Home

Автор: Екатерина Гаврилова

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

В прошлой статье я рассказала, какой подход помог мне сделать ИИ напарником по тестированию и поделилась формулой хорошего промпта для QA.

Но остаётся вполне логичный вопрос — А какая вообще разница? Ну попрошу я написать ИИ тесты без контекста. Что изменится в полученном результате?

Ведь где-то внутри всегда сидит ленивая версия нас и шепчет «И так сойдет».

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

Чтобы в конце получить классные и подробные тесты вроде таких:

Мы возьмём одну и ту же задачу и сравним:

• «плохой» промпт в стиле «ну ты же умный, сам догадаешься»;

• «нормальный» промпт по формуле;

• и промпт с обучающим примером, где мы прямо объясняем ИИ, как у нас всё устроено.

Напомню формулу, которой я пользуюсь сама и рекомендую вам:

Роль → Задача → Контекст → Формат вывода.

• Роль: кто именно «говорит» — QA‑инженер, тимлид, backend-разработчик.

• Задача: что нужно получить — тесты, чек-лист, баг-репорт, ревью.

• Контекст: детали системы — поля, API, роли, ограничения.

• Формат вывода: таблица, JSON, Markdown, структура для TMS.

А теперь давайте посмотрим, как это работает на практике.

Пример № 1: форма логина

Начнём с самого простого и знакомого — обычного окна авторизации.

Плохой промпт

Представим, что мы устали, нам лень, спешим, поэтому пишем ИИ такой запрос:

Напиши тест-кейсы для формы логина.

ИИ в таком случае напишет что-то такое:

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

• контекста нет,

• предусловия абстрактные,

• шаги общие,

• результаты туманные,

• негативных и граничных сценариев нет.

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

1. Отсутствие контекста

Опытный тестировщик всегда задаст себе самый главный вопрос — что я тестирую и зачем? Разберем это подробнее в рамках нашей задачи тестирования формы авторизации.

• Что это за форма и где она: web, мобилка, десктоп? браузеры, устройства?

• Какая авторизация вообще подразумевается: email/логин/телефон/ЕЦП?

• Есть ли у нас ограничения по попыткам, блокировка, капча, двухфакторка?

2. Предусловия на уровне «пользователь зарегистрирован»

Напомню, данные в столбце «Предусловия» выглядят так:

«Пользователь зарегистрирован»

Можно ли назвать такое предусловием? Прежде чем сказать «да», опомнитесь, ведь этим ртом вы здороваетесь с коллегами.

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

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

• Кто создаёт этого пользователя и как?

• Какое у него окружение, роль, статус (активен/заблокирован)?

• Нужен ли ему подтверждённый email или достаточно телефона?

3. Шаги слишком общие

Примерно в таком духе:

1. Открыть форму логина

2. Ввести корректный логин/пароль

3. Нажать «Войти»

Что здесь не хватает:

• где именно открыть: URL, путь в приложении, контекст (гость/сессия/кэш)?

• «корректный логин» — это какой? email? номер? длина? формат?

• нет ни одного шага про проверку состояния до/после (куки, сессии, редиректы).

Такой тест ничего важного не проверит и багов им не найти. А тогда вопрос — зачем он вообще нужен?

4. Ожидаемый результат в стиле «Не упало и слава Богу»

Напомню ОР от ИИ:

«Пользователь успешно авторизован и перенаправлен на главную страницу»

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

• появился токен/сессионная кука?

• как исчезла форма логина?

• чем отличается главная страница гостя и авторизованного пользователя?

5. Никакого привязки к системе и окружению

Если просто взять эту таблицу и отнести в проект, через месяц никто не вспомнит:

• для какого продукта это писалось;

• на каких стендах проверять;

• какие данные использовать.

Это такой «универсальный шаблон для любой формы логина», а не реальные тесты под конкретную систему.

Ну и самое главное. Ничего важного эти тесты не проверяют. А как же пустые поля, ввод неверных данных, блокировка авторизации после N попыток и так далее?

Промт по формуле Роль → Задача → Контекст → Формат вывода.

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

Контекст системы: «Побрякушки Катюшки»

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

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

Как устроена регистрация

• Регистрация через форму «Создать аккаунт». Открывается нажатием на кнопку Создать аккаунт на главном экране авторизации.

  Регистрация

  • Форма «Создать аккаунт».

  • Поля:

    • Email — обязательное, уникальное, формат email.

    • Пароль — обязательное, от 8 до 32 символов.

    • Имя — необязательное, до 50 символов.

    • чекбокс «Согласен с условиями и политикой обработки данных» — обязателен.

  • После отправки формы:

    1. Если всё ок — создаётся аккаунт в статусе «Не подтверждён».

    2. На email уходит письмо с ссылкой подтверждения.

    3. После перехода по ссылке статус меняется на «Активен».

