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