Плохой промпт vs хороший: как контекст меняет тесты ИИ

Всем привет! Меня зовут Катя и я 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. Предусловия перестали быть абстрактными

Раньше:

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

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

• «Аккаунт active_user@example.com существует, статус Активен, пароль ValidPass1»

• «Аккаунт unconfirmed_user@example.com существует, статус Не подтверждён, пароль Unconf123»

• «Аккаунт deleted_by_user@example.com был ранее создан и удалён пользователем»

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

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

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

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

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

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

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

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

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

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

Email: active_user@example.com, Пароль: ValidPass1!

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

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

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

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

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

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

2. Ввести active_user@example.com.

3. Ввести ValidPass1!.

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

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

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

То есть:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Общий вывод

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: habr.com