Меня зовут Алена Метенева, я руководитель направления по тестированию в Росгосстрахе. А это третья статья цикла про внедрение ИИ в тестирование.
В первой статье я рассказывала, зачем мы вообще пошли в пилот и почему начали с ручного режима в Cursor. Во второй разбирала подготовку контекста: от простого кейса до больших ТЗ с PDF, диаграммами и макетами.
Теперь двигаемся дальше: контекст уже собран и актуализирован, значит пора переходить к следующему этапу — тестированию требований с помощью ИИ.
Зачем вообще тестировать требования с ИИ?
Ни для кого не секрет, что если находить пробелы и противоречия в постановках до начала разработки, команда экономит и время, и деньги.
На этом этапе ИИ хорошо решает три практические задачи:
-
Системно ищет противоречия, пробелы и логические ошибки;
-
Ускоряет первичный разбор большого объёма требований;
-
Структурирует вопросы к аналитику и команде.
Отдельно подчеркну важный момент: анализ требований — это не только зона ответственности QA. Аналитикам тоже полезно прогонять свои постановки через ИИ до передачи в разработку и тестирование. Это экономит время всех компетенций.
Пошаговый процесс
Когда у вас готов контекст, любой процесс с ИИ можно уложить в стандартную схему: данные + промт + ревью и доработки = результат. Остановлюсь на каждом шаге чуть подробнее:
Шаг 1. Подготовьте материалы по задаче
Соберите в одну папку:
-
актуальный контекст продукта (как подготовить контекст, описано в статье);
-
требования по новой задаче или фиче;
-
связанные артефакты (если они есть): макеты, диаграммы, уточнения от аналитика.
Чем лучше подготовлены входные данные, тем меньше остается пространства для «творчества» у ИИ.
Шаг 2. Подготовьте промпт
Есть два рабочих пути:
-
взять готовый промпт и адаптировать под ваш продукт;
-
попросить ИИ сгенерировать промпт под ваши нужны.
Мне лично больше нравится второй вариант, потому что он быстрее. Достаточно только четко прописать задачу и ограничения, а ИИ сам упакует это в нужные слова.
Что важно явно зафиксировать в промпте:
-
область анализа (что проверяем, а что не проверяем);
-
ожидаемую структуру ответа;
-
формат итогового списка проблем;
-
запрет на домысливание фактов, которых нет в требованиях.
Шаг 3. Запустите анализ
Запустите промпт с подготовленными файлами и дайте ИИ сформировать первичный список замечаний.
На этом этапе не ждите идеала с первого раза. Нужный результат, как правило, достигается за несколько итераций.
Шаг 4. Проведите ревью результатов
Это ключевой шаг. ИИ обязательно нужно ревьюить, поскольку модель знает только то, что лежит в контексте. Неформальные договорённости и командные нюансы ей неизвестны, поэтому она может давать лишние или неактуальные замечания.
Во время ревью разделяйте замечания на две группы.
Отбросьте замечание, если:
-
у вас уже есть подтверждённый ответ;
-
если оно касается того, что осознанно оставлено на усмотрение команды (например, детали реализации).
Оставьте замечание, если:
-
оно подсвечивает реальные противоречия между частями требований и макетами;
-
это недостающие сценарии и edge-cases;
-
оно указывает на неоднозначные формулировки, которые могут по-разному трактоваться.
Шаг 5. Итеративно улучшайте результат
Рабочий цикл выглядит так:
-
генерация замечаний ИИ;
-
ревью тестировщиком;
-
уточнение промпта и/или контекста;
-
повторный запуск.
Правило простое: если ИИ ошибся из-за неточных инструкций — дорабатываем промт. Если ошибся из-за недостатка информации — дорабатываем контекст. Идём по кругу, пока:
-
список проблем не станет релевантным и удобным для передачи команде;
-
количество ложных срабатываний не снизится до приемлемого минимума.
На финальной итерации можно попросить ИИ:
-
переписать требования, оставив корректные части без изменений, а спорные пометить ⚠️;
-
сформировать отдельный список вопросов к аналитику;
-
собрать короткий README по следующему шагу для ролей: аналитик, разработчик, QA.
-
актуализировать промт, исходя из тех замечаний, которые вы делали ИИ. Это позволит в следующий раз быстрее добиться нужного результата.
Какие могут возникнуть проблемы на этом этапе
Когда начинаешь тестировать требования с ИИ регулярно, проблемы повторяются.Это происходит потому что на этом этапе смешиваются три вещи: качество входных данных, качество промпта и качество ревью.
Самая частая история — модель выдаёт длинный, формально правильный, но плохо читаемый текст. Такое легко чинится: не тратить полчаса на ручное вылизывание, а сразу попросить ИИ переформатировать результат в понятную структуру: по компонентам, сценариям и приоритетам.
Вторая типовая история — «много шума, мало пользы». Модель начинает поднимать вопросы уровня реализации, хотя вы в этом прогоне проверяете бизнес-логику и тестируемость. В таких случаях спасает не новый инструмент, а точнее сформулированная рамка задачи: что именно анализируем, а что в этом запуске сознательно не трогаем. Как только в промпте появляется этот фокус, процент второстепенных замечаний обычно резко падает.
Что вы получите в итоге?
Хороший результат тестирования требований с ИИ — это прикладной отчет, который можно сразу использовать в работе:
-
релевантный список проблем в требованиях;
-
структурированные вопросы к аналитику;
-
предложения по улучшению формулировок и требований.
Именно здесь начинает работать shift-left: неточности и ошибки проявляются до того, как требования переданы в разработку, а значит устранять их намного легче и дешевле.
В следующей статье цикла я расскажу о том, как генерировать тестовую документацию с ИИ.
И, как всегда, короткое напоминание: ИИ ускоряет процесс, но качество результата держится на вашей экспертизе и ревью.
Продолжение следует!
Автор: alenameteneva
