Тестировщик без инструментов – как филолог без словаря: вроде можно что-то проверить «на слух», но вероятность ошибки велика. Когда я пришла в тестирование 1С после филологии, первое время я проверяла систему «по наитию»: открывала форму, нажимала кнопки, смотрела, что получится. Но довольно быстро стало ясно – одного «чутья» мало. В 1С есть своя логика, свои правила и, конечно, свои инструменты.
Со временем я собрала свой личный набор «помощников» тестировщика. Их не пятьдесят и не сто – всего десять. Но эти десять инструментов работают каждый день и позволяют не утонуть мне в море документов и багов.
Инструмент 1. Живой пользователь (ручное тестирование)
Самый простой, но от этого не менее ценный инструмент – это «живое» тестирование. То есть банально пройти путь пользователя руками. Ручное тестирование – это как автору перечитать роман глазами простого читателя: только так понимаешь, насколько он понятный, захватывающий ли сюжет.
Например, бухгалтер открывает форму «Поступление товаров». Я, как тестировщик, делаю то же самое: создаю документ, выбираю поставщика, указываю товары, провожу. Потом проверяю, появился ли документ в нужном журнале, правильно ли посчитались суммы, сформировался ли отчёт.
На первый взгляд – ничего сложного. Но именно так чаще всего вылезают ошибки, которые никакой автотест не заметит. Скажем, поле «Комментарий» уехало за пределы формы. Или кнопка «Провести» почему-то исчезла у одного типа пользователей.
Плюсы:
- сразу видно, удобно ли работать;
- легко «почувствовать» логику интерфейса;
- не нужны сложные настройки.
Минусы:
- занимает много времени;
- легко что-то пропустить;
- тесты сложно и муторно повторять один в один.
Инструмент 2. Отчёты и журналы регистрации
Если ручное тестирование – это взгляд «снаружи», то журналы регистрации – взгляд «внутрь». Это как черновики писателя: там можно увидеть, что именно система «думала» перед тем, как выдала результат. Еще журнал – это как рукопись с правками. Чтобы понять автора, надо уметь читать между строк.
Журнал регистрации в 1С фиксирует каждое действие: кто, когда, с каким результатом. Если где-то произошёл сбой, именно здесь найдётся подсказка. Например, документ не проводился, хотя всё вроде ввели правильно. Открыв журнал, можно увидеть: «Ошибка доступа к регистру накопления». Для пользователя это магия, а для тестировщика – точка отсчёта.
Плюсы:
- точная диагностика проблем;
- можно отследить последовательность действий;
- помогает восстанавливать «историю события».
Минусы:
- для новичка выглядит как набор заклинаний;
- требует внимательности и терпения.
Инструмент 3. Автоматизированное тестирование (Менеджер тестирования + Тест-клиент)
Тут уже всё серьёзнее. В 1С есть встроенный механизм автоматизированного тестирования, который работает в связке: Менеджер тестирования управляет сценарием, а Тест-клиент его выполняет.
Это как режиссёр и актёр: первый даёт текст и указания, второй играет роль.
Например, я могу задать в менеджере: «Создать документ “Платёжное поручение”, провести его, проверить результат». Тест-клиент выполнит шаги так, как будто это делает реальный пользователь. Чтобы проверить разные роли, сценарий можно прогнать под учётными записями бухгалтера, менеджера или администратора.
Плюсы:
- можно воспроизводить сценарии без «живых» коллег;
- удобно тестировать роли и права;
Минусы:
- нужно время на настройку окружения;
- сценарии чувствительны к изменениям интерфейса.
- результаты предсказуемы.
Инструмент 4. Фреймворки автотестов (xUnitFor1C, Vanessa Automation и др.)
Если встроенные средства — это «репетиция с актёрами», то фреймворки — целая киностудия.
xUnitFor1C позволяет писать модульные и интеграционные тесты на уровне кода. Это быстро, надёжно и отлично подходит для регрессии: система сразу подскажет, что после обновления перестал считаться НДС или сломалась логика проведения.
Vanessa Automation идёт ещё дальше — сценарии пишутся в стиле BDD («человеческим языком») и исполняются через тест-клиент. Такой подход делает тесты понятными не только программистам, но и аналитикам.
Плюсы:
- экономия времени на рутинных проверках;
- легко встроить в CI/CD;
- читабельные сценарии для всей команды.
Минусы:
- требует дисциплины и времени на написание тестов;
- UI-сценарии чувствительны к любым изменениям форм.
Инструмент 5. Скриншоты и чек-листы
Мой любимый «гуманитарный» инструмент. Иногда самое важное в тестировании – не найти баг, а зафиксировать его так, чтобы его понял любой коллега.
Скриншот – это как цитата из романа: не надо объяснять на словах, достаточно показать. Чек-лист – это конспект, который помогает не забыть главные моменты.
Например, я проверяю документ «Поступление». В чек-листе у меня пункты:
- создать документ;
- заполнить реквизиты;
- провести;
- проверить отчёт.
И если где-то баг – я делаю скриншот и прикладываю к отчёту. Всё. Коллега открывает картинку и сразу понимает, что не так.
Плюсы:
- понятность для команды;
- прозрачность работы;
- помогает структурировать тесты.
Минусы:
- требует дисциплины;
- соблазн «забыть заполнить».
Но поверьте, один хороший чек-лист и пара скриншотов иногда экономят больше времени, чем самый умный автотест.
Инструмент 6. Общение с коллегами
Можно сколько угодно копаться в журналах регистрации, но иногда баг выскакивает из уст коллеги.
— «А я всегда жму кнопку два раза, иначе не работает», – говорит бухгалтер.
И ты понимаешь: баг не в логике программы, а в том, как она воспринимается человеком.
Разговор с пользователем иногда экономит часы расследования. Менеджер подскажет, что в отчёте ему нужны три колонки, а не пять. Программист объяснит, почему кнопка уехала. А администратор напомнит, что сервер ночью перезагружается, и это ломает автотесты.
Общение – это не «софт скилл», а инструмент. Такой же важный, как журналы или чек-листы.
Инструмент 7. Время и методичность
Да, звучит скучно, но время – инструмент, а не просто ресурс.
Вот что я поняла за время работы тестировщиком: когда берёшься за тестирование, важно решить: где копать глубже, а где достаточно поверхностного взгляда. Проверить 100 документов по всем сценариям невозможно. Но сделать выборку и пройтись по ней внимательно – реально. Это как читать роман: где-то смакуешь каждую страницу, а где-то пролистываешь описания пейзажей. Главное – не потерять нить сюжета.
Инструмент 8. Тестовые базы
Если ручное тестирование – это «чтение романа», то тестовая база – это «черновик». В ней можно писать, зачеркивать, рвать страницы, и никто и ничего при этом не пострадает. А работать без тестовой базы – всё равно что править текст прямо в авторском оригинале.
Это место, где тестировщик чувствует себя свободно. Хочешь проверить редкий сценарий? Пожалуйста.
Хочешь «сломать» систему и посмотреть, что будет? Отлично, для этого и существует копия.
Инструмент 9. Собственные заметки и база знаний
Мне как гуманитарию близка идея «словаря». У тестировщика такой словарь тоже есть – это его заметки.
Заметки – это такая личная библиотека тестировщика со всеми нужными данными. Кто-то ведёт тетрадку, кто-то записывает в Notion, кто-то заводит простую таблицу Excel. Важно одно: там копится опыт. Например, я пишу:
«Эта ошибка возникает, если заполнить поле вот так».
«Этот отчёт ломается после обновления вот этой подсистемы».
Через месяц без заметок не вспомнишь, что уже проверял, а через год без них вообще невозможно будет объяснить новичку, где искать типичные баги.
Инструмент 10. Интуиция (и немного занудства)
Звучит странно, но для меня интуиция – действительно, один из главных инструментов. Интуиция появляется из опыта. Она как литературный вкус: чем больше читаешь, тем точнее чувствуешь фальшь. Бывает, открываешь форму и вдруг чувствуешь: «А вот это поле надо проверить». Никто не говорил, багов там не ждали, но именно там они и «живут»!
А ещё нужен лёгкий налёт занудства. Проверить то, что и так должно работать. Кликнуть там, где «всё уже проверяли». Задать лишний вопрос. Именно это занудство часто спасает от серьёзных ошибок.
Типичные проблемы тестировщика и чем их лечить?
1. Кнопка «куда-то делась»
Проблема: у одного пользователя кнопка «Провести» есть, у другого – нет.
Решение: тест-клиент (Инструмент 3) и общение с коллегами (Инструмент 6). Проверяем роли, воспроизводим ситуацию под разными пользователями. Часто оказывается, что дело в правах доступа.
2. «У меня ВСЁ зависло!»
Проблема: система подвисает на ровном месте, у одних пользователей работает, у других – нет.
Решение: журналы регистрации (Инструмент 2) и виртуальные машины (Инструмент 8). Смотрим, что происходило в момент зависания, воспроизводим на тестовой базе. Иногда помогает выявить конфликт прав или перегруженную форму.
3. Документ не проводится
Проблема: пользователь заполнил всё правильно, но документ «не идёт».
Решение: ручное тестирование (Инструмент 1) + журналы регистрации (Инструмент 2). Повторяем шаги, ловим ошибку в журнале. Чаще всего это проблема с регистром или недостающими настройками.
4. После обновления что-то сломалось
Проблема: вчера всё работало, сегодня после обновления – нет.
Решение: автотесты (Инструмент 4) и чек-листы (Инструмент 5). Автотесты быстро показывают, что именно перестало работать. Чек-листы помогают убедиться, что проверены все основные сценарии.
5. «Это неудобно!»
Проблема: пользователи жалуются, что работать в форме неудобно, хотя формально всё правильно.
Решение: общение с коллегами (Инструмент 6) и интуиция (Инструмент 10). Иногда нужна не логика программиста, а «человеческий взгляд». Поменять расположение кнопки или добавить подсказку – и жизнь пользователей станет легче.
6. Баг «прячется»
Проблема: ошибка проявляется только раз в неделю или при очень специфических условиях.
Решение: заметки и база знаний (Инструмент 9) + методичность (Инструмент 7). Фиксируем все условия, при которых баг возникает, ведём журнал наблюдений. Иногда именно запись «возникло в пятницу вечером при закрытии месяца» помогает поймать причину.
7. «Вроде всё проверил, но всё равно упустил»
Проблема: тестировщик пропустил баг, потому что не хватило времени или внимания.
Решение: чек-листы (Инструмент 5) и планирование времени (Инструмент 7). Чек-лист снимает нагрузку с памяти, а грамотное распределение времени помогает не застрять на мелочах.
Что-то вроде вывода
Тестировщик – это не программист и не конечный пользователь. Он стоит на границе между ними. Его задача – перевести «язык программы» на «язык пользователя» и наоборот. А каждая проблема в 1С тестировании — это не катастрофа, если под рукой есть правильный инструмент. Главное: не паниковать, а вспомнить: баги повторяются, а значит, и решения для них тоже есть.
Вступайте в нашу телеграмм-группу Инфостарт