Всем привет! Меня зовут Катя, я QA Tech Lead в MD Audit.
Сегодня бы не будем говорить о банальностях типа чек-листов и тест кейсах. Эта база, я о ней уже писала коротко и даже длинно. Речь пойдет именно о тех интересных вариациях использования нейросети, которые я на Хабре не видела или не нашла.
1. Карманный аналитик
Это способ подойдет тем, у кого в компании есть аналитики, они что-то пишут и это не «сделай также как там», а как там уже одному богу сеньору известно.
Суть подхода в том, что мы отправляем нейросети задачу или тз. Наиболее это актуально для больших фич, где описание логики занимает несколько страниц. И просим нейросеть побыть нашим карманным аналитиком.
А зачем нам это надо если можно кошмарить в чате живых аналитиков и даже разработчиков вопросами?
Ответ банальный — лучше разобраться в задаче. Исключить лишние коммуникации. Нащупать в тз слабые места. Так как в промте мы четко обозначаем — если чего того в тз не описано, скажи об этом прямо. Ничего не придумывая.
Пример промта:
Ты бизнес-аналитик. Прочитай текст ТЗ ниже.
Составь список бизнес-правил и проверок, которые описаны в документе.
Если логика не полная или противоречит себе — укажи это явно, ничего не придумывая.
Почему работает: потому что ИИ помогает “вытрясти” неочевидные пробелы, которые обычно всплывают только на регрессе.
2. Личный секретарь
Это скорее будет хорошим поинтом для ментора или лида, но лично я использую это и как тестировщик.
Особенно этот метод хорошо лечит такие симптомы как «мы же это обсуждали» с осложнениями «я не помню такого».
Всего-то нужно включить запись на встрече. Отправить для перевода в текст и у вас уже есть список кто кому и что должен.
Аналитику это может помочь быстро внести правки в документацию. Тестировщику зафиксировать какие-то договорённости с кем угодно.
И главное! Минимальное участие человека. Ну за исключением участия в созвонах. Это пока нейросети за нас делать не умеют, но мы надеемся и верим в светлое будущее.
Ты помощник по организации задач.
На основе текста встречи составь краткое summary с основными решениями, сроками и ответственными.
Почему полезно: помогает не искать “кто обещал поправить API до среды” и не спорить, что “мы не договаривались”.
3. Ревью тестовой документации
Это опять же применимо как к лидам, так и к обычным тестировщикам.
Процесс ревью есть не у всех, но полезен он точно будет любому тестировщику.
На нашем проекте ревью позволяет подсказать узкие места в продукте, которые обычно опытные сотрудники знают лучше. Но в любой случае даже проверив самого себя с помощью виртуального тимлида можно найти что-то полезное.
Даем контекст — тз, описание задачи.
Даем документацию — чек-лист, тест-кейс.
Пишем промт (пример ниже)
По итогу нейросеть может подсказать как минимум несколько хороших проверок.
Ты QA-лид. Проведи ревью тест-кейса ниже.
Проверь полноту шагов, корректность ожидаемых результатов и наличие предусловий.
Если чего-то не хватает — перечисли, что нужно добавить.
Это только пример промта, в который вы можете включить свои частые ошибки тестировщика или какие-то базовые принципы тестовой документации принятой на проекте.
Почему важно: ИИ не заменит ревью от живого тестировщика, но помогает увидеть “слепые зоны”.
4. Матрица покрытия требований
Это опять же полезная тема для тех у кого есть тз. И может использоваться как лидом в приемочном тестировании, так и обычным тестировщиком на финале регрессе перед деплоем фичи на прод.
В отличие от нашего любимого чек-листа, матрица делает список требований из ТЗ, которые не должны отвалиться по дороге до клиента. В матрице нет большой вариации проверок. Но она помогает проверить, что важные функции все еще работают как надо.
Ты QA-инженер. Прочитай ТЗ ниже и составь матри��у покрытия требований.
Колонки: {ID требования}, {Описание}, {Есть тесты (Да/Нет)}, {Комментарий}.
Почему работает: даёт быстрый способ проверить, что ни одно требование не потерялось между “написали” и “протестировали”.
5. Импорт в TMS
Если вы уже занимаетесь созданием тестовой документации с ИИ, то вам наверняка знакома проблема переноса данных из нейро помощника в систему управления тестированием.
Казалось бы, вот мы уже автоматизировали создание документации, что еще надо? Но сам по себе перенос тоже очень муторный процесс и зачем он нам нужен.
В большинстве современных TMS есть импорт. Обычно принцип импорта одинаковый — данные из эксель шаблона загружаются в TMS и вот они уже на месте. Что спасает нас от рутинного копирования данных из одного места в другое.
Пример промта для импорта в TMS TestIT
Ты QA-инженер. Выведи тесты в формате таблицы (Excel) для импорта.
Колонки:
{Наименование}, {Шаги}, {Ожидаемый результат}Правила:
{Наименование} — только название теста, один раз на тест.
{Шаги} — последовательные действия (в UI или API). Пример: "Выполнить запрос POST /endpoint с входными данными".
{Ожидаемый результат} — проверяемые факты:
статус/ответ системы,
ключевые поля,
важные значения.
Не придумывай ничего сверх указанного контекста.
Каждый тест — отдельная строка.
Почему важно: потому что автоматизация без импорта — как баги без описания шагов. Вроде существуют, но зачем.
Итоги
Эти промты не заменят тестировщика. Но если использовать их с умом, можно освободить пару часов, чтобы наконец заняться любимым делом, кидать мемы в рабочий чат.
Спасибо, что дочитали. Буду рада, если поделитесь еще интересными способами использовании ИИ в работе в комментариях.
Если статья была вам полезна, буду рада видеть в моем Телеграм-канале.
В следующих статьях разберем:
1) Какая модель АИ лучше справится с рутинными задачами именно в тестировании? Сравнение ChatGPT и Claude.
2) Матрица покрытия требований. Почему она может спасти ваш релиз от критичных багов?
