Привет! Я — Таня Рашидова, QA тимлид в KODE. Я думала, что все тестировщики уже давно внедрили AI в свою повседневную работу. Но недавно выяснила, что многие либо не пробовали, либо попробовали, запутались, не получили вау-результата и забросили. Раз уж я уже объяснила, как использую AI в работе нескольким коллегам, решила оформить опыт в статью. Может, кому-то из вас она сэкономит время и силы.

Лень — двигатель прогресса (в тестировании тоже)

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

Когда я окончательно устала писать всё вручную, решила попробовать использовать AI. В моём случае это была DeepSeek. Первые попытки были… ну, так себе. Но потом я нащупала систему, с помощью которой AI реально помогает, и теперь она у меня работает почти как конвейер. 

Сразу оговорка: не верьте рилсам, где всё делается в один промт. Это магия монтажа. Реальность — это итерации. Делим задачу на части, уточняем, добавляем примеры, учим AI на ходу. Но результат — стоит того.

Для примера — простой экран

Для создания алгоритма ��озьмем не самый сложный экран, где есть много кнопочек. Это поможет настроить AI, показать ему, какой бывает функционал, какие паттерны заложены. 

Шаг 1. Постановка задачи

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

AI быстро генерирует первый вариант чек-листа. Обычно это базовые проверки:

  • отображение кнопок,

  • реакция на нажатие,

  • переходы по экранам.

Результат далёк от идеального, но это и не нужно — главное, чтобы был старт. Первый черновик даёт опору.

Шаг 2. Уточнение требований

Вот тут начинается самое интересное. Я перечитываю то, что сгенерировал AI, и вижу, что он:

  • часто забывает про кнопки «Назад» и «Закрыть»;

  • не различает заголовки и интерактивные элементы;

  • не учитывает поведение иконок;

  • может игнорировать нестандартные паттерны.

Я пишу ему фидбек:

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

Шаг 3. Форматирование и структура

Когда сам по себе чек-лист более-менее ок, я прошу AI привести его к нужному формату. Например:

  • у нас есть уровни декомпозиции: сначала разделы, потом шаги внутри;

  • каждый пункт должен быть пронумерован;

  • текст — в определённом стиле (без «проверьте, что…» и прочего лишнего);

  • структура: ID | Screen | Expected Result | Priority | Behavior.

Чтобы AI понял, как надо, я просто загружаю в чат шаблон или PDF с требованиями, и говорю: «делай так». К сожалению, поделиться нашими требованиями я не могу, но уверена, у вас есть собственные для каждого проекта. 

Если что-то идёт не так — даю примеры. Прямо пишу:

«Ты сделал:
1. Проверить отображение списка
А нужно:
UI-LST-001 |Экран Настроек | Элемент “Список” отображается корректно | High | Positive»

Шаг 4. Добавление атрибутов

Следующий этап — добавляем метаинформацию. AI не всегда сам понимает, какие атрибуты нужны. У нас, например, в каждой проверке должны быть:

  • Priority (High / Medium / Low),

  • Behavior Type (Positive / Negative),

  • Component (для связи с модулями),

  • иногда — Link to requirement.

Я либо пишу руками, что не хватает, либо показываю: «Вот ты сделал X, а должно быть Y». Часто использую фразу:

«Ты делаешь хорошо, но мне нужно, чтобы ты делал, как на картинке»

Показываю скрин. DeepSeek на это реагирует нормально.

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

Шаг 5. Экспорт в нужный формат

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

Самый удобный — CSV. AI сам генерирует таблицу, где:

  • каждая строка — отдельная проверка,

  • все поля — на месте,

  • структура — готова для импорта в TestRail, Qase или Allure TestOps.

Можно, конечно, и в Markdown или JSON — зависит от того, куда дальше идёт документация.

Рефлексия и нюансы

Первый раз у меня ушло где-то 40 минут — от скрина до готового чек-листа. Но теперь, когда AI обучен и диалог сохранён, всё делается в 3–5 раз быстрее.

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

Что важно учесть

AI редко даёт идеальный результат с первого раза. Каждый шаг — это цикл: прочитать, поправить, уточнить, сверить с ожиданиями. Без этого не обойтись.

Слепо доверять AI не стоит. Он полезный, но сыроватый инструмент. Чтобы поймать косяки, нужно понимать, как выглядит хороший результат. Поэтому AI — для тех, кто уже умеет писать документацию руками.

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

Юридические риски — тоже важно учитывать. Если работаете под NDA, не сливайте реальные данные в AI-инструменты. Это может считаться разглашением. Лучше перестраховаться и обезличить чувствительную информацию. 

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

Если уже используете AI в тестировании — делитесь своими приёмами в комментариях. Чем больше практик, тем быстрее индустрия выйдет из состояния «я всё сам руками» в нормальный, взрослый автоматизированный подход.