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

Тест-документация рождается быстрее, а свободное время инженеры используют для исследовательских тестирований, погружения в продукт и проработки нефункциональных требований. И всё это вместо монотонного создания проверок по требованиям.

Вместе с Марией, техническим руководителем QA в Surf, расскажем, как сократили время создания проверок в 5 раз и не потеряли в качестве.

Кому пригодится

1. Командам, чей продукт растёт быстрее, чем закрывается тест-долг.

2. Проектам, в которых дизайнеры, аналитики и QA живут в разных инструментах.

3. Тем, кто уверен, что человеку нужно делать только то, что недоступно машине.

Почему мы решили автоматизировать тесты

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

Мы используем 2 типа тестов. Это надёжно, но требует ресурсов.

Компонентные тесты

Изолированно проверяем каждый UI-элемент и экран. Мы, кстати, уже писали об этом. Эти проверки используем чаще всего при первом функциональном тестировании новой фичи — это помогает найти все неточности сразу.

Сценарные тесты

Проигрываем пользовательский путь от первого клика до последнего действия.

Такие проверки используем в регрессионном тестировании и при приёмке фичи.

Как выглядит процесс автотестирования

1. Макеты лежат в Figma, требования — в Confluence.
   Макеты нужны, чтобы сделать декомпозицию экрана и не потерять элементы.
   Требования аналогично помогают не потерять важные элементы или экраны, а ещё содержат логику экрана и флоу.

2. По регламенту каждый экран и ключевой элемент превращается в отдельный Xray-тест в Jira.

3. Ручной ритуал занимает около 30 минут на один экран: открыть макет, скачать png-макет, завести задачу, описать шаги, заполнить поля, прикрепить PNG.
   Или: открыть требования, завести задачу, описать шаги, заполнить поля. Конечно, с применением техник тест-дизайна.

4. В релизе бывает 60 экранов — это 30 часов чистой рутины в каждом цикле.

В общем, задача реально ресурсозатратная.

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

Мы уже пробовали поручать ИИ сразу создавать тесты, но без достаточного уровня проработки. Что получилось:
• модель выдаёт формат, отличный от корпоративного шаблона, — приходится править вручную;
• экономии времени почти нет. Польза в основном в том, что можно легко увидеть пробелы в покрытии.

Как это должно работать в идеале

1. Тест-кейс рождается автоматически — по дизайну и требованиям.

2. Скриншоты, ссылки и шаги Xray заполняет робот, без участия человека.

3. QA остаётся пройтись по готовому списку и дописать нюансы.

4. При этом покрытие должно быть достаточно высоким, а времени хотелось бы тратить меньше.

Что нам мешало раньше

В первых экспериментах с LLM форматы выходили «кривыми»: модель генерировала тесты, но их приходилось править под корпоративный шаблон. 

Мы поняли, что нужен сложный, контекстный промпт. Он сразу должен был выдать CSV/JSON-файл в точном формате, который можно было бы загрузить в Xray.

Что мы придумали

В итоге мы решили усложнить запросы к ИИ, поэтому жёстко закодировали в промпт правила структуры тестов. Так что теперь результат сразу должен быть совместим с нашими подходами.

Сделали так, что весь обмен теперь идёт через API сервисов Figma, Confluence, Swagger, Jira Xray.

Что мы придумали

Давайте смотреть.

Как это сделали мы

Мы собрали скрипт-конвейер, который за пару минут и пару кликов забирает рутину на себя.

1. Подготовка данных — это делает скрипт.

• Забирает нужные экраны и элементы из Figma, рендерит их в PNG.

• По маскам выделяет ключевые элементы, чем проводит декомпозицию экрана.

• Конвертирует требования из Confluence в Markdown — получается готовый набор данных для LLM.

• Собирает в один пакет данные из Figma, требований, Swagger и результатов декомпозиции и формирует финальный промпт.

2. Генерация проверок — это делаем мы с LLM.

• QA инженер отправляет готовый промпт в модель.

• LLM создаёт проверки в формате JSON — уже в соответствии с корпоративным шаблоном для Xray.

3. Экспорт в Jira Xray — это снова делает скрипт.

• Скрипт принимает JSON и автоматически создаёт задачи Xray.

Скрипт берёт на себя всю рутину подготовки и импорта, а человек сосредотачивается на самой генерации и быстром ревью полученных тестов.

Теперь детально.

Промт для автогенерации проверок

У нас есть своя, годами испытанная, структура проверок с правиами. Мы превратили ее в промт и добились того, что при автосоздании в проверках корректно заполненяются следующие поля:

• названия (по формату);

• наполнение и разбиение на шаги (по формату и техникам тест-дизайна);

• разбиение на тесты (по формату);

• расположение в папках;

• ссылки на требования;

• лейблы (автоматически и задаваемые вручную);

• оценка теста;

• приоритет.

Подготовка нашего промта

Специальный скрипт вытягивает данные из Figma/Confluence/Swagger и подставляет их в заглушки шаблона:

• {{REQ_CONTENT}} — требования;

• {{SWAGGER_CONTENT}} — swagger;

• {{TESTS_FROM_FIGMA_CONTENT}} — проверки, созданные по Figma

