Я пришла в автоматизацию из ручного тестирования. В нашей компании было правило: тестировщик читает ТЗ до того, как оно уходит разработчикам. Тогда казалось лишним. Теперь понимаю — без этого автоматизация просто не взлетит.
Ручной тестировщик строит матрицу трассировки, пишет тест-кейсы. Автоматизатор получает то же ТЗ и должен родить сценарии на Vanessa Automation (VA).
И тут начинается самое интересное.
Мы не просто «перекладываем шаги» — мы проектируем проверки. Но значительная часть времени уходит на вещи, которые можно было бы автоматизировать. Не заменяя мышление, а освобождая его для действительно сложных задач.
В этой статье — четыре ситуации, где я каждый раз ловлю себя на мысли: «А почему, собственно, я это делаю руками?» И четыре техники, которые могли бы убрать эту рутину.
1. Требования: три вопроса, которые аналитик забыл
VA не умеет читать ТЗ, и не должна. Feature-файлы мы пишем руками, глядя в документ. И каждый раз я вынуждена выяснять одно и то же:
Как называется элемент интерфейса? Не «кнопка добавления», а её Синоним — точный текст, который видит пользователь. Если название менялось («Добавить» → «Создать») — мне нужны оба варианта: в VA есть механизм множественных синонимов, и если его не использовать, тесты упадут при первом же обновлении.
Какие данные уже есть, а какие нужно создать? Контрагент уже существует в базе или его надо заводить прямо в сценарии? Какие реквизиты обязательны, как они связаны?
Что считается успехом? Не «документ провёлся», а конкретные изменения: статус, движения регистров, сообщение пользователю, состояние полей.
Если этих данных нет — я иду к аналитику. Если аналитик занят — к разработчику. Если разработчик занят — я начинаю додумывать. А додумывание в автотестах — это ложные падения и ночные звонки.
Что можно сделать.
На этапе приёмки требований внедрить простой чек-лист. Аналитик, прежде чем отдать ТЗ разработчику, отвечает на три вопроса — интерфейс, данные, результат. Это не технология, это дисциплина. Но она экономит часы переписки и устраняет неопределённость до того, как написан первый шаг.
2. «Исследователь формы»: как перестать копировать
Многие представляют «Исследователь формы» как инструмент, где надо наводить курсор, ловить элемент, выискивать строчку. На самом деле всё удобно:
- В клиенте тестирования я щёлкаю по нужному реквизиту — просто выделяю его.
- Переключаюсь в менеджер тестирования, открываю «Исследователь формы».
- В окне уже подсвечен тот самый реквизит, со всеми его атрибутами: Имя, Синоним, путь, тип.
- Копирую Имя, вставляю в конструкцию с именем "…".
Десять секунд. Сто реквизитов за спринт — тысяча секунд. Само по себе не критично, но каждое такое действие — это переключение контекста. Я выныриваю из редактора, тыкаю мышкой, возвращаюсь. Поток сбивается.
Что можно сделать.
Автокомплит имён реквизитов прямо в редакторе. VA и так знает, какая форма открыта в клиенте тестирования — через тот же механизм, который использует «Исследователь». Почему бы не стянуть список доступных имён и не показывать его, когда я начинаю вводить с именем "?
Это не нейросети. Это просто связка между двумя сеансами. Никакого копирования, никакого переключения. Выбрал из списка — и поехали.
3. Атомарность: не нарезка, а таблица решений
Часто слышу: «Мы сделали атомарные тесты — разрезали длинный сценарий на десять частей».
Это не атомарность. Это просто дробление. Данные остаются связанными, логика переплетена, и при падении на сороковом шаге всё равно полчаса расследуешь причину.
Атомарность — это один тест = одно условие.
Вот пример. Требование: «Документ проводится, если заполнены контрагент, склад, сумма > 0 и есть остатки. Иначе — проведение запрещено».
Условий — четыре. Каждое бинарное (да/нет). Полное комбинаторное покрытие — 16 комбинаций, но нам не нужно проверять все. Достаточно метода Pairwise (попарного тестирования) или просто метода «каждый параметр по очереди — невалиден».
Я пишу пять тестов:
- Все условия выполнены → проведение разрешено (базовый).
- Контрагент не заполнен → проведение запрещено.
- Склад не заполнен → проведение запрещено.
- Сумма = 0 → проведение запрещено.
- Нет остатков → проведение запрещено.
Каждый тест создаёт свои собственные данные — с уникальным префиксом, чтобы не пересекаться с другими. Никакой зависимости.
При падении теста №2 я сразу знаю: проблема в валидации контрагента. Не надо расследовать — надо чинить.
Что можно сделать.
Генератор тестовых наборов по таблице решений. Я ввожу условия (контрагент, склад, сумма, остатки) и ожидаемый результат для каждой комбинации. Инструмент строит минимальный набор по алгоритму Pairwise (ортогональные массивы) и генерирует каркас feature-файлов с уникальными префиксами.
Это не магия. Это комбинаторика, которую мы всё равно делаем головой, но медленно и с ошибками. Переложить её на инструмент — значит снять с автоматизатора механическую работу по перебору вариантов.
4. Поддержка: глобальный рефакторинг имён
Разработчик переименовывает реквизит в конфигураторе. По бизнес-логике — ничего не изменилось. По нашим тестам — упало всё, где использовалось с именем "СтароеИмя".
Разработчики VA уже решили проблему для синонимов — в версии 1.2.041.1 появился механизм множественных синонимов. Можно сохранить старое название кнопки в настройках, и тесты будут работать и с ним, и с новым.
Но если меняется Имя — программный идентификатор — механизм не помогает. Я открываю каждый упавший фича-файл, ищу строки со старым именем, заменяю вручную. Пятьдесят файлов — три часа.
Что можно сделать.
Инструмент глобального рефакторинга. Он анализирует все feature-файлы в проекте, находит вхождения заданного имени в шагах с именем "…" и предлагает заменить их на новое. Один клик — и 50 файлов исправлены.
То же самое — для синонимов. Да, множественные синонимы помогают не ронять старые тесты, но они не удаляют устаревшие названия из кода. Через год в проекте копятся десятки неиспользуемых синонимов, и никто не знает, можно ли их убрать. Рефакторинг должен подсвечивать и такие места.
Это не искусственный интеллект. Это обычный поиск с учётом контекста, реализованный в любой современной IDE.
Вместо итога: эволюция, а не замена
Я не прошу нейросеть писать за меня сценарии. Я прошу, чтобы инструмент взял на себя ту работу, которая не требует творчества:
- подстановку имён реквизитов вместо копирования;
- генерацию комбинаторных наборов вместо ручного перебора вариантов;
- глобальный рефакторинг вместо открытия пятидесяти файлов по очереди.
Это всё решаемо уже сейчас. Не хватает только одного — системного взгляда на автоматизацию как на инженерную дисциплину, где инструмент помогает думать, а не заменяет мышление.
Vanessa Automation дала нам возможность автоматизировать проверки 1С. Следующий шаг — автоматизировать рутину внутри самой Vanessa Automation.
А какие приёмы используете вы, чтобы сократить ручной труд при написании сценариев? Есть ли у вас собственные наработки или скрипты, которые ускоряют работу? Буду благодарна за комментарии — давайте соберём коллекцию практик.
Больше разборов ИТ-процессов, кейсов по автоматизации и заметок
«с полей» — в моем Telegram-канале:👉 Техред в полях