Всем привет! Я продолжаю цикл статей про применение ИИ в тестировании. Мы уже успели поговорить про анализ требований, создание тестовой документации и автотесты, т.е. разобрали весь shift-left с ИИ. Но у QA-инженера есть много других задач, с которыми ИИ также может помочь.
И одной из таких задач является актуализация тестовой модели. Когда она может потребоваться? Когда продукт существует уже не первый год, тест-кейсов накопилось много, они написаны разными людьми в разное время по разным шаблонам, а требования к продукту успели поменяться. В TMS накапливаются дубликаты, устаревшие шаги и кейсы, которые логичнее было бы объединить. Разбирать всё это вручную долго и дорого, и редко когда у команды есть ресурс на такой разбор. Вот тут-то вам может пригодится ИИ.
Ручной аудит сотни кейсов — это недели монотонной работы. ИИ может пройтись по всей тестовой модели и выдать структурированный отчёт с рекомендациями. Анализ 50–100 тест-кейсов занимает у модели несколько минут. Ревью и правки в Zephyr займут у человека несколько часов, но хотя бы не нужно будет читать каждый кейс с нуля и сравнивать его с документацией.
Опять же, при работе с большим объемом кейсов человек в какой-то момент теряет фокус, а модель может увидеть дубликаты, которые при беглом просмотре не бросаются в глаза: разные формулировки, но один и тот же сценарий.
Основной момент, который надо учитывать: ИИ выдаст вам отчет с рекомендациями, а не готовые правки. После отчета вас все равно ждет ручная работа. Решение об удалении, объединении или актуализации всегда принимает тестировщик. Если кейс важен для регресса — его оставляют, даже если модель посчитала его дубликатом. Конечно, можно настроить интеграцию с jira и пустить агента переписывать кейсы без вас. Но все мы понимаем, что ничем хорошим это не кончится)
Что нужно для старта?
Минимальный набор артефактов на входе:
Полный контекст продукта — актуальные требования в структурированном виде. Если контекст устарел, весь план оптимизации бессмысленен: ИИ будет сравнивать кейсы с неактуальной картиной мира.
Выгрузка тест-кейсов из вашей TMS в текстовом формате.
Вы МОЖЕТЕ дать ИИ только кейсы, без актуальных требований. Но тогда максимум, на что вы можете рассчитывать — это отчет о дублирующих кейсах и кейсах, которые можно каким-то образом объединить. С другой стороны, если у вас требования особо не менялись и вы уверены в том, что все шаги в кейсах актуальны, нужно просто прошерстить тестовую модель на предмет лишних тестов — тогда ваша задача становится еще легче.
Пошаговая инструкция
Шаг 1. Собрать входные данные
Контекст продукта + выгрузка кейсов. Чем полнее входные данные, тем меньше «творчества» в ответе.
Важно: контекст должен отражать текущее состояние продукта. Если вы запустите анализ со неактуальной версией требований, получите на выходе ложные рекомендации по актуализации.
Шаг 2. Подготовить промпт для анализа
Промт пишу с помощью ИИ и явно фиксирую:
задачу — например: «Выполни анализ тест-кейсов продукта …»;
входные данные — ссылки на файл с контекстом и на файл с тест-кейсами;
задачи анализа:
найти дубликаты (критерии дубликатов, формат рекомендаций);
найти кейсы, которые можно объединить в один е2е (параметризация, связанные сценарии);
дать рекомендации по актуализации (сопоставление с требованиями, типы расхождений);
формат отчёта — разделы: Введение, Дубликаты, Кандидаты на объединение, Требуют актуализации, Сводка и рекомендации;
ограничения — опираться только на предоставленные файлы, при неоднозначности помечать «требует ручной проверки», учитывать типы тестов (E2E / Service / Component).
Пример промта:
Скрытый текст
# Промпт для анализа тест-кейсов Онкокалькулятора Ты — QA-аналитик. Выполни анализ тест-кейсов продукта «Онкокалькулятор» (онкострахование «Здоровье дороже») и подготовь структурированный отчёт. ## Входные данные 1. **Тест-кейсы** — файл `Тест-кейсы_Онкокалькулятор.csv` (выгрузка из Zephyr). Содержит: Key, Name, Component, Test Type, Status, шаги, тестовые данные, ожидаемые результаты. 2. **Требования к продукту** — файл `Сводный контекст Онкокалькулятор.md` (описание компонентов, логики, валидаций, API-сценариев и сценариев использования). ## Задачи анализа ### 1. Анализ на дубликаты - Сравни тест-кейсы по целям, предусловиям, шагам и ожидаемым результатам. - Найди пары/группы тест-кейсов, которые проверяют одно и то же поведение или сценарий. - Для каждой пары укажи: Key обоих тест-кейсов, краткое описание пересечения, рекомендуемый к удалению тест-кейс (с обоснованием). - Критерии дублирования: одинаковые или практически идентичные шаги, проверки и ожидаемые результаты; один сценарий, покрытый несколькими разными тест-кейсами. ### 2. Анализ на объединение - Выдели тест-кейсы, которые логически связаны, но сейчас разнесены по отдельным кейсам (например, разные варианты одного сценария или один сценарий, разбитый на несколько маленьких). - Предложи варианты объединения: какой тест-кейс можно расширить или каким образом объединить 2–3 кейса в один (с параметризацией/вариантами данных). - Для каждого предложения: Key участвующих тест-кейсов, новый сценарий, предполагаемые выгоды (сокращение количества, улучшение покрытия и т.п.). ### 3. Анализ на актуализацию - Сопоставь тест-кейсы с требованиями из `Сводный контекст Онкокалькулятор.md`. - Выяви тест-кейсы, у которых: - шаги или ожидаемые результаты не соответствуют текущей логике продукта; - устаревшие формулировки сообщений валидации, форматы полей или API-эндпоинты; - неверные предусловия или тестовые данные; - статус Draft/Needs actualization без явного признака актуализации; - проверяют поведение, которого нет в описании продукта. - Для каждого: Key, тип расхождения (шаги/ожидания/предусловия/статус), что именно нужно скорректировать. ## Формат отчёта Подготовь отчёт в Markdown со следующими разделами: 1. **Введение** — объём анализа (количество тест-кейсов, компонентов), краткая методология. 2. **Дубликаты — рекомендованы к удалению** - Таблица: Key | Название | Дублирует Key | Обоснование | Рекомендация. - Итог: сколько тест-кейсов можно удалить. 3. **Кандидаты на объединение** - Таблица: Key участвующих | Предлагаемое объединение | Выгода. - Краткое описание предлагаемого объединённого сценария. 4. **Требуют актуализации** - Таблица: Key | Название | Тип расхождения | Что изменить | Приоритет (Высокий/Средний/Низкий). - Подробности по критичным расхождениям. 5. **Сводка и рекомендации** - Общая статистика: удалить / объединить / актуализировать. - Рекомендуемый порядок работ. - Список тест-кейсов, не требующих изменений (устойчивое ядро). ## Дополнительные указания - Приводи обоснования, опираясь только на предоставленные файлы; не добавляй предположений извне. - При неоднозначности помечай как «требует ручной проверки». - Учитывай типы тестов (E2E / Service / Component) при рекомендациях по объединению. - Для сценариев с разными данными (паспорт РФ/иностранный, страхователь = застрахованному / нет) рассматривай параметризацию вместо дублирования кейсов.
Шаг 3. Запустить анализ
Команда простая:
Выполни задание, описанное в файле [путь к промпту для анализа тест-кейсов]
Запускаю в папке с входными артефактами и жду. На наборе из 50–100 кейсов анализ занимает несколько минут. Если ваша тестовая модель насчитывает несколько тысяч кейсов, лучше разбить ее на несколько блоков, например, по компонентам, функциям или любому другому критерию. Смысл в том, чтобы за раз давать нейросетке не больше 200-250 тест-кейсов (если это длинные е2е с парой десятков шагов)
На выходе получается отчёт с разделами:
Введение — объём анализа, методология;
Дубликаты — таблица с id кейсов и обоснованием, рекомендованы к удалению;
Кандидаты на объединение — id кейсов и почему их стоит склеить;
Требуют актуализации — тип расхождения и приоритет;
Сводка и рекомендации — статистика, порядок работ, актуальные кейсы, которые не надо трогать и т.п.
Шаг 4. Провести ревью отчёта
Напоминаю, что ревью — это обязательный шаг. ИИ ускоряет анализ, но не снимает ответственность за качество.
На что смотрю я:
Область | Что проверить |
|---|---|
Дубликаты | Кейсы действительно дублируют друг друга, а не покрывают смежные сценарии |
Объединение | Шаги из разных кейсов логичны и дополняют друг друга, сценарии не смешиваются в одном кейсе, объединение удобно на практике |
Актуализация | Пункты сверены с реальными требованиями, учтены недавние изменения |
Ручная проверка | Все пункты «требует ручной проверки» проверены |
По каждому кейсу ставлю свое итоговое резюме: убираем/оставляем/обновляем.
Шаг 5. Внести изменения в Zephyr
Можно действовать в таком порядке:
Удаление дубликатов — удалить рекомендованные кейсы, предварительно убедившись, что оставшийся полностью покрывает сценарий.
Актуализация — обновить шаги, ожидаемые результаты и предусловия. Сначала кейсы с высоким приоритетом и явными ошибками.
Объединение — создать новые объединённые кейсы, затем удалить или архивировать старые.
Статусы — привести в порядок кейсы со статусами Draft и Needs actualization.
Изменения лучше делать поэтапно, в несколько заходов. Я обычно создаю в Zephyr новую папку и постепенно переношу туда актуальные и обновленные кейсы. После окончания переноса удаляю старый набор. Так проще контролировать процесс и нет риска «сломать» всё разом.
Что в итоге
Оптимизация тестовой модели — логичное продолжение shift-left с ИИ. Сначала мы собираем контекст, тестируем требования, генерируем документацию, потом автоматизируем регресс. Но тестовая модель живёт и меняется: требования обновляются, появляются новые кейсы, старые забывают архивировать.
Если ручные тестировщики с самого начала пишут детальные кейсы, пригодные для автоматизации, — оптимизировать потом проще: в отчете меньше неоднозначностей, меньше пометок «требует ручной проверки». Поэтому сквозной процесс слева работает лучше, чем точечное применение ИИ на одном этапе.
Кстати, даже если вы не планируете регулярно гонять оптимизацию через нейросеть, сам отчёт полезен как аудит: видно, где тестовая модель раздулась, где отстала от требований, где можно объединить проверки.
В следующих статьях я расскажу про другие задачи, с которыми вам могут помочь ИИ-инструменты.
Продолжение следует!
