Генерация тестовой документации с ИИ

Всем привет! Продолжаю цикл статей про применение ИИ в тестировании. В первой ^[1]я рассказывала о том, зачем мы пошли в пилот по применению ИИ в тестировании. Во второй ^[2]— как собирать контекст. В третьей ^[3]— как тестировать требования, когда контекст уже готов.

Сегодня поговорим про следующий этап — генерацию тестовой документации: тест-кейсы, чек-листы, матрица покрытия и т.д. Небольшой спойлер: в конце статьи вас ждет ссылка на репозиторий с инструкциями и промтами.

Зачем вообще отдавать тест-дизайн нейросети?

Причины все те же:

Скорость — она реально чувствуется на объёмных требованиях. На маленькой фиче из двух абзацев вы потратите больше времени на промпт и контекст, чем сэкономите.

Детализация — модель учитывает в сценарии все мелочи из ТЗ и расписывает все подробнее. У тестировщиков часто не хватает времени на детализацию шагов и ожидаемых результатов. Опытные инженеры многое держат в голове, но это потом больно аукается, когда “носитель знаний” уходит из команды или когда нужно онбордить нового человека. Времени на онбординг всегда мало, и детальные тест-кейсы могут снять часть нагрузки с ментора.

Формат под TMS — если прописать четкие правила по итоговому формату, на выходе можно получить не простыню текста в чате с ИИ, а файлы, которые реально импортировать в вашу TMS.

Какая информация нужна для старта?

Если вы воспользовались советами из моих предыдущих статей, то к этому моменту у вас уже есть контекст продукта и требования по фиче , протестированные и исправленные аналитиками в случае необходимости. К этому нужно добавить следующие документы:

Правила написания тест-кейсов, основанные на стандартах, принятых в вашей компании или команде:

• где хранятся кейсы (у нас это Zephyr);

• как формулировать шаги и ожидаемые результаты;

• насколько детальными должны быть тестовые данные;

• нужно ли указывать окружение или предусловия и для каких кейсов;

• особые условия (например, точный текст ошибки ^[4] в негативных кейсах);

• какие есть ограничения и антипаттерны (не делать отсылки к другим кейсам, не использовать условную логику ^[5] в шагах и т.д.).

Эталонный тест-кейс — один «идеальный» пример. Я выгружала его из Zephyr в CSV формате: модель легко читает csv и сразу видит реальные поля и стиль описания шагов, а не выдумывает свой шаблон.

Базовый сценарий. Не обязательно, но желательно для тех задач, если фича продолжает уже знакомый путь. Например, в калькуляторе страховой премии пользователь идет по экранам постепенно. И разработка тоже ведется постепенно от первого экрана к последнему. Когда у меня есть готовые тест-кейсы для первого экрана, я даю их нейросети для генерации тестов на последующие экраны. Если у меня уже есть идеально описанные шаги, то зачем просить нейросеть сделать ту же работу дважды? Если подумать, то мы тоже при написании новых кейсов часто клонируем старые и корректируем их или дополняем новыми условиями. С ИИ этот принцип тоже работает. К тому же, такой подход унифицирует документацию и уменьшает вероятность ошибок.

Пошаговая инструкция

Шаг 1. Собрать входные файлы в одну папку

Контекст, требования по задаче, правила, эталонный тест-кейс и, при необходимости, базовый сценарий. Чем меньше модели приходится догадываться, тем меньше «творчества» будет в ее ответе.

Шаг 2. Подготовить промпт

Беру готовый шаблон и подкручиваю под продукт или прошу ИИ собрать промпт под конкретную задачу. Второй вариант обычно быстрее и удачнее. В промпте фиксирую: какие файлы на входе, какие артефакты на выходе, ограничения (не выходить за рамки ТЗ, не придумывать данные, не ссылаться на другие кейсы).

Промпт у меня не статичный. После каждой итерации, где что-то пошло не так, я прошу поправить сначала документацию, потом сам промпт, чтобы на следующей задаче уже не наступать на те же грабли.

Шаг 3. Запустить генерацию

Загружаю файлы, даю задачу вроде «выполни задание из файла …» и жду.

С тем промтом, который я использую сейчас, у меня получается такой набор документации:

Use cases в формате .md — этот документ я проверяю первым. По нему сразу видно, как модель поняла требования и какие сценарии выделила. Если use cases написаны неправильно, то дальше проверять бессмысленно, и я возвращаюсь к контексту или промпту. Пример use cases:

End-to-end тесты в формате .md — подробные е2е тесты для вдумчивого ревью: все шаги, все тестовые данные, детальные ожидаемые результаты.

Пример тест-кейсов, сгенерированных ИИ по заданным правилам и шаблону:

Чек-лист в формате .md — позитивные и негативные проверки по элементам или компонентам. Также подлежат тщательной проверке тестировщиком.

Матрица покрытия в формате .csv — исключительно для проверки того, что все требования покрыты тестами.

У вас может быть свой набор выходной документации.

Шаг 4. Ревью

Про ревью уже немного написала в предыдущем пункте. Что важно: ревью должен делать опытный специалист, который мог бы написать то же самое самостоятельно, просто потратил бы на это больше времени. Если с ИИ работают джуны — финальное ревью должны выполнять миддлы и сеньоры. Иначе ошибки модели быстро станут «официальной документацией».

Ну и в целом принцип ревью один и тот же: если вы нашли у ИИ ошибку из-за недостатка информации, нужно дополнить требования или контекст. Если вы понимаете, что ошибка из-за неточного промта, то правите промт. Если же во время ревью вы понимаете, что модель делает что-то наперекор инструкциям, просто спросите у нее, почему она так делает. Чаще всего вы получите внятный ответ и сможете скорректировать задачу. У меня однажды было такое, что ИИ долго выдавал мне тест-кейсы, написанные не в соответствии с моими требованиями. После каждой итерации я добавляла в промт новый запрет, но это не помогало. В конце концов, я задала вопрос агенту “Ты что, вообще не читаешь мои инструкции?”. На что он мне ответил: “Читаю, но там уже так много запретов и указаний, как НЕ надо делать, что я не понимаю, как НАДО делать”. В общем, оказалось, что ИИ лучше работает с позитивными установками, чем с негативными, и я теперь стараюсь не забывать ^[6] об этом.

Шаг 5. Итерации

Сколько итераций надо сделать, прежде чем остановиться и сдаться? У меня правило такое: если я уже потратила больше времени на задачу с ИИ, чем у меня ушло бы вручную, и при этом я не получила ни одного приемлемого результата, я делаю вывод, что эту задачу лучше оставить человеку. Если же я получала хорошие ответы, но они были нестабильны, то я делаю паузу и возвращаюсь к задаче позже.

Ну, а еще бывает, что контекстное окно чата забито под завязку. Новый чат или короткое саммари часто помогают в этой ситуации.

Шаг 6. CSV и импорт в Zephyr

Когда мое ревью и правки окончены и качество артефактов меня устраивают, я прошу ИИ перевести кейсы и чек-листы в формат CSV под наш Zephyr.

Тут ничего сложного нет – достаточно один раз выгрузить тест-кейс из Zephyr, проанализировать соответствие полей и прописать все в промте. Вот небольшой пример:

• Precondition: заполняется только в первой строке тест-кейса, если предусловия указаны в тест-кейсе. Для остальных шагов поле Precondition остаётся пустым.

• Steps: один шаг — одна строка. Нумерация шагов внутри каждого тест-кейса должна начинаться с 1 для каждого нового тест-кейса.

• Test Data: заполняется, если есть тестовые данные для шага.

• Test Type: всегда “E2E”.

• Automation: всегда “To be automated”.

После того как формат подобрали, ИИ быстро превращает текстовые тесты в csv, а импорт в Zephyr у меня занимает меньше минуты. Пару раз при импорте у меня получалась ерунда, например, каждый шаг e2e-теста становился отдельным тест-кейсом. Причина оказалась банальной: в CSV название кейса (поле Name) должно быть указано только в строке первого шага. Если продублировать поле Name в каждой строке — Zephyr плодит отдельные кейсы.

Что в итоге

На этапе написания тестовой документации ИИ может дать едва не лучший буст по скорости, особенно если у вас большой объем документации, сложный тест-дизайн или много однотипных кейсов. Но залогом хорошего результата всегда остаются два компонента: качественные входные данные и обязательное ревью.

В следующей статье цикла я начну рассказывать о генерации автотестов с помощью ИИ, и о том, почему получилось не сразу.

И обещанный бонус: в этом репозитории ^[7] лежат более подробные инструкции и примеры промптов для использования ИИ в тестировании.