Удаление аккаунта

Аккаунт может быть удалён двумя способами:

1. Сам пользователь:

   • в личном кабинете есть кнопка «Удалить аккаунт»;

   • перед удалением показываем подтверждение;

   • после удаления авторизация невозможна, при попытке входа показываем сообщение:
     
     «Аккаунт не найден. Проверьте данные или зарегистрируйтесь снова».

2. Администратор:

   • в админке есть действие «Удалить аккаунт»;

   • после удаления поведение при логине такое же, как выше.

Вход (логин)

• Форма «Войти»:

  • Email, Пароль, чекбокс «Запомнить меня»;

  • ссылки «Забыли пароль?» и «Создать аккаунт».

• Логика:

  • для статуса «Активен» — вход разрешён;

  • для «Не подтверждён» — вход запрещён, сообщение:
    «Пожалуйста, подтвердите email. Мы отправили вам письмо со ссылкой»;

  • если аккаунта с таким email не существует (никогда не было или был удалён) — сообщение:
    «Аккаунт не найден. Проверьте данные или зарегистрируйтесь»;

  • при неверной паре email/пароль — «Неверный логин или пароль».

• После успешного входа:

  • редирект в личный кабинет /profile;

  • в шапке отображается имя или email пользователя;

  • при попытке открыть /login авторизованному пользователю — редирект в /profile.

Вот это и есть тот дополнительный контекст, которого обычно не хватает ИИ.

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

Преобразуем описание системы в идеальный промт

Ты инженер по качеству (QA), специализирующийся на web.

Задача:
На основе описания системы ниже сгенерируй тест-кейсы для проверки формы логина
интернет-магазина украшений «Побрякушки Катюшки».

Контекст системы:
- Это интернет-магазин украшений ручной работы.
- Регистрация через форму "Создать аккаунт":
  - поля: Email (обязательное, уникальное), Пароль (8–32 символа), Имя (необязательное),
    чекбокс согласия с условиями.
  - после успешной регистрации аккаунт создаётся в статусе "Не подтверждён",
    на email уходит письмо со ссылкой подтверждения;
  - после перехода по ссылке из письма статус меняется на "Активен".
- Аккаунт может быть удалён:
  - самим пользователем из личного кабинета (кнопка "Удалить аккаунт");
  - администратором через админку.
  После удаления логин невозможен, при попытке входа показывается:
  "Аккаунт не найден. Проверьте данные или зарегистрируйтесь".
- Вход (логин) выполняется через форму "Войти":
  - поля: Email, Пароль, чекбокс "Запомнить меня";
  - ссылки "Забыли пароль?" и "Создать аккаунт".
- Логика авторизации:
  - статус "Активен" — вход разрешён;
  - статус "Не подтверждён" — вход запрещён, сообщение:
    "Пожалуйста, подтвердите email. Мы отправили вам письмо со ссылкой";
  - если аккаунта с таким email нет (никогда не существовал или был удалён) —
    сообщение: "Аккаунт не найден. Проверьте данные или зарегистрируйтесь";
  - при неверной паре email/пароль — сообщение:
    "Неверный логин или пароль".
- После успешного входа пользователь попадает в личный кабинет /profile,
  в шапке отображается его имя или email.
  При повторном открытии /login авторизованный пользователь перенаправляется в /profile.

Формат вывода:
Верни результат в виде таблицы с колонками:
{Наименование}, {Предусловие}, {Тестовые данные}, {Шаги},
{Ожидаемый результат}, {Статус аккаунта}, {Платформа}, {Тип теста (Positive/Negative/Edge/Localization)}.

Требования к детализации:
- В "Предусловие" явно указывай статус аккаунта (Активен / Не подтверждён / Аккаунт удалён)
  и кто его удалил, если это важно (пользователь / администратор).
- В "Тестовые данные" приводи конкретные значения email и пароля
  (валидные, невалидные, несуществующий email, пустые поля, слишком длинные значения).
- В "Шаги" описывай действия так, чтобы другой тестировщик мог выполнить их без догадок.
- В "Ожидаемый результат" указывай:
  - какое сообщение отображается;
  - куда происходит редирект;
  - что видно в шапке и на странице.
  Не используй общие формулировки вроде "авторизация успешна" без конкретики.

Обязательно включи:
- позитивные сценарии (успешный вход для активного аккаунта, с/без "Запомнить меня");
- попытки входа для "Не подтверждённого" аккаунта;
- попытки входа для удалённого аккаунта (удалил сам пользователь / удалил админ);
- сценарии "неверный пароль", "несуществующий email", пустые поля;
- граничные значения для длины пароля и формата email;
- сценарии локализации (RU/EN тексты для основных сообщений).

На выходе мы получаем уже такой результат:

Если интересно, можно посмотреть полный набор тестов в эксель.

Почему же такой результат лучше?