Шаблон хранится как вложенный md-файл и состоит из шести основных блоков:

1. Бизнес-требования по фиче.

2. Swagger-спецификация.

3. Тесты на дизайн.

4. Правила генерации тестов.

5. Структура проверок и их содержимое.

6. Самопроверка.

Пример промта

Требования и Swagger

Преобразуем требования в виде одного целого md-файла с описанием структуры и списком содержимого файлов.

Требования из confluence выгружаем в проект и конвертируем в .md.

Проверки, созданные по фигме

JSON-формат проверок

Мы пробовали работать с CSV, но с ним LLM редко выдавали качественный результат, поэтому мы перешли к более удобному формату:

Правила

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

Запреты

Примеры

Мы попробовали и знаем, что примеры отлично работают. Поэтому мы решили наполнить ими промт. И это помогло получить (и получать впоследствии) стабильный качественный результат.

Судя по собственному опыт и информации из Antropic, Google и других, мы поняли, что корректно составленный промт состоит из следующих частей:

• контекста — цель задачи, контекст, дополнительные обстоятельства;

• примеров — желаемый стиль или формат вывода;

• ограничений — чёткий формат, длина и другие требования к выходным данным;

• определения роли или тона ИИ.

Сначала планирование, потом реализация

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

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

Модели для автогенерации проверок

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

• gemini-2.5-pro; 

• o3;

• claude-4.

Пример проверок по одной из фичей

Компонентные

Сценарные

Что получилось

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

Из всего этого мы собрали MVP за 60 часов. Да, он небольшой — кое-чего не хватает, но уже сейчас он экономит время и дает ребятам заниматься куда более важными вопросами тестирования.

Проект писали с помощью ИИ. Основная команда состояла из двух QA. Для ревью тестов и шлифовки промптов подключили ещё четверых ребят из отдела качества.

В общем, мы сделали инструмент сами и для себя. Это помогло нам ускориться в 5 раз и вырасти в качестве:

• тесты теперь оформляются за минуты, а не часы или дни;

• QA больше не распыляются на копипаст и поля Xray — время уходит на разбор самой фичи и бизнес-логики;

• освободив голову от рутины, инженеры глубже исследуют продукт, ловят нестандартные сценарии и критические пограничные условия;

• мелкие, но чувствительные баги ловятся до релиза, что поднимает общее восприятие качеств

• тесты теперь оформляются за минуты, а не часы или дни;

«Есть ещё одно преимущество, которое идёт рука об руку с избавлением от UI-рутины. Когда проверки не приходится переписывать вручную, уровень стресса резко падает. Достаточно попросить LLM, и она мгновенно перегенерирует тесты. Если не понравилось, просим ещё раз и получаем новую версию. 

А вот вручную это мучительно. Каждую правку нужно заново продумывать с точки зрения тест-дизайна, поэтому ревью растягивается. Переписать всего 5 проверок — минимум час работы».

© Влад, QA в Surf.

Пример времязатрат с ручным написанием проверок и при помощи ИИ

• 3 фичи

• 61 компонентный тест 

• 34 сценарные проверки

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

Как мы сделали автогенератор так быстро

• Микроитерации — каждый день! выкатывали новую версию и сразу собирали обратную связь.

• API-first — ни одного клика мышью: все шаги через REST-запросы - дорабатывать проще и быстрее.

• Одна точка настройки — файл config.py: токены и правила фильтрации экранов - и больше ничего.

• Одна точка запуска — RUNBOOK.

Что мы сознательно пропустили, чтобы ускориться

1. Мы не стали делать полноценный фронтенд и прямую API-интеграцию с LLM. И это сэкономило недели разработки.

2. Вместо сложного интерфейса брали live-логи: в реальном времени видно ошибки, статус и итог операции.

3. Добавили лёгкое веб-окно для выбора требований, которые пойдут в промпт — а это, между прочим, был самый трудоёмкий этап, который требовал визуального контроля.

4. RUNBOOK в Markdown — запуск скрипта прямо по мере чтения инструкции.

Такой подход не только позволил быстро выпустить MVP, но и дал возможность тщательно проревьюить крупные, критически важные части процесса. А это очень важно и полезно.

Риски и ограничения у нашего подхода

Недостаточное покрытие и ошибки

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

Утечка NDA-данных

Тут используем Cursor с privacy mode, API-версии моделей по согласованию с клиентом.

Изменений требований или дизайна

Если сейчас такое происходит, то перегенерируем тесты полностью.

Большая и сложная фича для ИИ

Корректируем созданные шаблоны вручную.

Что дальше

1. Хотим расширить охват функций. Геолокация, пуши, пермишены и диплинки ещё не покрыты.

2. После — обогатить промпт. Вливаем нюансы проверок и типовые чек-листы прямо в шаблон, чтобы ИИ генерировал более точные тесты.

3. Также нужно параллелить рендер — будем грузить скриншоты параллельно, чтобы ускорить разбор макетов.

4. Будем фильтровать по платформе. Это значит, что в мультиплатформенных проектах (мобайл, веб, планшет) будем экспортировать только нужный вариант дизайна.

5. Ну и будем поддерживать датасеты. Храним типовые входные данные и ошибки одной строкой — это компактнее, чем ручные кейсы.

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