Всем привет! Меня зовут Катя и я QA Tech lead в MD Audit.
В прошлой статье я рассказала, какой подход помог мне сделать ИИ напарником по тестированию и поделилась формулой хорошего промпта для QA.
Но остаётся вполне логичный вопрос — А какая вообще разница? Ну попрошу я написать ИИ тесты без контекста. Что изменится в полученном результате?
Ведь где-то внутри всегда сидит ленивая версия нас и шепчет «И так сойдет».
В этой статье я покажу, почему, зная формулу «Роль → Задача → Контекст → Формат», нужно использовать именно её, как бы ни хотелось отправить ИИ что-то в духе: «Напиши тесты для логина, пожалуйста» и надеяться на лучшее.
Чтобы в конце получить классные и подробные тесты вроде таких:
Мы возьмём одну и ту же задачу и сравним:
«плохой» промпт в стиле «ну ты же умный, сам догадаешься»;
«нормальный» промпт по формуле;
и промпт с обучающим примером, где мы прямо объясняем ИИ, как у нас всё устроено.
Напомню формулу, которой я пользуюсь сама и рекомендую вам:
Роль → Задача → Контекст → Формат вывода.
Роль: кто именно «говорит» — QA‑инженер, тимлид, backend-разработчик.
Задача: что нужно получить — тесты, чек-лист, баг-репорт, ревью.
Контекст: детали системы — поля, API, роли, ограничения.
Формат вывода: таблица, JSON, Markdown, структура для TMS.
А теперь давайте посмотрим, как это работает на практике.
Пример № 1: форма логина
Начнём с самого простого и знакомого — обычного окна авторизации.
Плохой промпт
Представим, что мы устали, нам лень, спешим, поэтому пишем ИИ такой запрос:
Напиши тест-кейсы для формы логина.
ИИ в таком случае напишет что-то такое:
На первый взгляд всё неплохо: есть таблица, позитивные кейсы, шаги. Но если смотреть глазами живого опытного тестера сразу видно, что ИИ допустил типичные ошибки джуна:
контекста нет,
предусловия абстрактные,
шаги общие,
результаты туманные,
негативных и граничных сценариев нет.
Это тесты «по форме», а не по сути. Разберем по пунктам почему это плохо и перейдем к примеру, где уже результат будет в категории «хорошо».
Отсутствие контекста
Опытный тестировщик всегда задаст себе самый главный вопрос — что я тестирую и зачем? Разберем это подробнее в рамках нашей задачи тестирования формы авторизации.
Что это за форма и где она: web, мобилка, десктоп? браузеры, устройства?
Какая авторизация вообще подразумевается: email/логин/телефон/ЕЦП?
Есть ли у нас ограничения по попыткам, блокировка, капча, двухфакторка?
2. Предусловия на уровне «пользователь зарегистрирован»
Напомню, данные в столбце «Предусловия» выглядят так:
«Пользователь зарегистрирован»
Можно ли назвать такое предусловием? Прежде чем сказать «да», опомнитесь, ведь этим ртом вы здороваетесь с коллегами.
Фактически же то что мы видим в предусловии ИИ не предусловие по своей сути, а скорее желание. Нам бы, конечно, хотелось чтобы он был зарегистрирован, но вообще-то до этого еще надо дожить.
В реальном жизненном цикле приложения и сансаре бытия до этого момент есть еще важные действия предшествующие регистрации от которых вообще зависит как человек попадет на тестируемую нами форму:
Кто создаёт этого пользователя и как?
Какое у него окружение, роль, статус (активен/заблокирован)?
Нужен ли ему подтверждённый email или достаточно телефона?
3. Шаги слишком общие
Примерно в таком духе:
Открыть форму логина
Ввести корректный логин/пароль
Нажать «Войти»
Что здесь не хватает:
где именно открыть: URL, путь в приложении, контекст (гость/сессия/кэш)?
«корректный логин» — это какой? email? номер? длина? формат?
нет ни одного шага про проверку состояния до/после (куки, сессии, редиректы).
Такой тест ничего важного не проверит и багов им не найти. А тогда вопрос — зачем он вообще нужен?
4. Ожидаемый результат в стиле «Не упало и слава Богу»
Напомню ОР от ИИ:
«Пользователь успешно авторизован и перенаправлен на главную страницу»
Неплохо для джуна, но какие вопросы должен задать себе опытный тестировщик? Помимо «что именно мы проверяем?».
появился токен/сессионная кука?
как исчезла форма логина?
чем отличается главная страница гостя и авторизованного пользователя?
5. Никакого привязки к системе и окружению
Если просто взять эту таблицу и отнести в проект, через месяц никто не вспомнит:
для какого продукта это писалось;
на каких стендах проверять;
какие данные использовать.
Это такой «универсальный шаблон для любой формы логина», а не реальные тесты под конкретную систему.
Ну и самое главное. Ничего важного эти тесты не проверяют. А как же пустые поля, ввод неверных данных, блокировка авторизации после N попыток и так далее?
Промт по формуле Роль → Задача → Контекст → Формат вывода.
Теперь возьмём ту же задачу, но напишем промпт так, как будто объясняем её живому джуну. А для этого нам нужен контекст системы.
Контекст системы: «Побрякушки Катюшки»
Для примера давайте представим не абстрактный «логин», а живую систему — интернет-магазин украшений ручной работы «Побрякушки Катюшки».
Пользователь здесь может зарегистрироваться и авторизоваться на сайте, чтобы оформлять заказы и отслеживать их статус.
Как устроена регистрация
Регистрация через форму «Создать аккаунт». Открывается нажатием на кнопку Создать аккаунт на главном экране авторизации.
Регистрация
Форма «Создать аккаунт».
Поля:
Email — обязательное, уникальное, формат email.
Пароль — обязательное, от 8 до 32 символов.
Имя — необязательное, до 50 символов.
чекбокс «Согласен с условиями и политикой обработки данных» — обязателен.
После отправки формы:
Если всё ок — создаётся аккаунт в статусе «Не подтверждён».
На email уходит письмо с ссылкой подтверждения.
После перехода по ссылке статус меняется на «Активен».
Удаление аккаунта
Аккаунт может быть удалён двумя способами:
Сам пользователь:
в личном кабинете есть кнопка «Удалить аккаунт»;
перед удалением показываем подтверждение;
после удаления авторизация невозможна, при попытке входа показываем сообщение:
«Аккаунт не найден. Проверьте данные или зарегистрируйтесь снова».
Администратор:
в админке есть действие «Удалить аккаунт»;
после удаления поведение при логине такое же, как выше.
Вход (логин)
Форма «Войти»:
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. Шаги стали реально воспроизводимыми
В старом ответе ИИ было что-то вроде:
«Открыть форму логина. Ввести корректные данные. Нажать Войти.»
Сейчас в таблице уже:
Открыть /login.
Ввести active_user@example.com.
Ввести ValidPass1!.
Убедиться, что чекбокс «Запомнить меня» не отмечен / отмечен.
Нажать «Войти».
После входа снова открыть /login в той же сессии/браузере (для кейса с редиректом).
То есть:
шаги разные для разных сценариев (с remember me, с редиректом, с неверным паролем);
нет «магии», каждый шаг — конкретное действие.
Это то, чего не было в первом «ленивом» ответе ИИ, но что важно для тестов в реальном жизненном цикле любого сервиса и приложения.
5. Ожидаемые результаты стали проверками, а не желаниями
Вот тут самый большой скачок качества.
Вместо абстрактного:
«Авторизация успешна»
«Отображается сообщение об ошибке»
ты теперь видишь:
куда конкретно происходит редирект (/profile или остаёмся на /login);
что именно отображается:
текст ошибки: «Пожалуйста, подтвердите email…»;
текст: «Аккаунт не найден. Проверьте данные или зарегистрируйтесь»;
отсутствие/наличие формы логина;
отображение имени/почты в шапке;
что не должно отображаться (форма логина не показывается для авторизованного).
То есть ожидаемый результат теперь = набор наблюдаемых фактов, а не «итоговое настроение тестировщика».
6. Отражены все важные состояния аккаунта
Покрыты все описанные статусы акаунта, что является прямой заслугой хорошо написанного контекста — ИИ это подхватил и перенёс в тесты.
У «сырого» первого варианта тестов такого вообще не было — он не знает про статусы, если ему их не рассказать.И поэтому даже не задумывается, что в системе аккаунт без какого-то статуса существовать не может.
Общий вывод
В первом случае ИИ выдал «универсальные тесты для любой формы логина». Смысла в таких тестах в реальном проекте мало: они не проверяют ничего конкретного, их не автоматизировать и ещё сложнее использовать как инструмент для поиска багов.
После того как мы добавили контекст системы и нормальный промт, тесты стали:
привязаны к конкретным статусам аккаунта;
с явными тестовыми данными;
с воспроизводимыми шагами;
с понятными ожидаемыми результатами (куда редиректит, какой текст отображается, что видно в интерфейсе).
То есть мы превратили ИИ из генератора общих идей в ассистента, который пишет тесты так, как их пишет живой тестировщик: с пониманием логики системы.
Такие тесты уже можно реально использовать на проекте:
занести их в TMS;
прогнать по тестовому стенду;
написать по ним автотесты;
отдать на прогон джуну или смежной команде — и быть уверенным, что они действительно проверят важные пользовательские сценарии.
Спасибо, что дочитали до конца!
Если статья была вам полезна, буду рада видеть в моем Телеграм-канале.
Там я планирую делиться новыми статьями на тему ИИ и тестирования, а также новостями по моему курсу «ИИ в тестировании». В нем я планирую на практике помочь научиться описанному подходу.
В следующих статьях на Хабре разберем:
Какие рутинные задачи можно решить с помощью обученного АИ помощника в тестировании.
Какая модель АИ лучше справится с рутинными задачами именно в тестировании? Сравнение ChatGPT и Claude.
Источник: habr.com