1. Появилась реальная модель системы, а не абстрактный «логин зарегистрированного пользователя»

Напомню, в старом ответе ИИ тесты были такими:

• «Успешный вход с валидными данными»

• «Неверный пароль»

• «Пустые поля»

• максимум — «Проверка чувствительности к регистру»

И нигде не чувствовалось, что за система за этим стоит.

В твоих новых тестах прямо читается контекст «Побрикушек Катюшки»:

• статусы аккаунта: Активен, Не подтверждён, Аккаунт удалён (удалил пользователь) — и они участвуют в предусловиях;

• есть сценарий, когда авторизованный пользователь открывает /login и получает редирект;

• есть различие между «неподтверждённым» и «удалённым».

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

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

Раньше:

«Пользователь зарегистрирован»

Сейчас, по скрину, уже так:

• «Аккаунт Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript существует, статус Активен, пароль ValidPass1»

• «Аккаунт Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript существует, статус Не подтверждён, пароль Unconf123»

• «Аккаунт Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript был ранее создан и удалён пользователем»

То есть в предусловиях теперь есть:

• конкретный email;

• конкретный статус аккаунта;

• иногда — информация, кто его удалил.

Это важно, потому что:

• тест можно поднять на любой стенд, просто подложив эти данные;

• любой другой тестировщик понимает, в какой ситуации находится пользователь.

3. Появился отдельный столбец «Тестовые данные» с конкретикой

Это огромная разница.

Вместо размытых формулировок «валидный логин и пароль» теперь есть конкретика:

Email: Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript , Пароль: ValidPass1!

Отдельный столбец вынуждает как ИИ, так и человека подумать о данных, в отличии от расплывчатых формулировок “корректные / некорректные”.

4. Шаги стали реально воспроизводимыми

В старом ответе ИИ было что-то вроде:

«Открыть форму логина. Ввести корректные данные. Нажать Войти.»

Сейчас в таблице уже:

1. Открыть /login.

2. Ввести Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript .

3. Ввести ValidPass1!.

4. Убедиться, что чекбокс «Запомнить меня» не отмечен / отмечен.

5. Нажать «Войти».

6. После входа снова открыть /login в той же сессии/браузере (для кейса с редиректом).

То есть:

• шаги разные для разных сценариев (с remember me, с редиректом, с неверным паролем);

• нет «магии», каждый шаг — конкретное действие.

Это то, чего не было в первом «ленивом» ответе ИИ, но что важно для тестов в реальном жизненном цикле любого сервиса и приложения.

5. Ожидаемые результаты стали проверками, а не желаниями

Вот тут самый большой скачок качества.

Вместо абстрактного:

«Авторизация успешна»
«Отображается сообщение об ошибке»

ты теперь видишь:

• куда конкретно происходит редирект (/profile или остаёмся на /login);

• что именно отображается:

  • текст ошибки: «Пожалуйста, подтвердите email…»;

  • текст: «Аккаунт не найден. Проверьте данные или зарегистрируйтесь»;

  • отсутствие/наличие формы логина;

  • отображение имени/почты в шапке;

• что не должно отображаться (форма логина не показывается для авторизованного).

То есть ожидаемый результат теперь = набор наблюдаемых фактов, а не «итоговое настроение тестировщика».

6. Отражены все важные состояния аккаунта

Покрыты все описанные статусы акаунта, что является прямой заслугой хорошо написанного контекста — ИИ это подхватил и перенёс в тесты.

У «сырого» первого варианта тестов такого вообще не было — он не знает про статусы, если ему их не рассказать.И поэтому даже не задумывается, что в системе аккаунт без какого-то статуса существовать не может.

Общий вывод

В первом случае ИИ выдал «универсальные тесты для любой формы логина». Смысла в таких тестах в реальном проекте мало: они не проверяют ничего конкретного, их не автоматизировать и ещё сложнее использовать как инструмент для поиска багов.

После того как мы добавили контекст системы и нормальный промт, тесты стали:

• привязаны к конкретным статусам аккаунта;

• с явными тестовыми данными;

• с воспроизводимыми шагами;

• с понятными ожидаемыми результатами (куда редиректит, какой текст отображается, что видно в интерфейсе).

То есть мы превратили ИИ из генератора общих идей в ассистента, который пишет тесты так, как их пишет живой тестировщик: с пониманием логики системы.

Такие тесты уже можно реально использовать на проекте:

• занести их в TMS;

• прогнать по тестовому стенду;

• написать по ним автотесты;

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

Спасибо, что дочитали до конца!

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

Там я планирую делиться новыми статьями на тему ИИ и тестирования, а также новостями по моему курсу "ИИ в тестировании". В нем я планирую на практике помочь научиться описанному подходу.

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

1. Какие рутинные задачи можно решить с помощью обученного АИ помощника в тестировании.

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