Всем привет! Меня зовут Катя, я QA Tech Lead в MD Audit.

Сегодня бы не будем говорить о банальностях типа чек-листов и тест кейсах. Эта база, я о ней уже писала коротко и даже длинно. Речь пойдет именно о тех интересных вариациях использования нейросети, которые я на Хабре не видела или не нашла.

1. Карманный аналитик

Это способ подойдет тем, у кого в компании есть аналитики, они что-то пишут и это не «сделай также как там», а как там уже одному богу сеньору известно.

Суть подхода в том, что мы отправляем нейросети задачу или тз. Наиболее это актуально для больших фич, где описание логики занимает несколько страниц. И просим нейросеть побыть нашим карманным аналитиком.

А зачем нам это надо если можно кошмарить в чате живых аналитиков и даже разработчиков вопросами?

Ответ банальный — лучше разобраться в задаче. Исключить лишние коммуникации. Нащупать в тз слабые места. Так как в промте мы четко обозначаем — если чего того в тз не описано, скажи об этом прямо. Ничего не придумывая.

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

Ты бизнес-аналитик. Прочитай текст ТЗ ниже.
Составь список бизнес-правил и проверок, которые описаны в документе.
Если логика не полная или противоречит себе — укажи это явно, ничего не придумывая.

Почему работает: потому что ИИ помогает “вытрясти” неочевидные пробелы, которые обычно всплывают только на регрессе.

2. Личный секретарь

Это скорее будет хорошим поинтом для ментора или лида, но лично я использую это и как тестировщик.

Особенно этот метод хорошо лечит такие симптомы как «мы же это обсуждали» с осложнениями «я не помню такого».

Всего-то нужно включить запись на встрече. Отправить для перевода в текст и у вас уже есть список кто кому и что должен.

Аналитику это может помочь быстро внести правки в документацию. Тестировщику зафиксировать какие-то договорённости с кем угодно.

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

Ты помощник по организации задач.
На основе текста встречи составь краткое summary с основными решениями, сроками и ответственными.

Почему полезно: помогает не искать “кто обещал поправить API до среды” и не спорить, что “мы не договаривались”.

3. Ревью тестовой документации

Это опять же применимо как к лидам, так и к обычным тестировщикам.

Процесс ревью есть не у всех, но полезен он точно будет любому тестировщику.

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

• Даем контекст — тз, описание задачи.

• Даем документацию — чек-лист, тест-кейс.

• Пишем промт (пример ниже)

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

Ты QA-лид. Проведи ревью тест-кейса ниже.
Проверь полноту шагов, корректность ожидаемых результатов и наличие предусловий.
Если чего-то не хватает — перечисли, что нужно добавить.

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

Почему важно: ИИ не заменит ревью от живого тестировщика, но помогает увидеть “слепые зоны”.

4. Матрица покрытия требований

Это опять же полезная тема для тех у кого есть тз. И может использоваться как лидом в приемочном тестировании, так и обычным тестировщиком на финале регрессе перед деплоем фичи на прод.

В отличие от нашего любимого чек-листа, матрица делает список требований из ТЗ, которые не должны отвалиться по дороге до клиента. В матрице нет большой вариации проверок. Но она помогает проверить, что важные функции все еще работают как надо.

Ты QA-инженер. Прочитай ТЗ ниже и составь матрицу покрытия требований.
Колонки: {ID требования}, {Описание}, {Есть тесты (Да/Нет)}, {Комментарий}.

Почему работает: даёт быстрый способ проверить, что ни одно требование не потерялось между “написали” и “протестировали”.

5. Импорт в TMS

Если вы уже занимаетесь созданием тестовой документации с ИИ, то вам наверняка знакома проблема переноса данных из нейро помощника в систему управления тестированием.

Казалось бы, вот мы уже автоматизировали создание документации, что еще надо? Но сам по себе перенос тоже очень муторный процесс и зачем он нам нужен.

В большинстве современных TMS есть импорт. Обычно принцип импорта одинаковый — данные из ��ксель шаблона загружаются в TMS и вот они уже на месте. Что спасает нас от рутинного копирования данных из одного места в другое.

Пример промта для импорта в TMS TestIT

Ты QA-инженер. Выведи тесты в формате таблицы (Excel) для импорта.
Колонки:
{Наименование}, {Шаги}, {Ожидаемый результат}

Правила:

1. {Наименование} — только название теста, один раз на тест.

2. {Шаги} — последовательные действия (в UI или API). Пример: "Выполнить запрос POST /endpoint с входными данными".

3. {Ожидаемый результат} — проверяемые факты:

   • статус/ответ системы,

   • ключевые поля,

   • важные значения.

Не придумывай ничего сверх указанного контекста.
Каждый тест — отдельная строка.

Почему важно: потому что автоматизация без импорта — как баги без описания шагов. Вроде существуют, но зачем.

Итоги

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

Спасибо, что дочитали. Буду рада, если поделитесь еще интересными способами использовании ИИ в работе в комментариях.

Если статья была вам полезна,  буду рада видеть в моем Телеграм-канале.

В следующих статьях разберем:

1) Какая модель АИ лучше справится с рутинными задачами именно в тестировании? Сравнение ChatGPT и Claude.

2) Матрица покрытия требований. Почему она может спаст�� ваш релиз от критичных багов?