Привет! Я — Таня Рашидова, 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 в тестировании — делитесь своими приёмами в комментариях. Чем больше практик, тем быстрее индустрия выйдет из состояния «я всё сам руками» в нормальный, взрослый автоматизированный подход.