Как составить тестовые сценарии с помощью ИИ

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

Передайте критерии

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

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

Попросите разные виды проверок

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

В SYNTX можно попросить языковую модель оформить сценарии в таблицу и отметить, какое требование они проверяют. Возможности сервиса не означают автоматического запуска тестов в вашем проекте. Бесплатный старт включает пять токенов и пять запросов к языковым моделям; план FREE действует без срока. Открыть SYNTX.

Пример: поле скидки

Требование: скидка принимает целое число от 0 до 50 включительно; пустое значение означает отсутствие скидки; для 51 и отрицательного числа сохранение запрещено. Сценарии: пустое поле; 0; 50; 51; −1; текст вместо числа. Для каждого проверяем и сообщение, и сохранённое состояние.

Промпт: «По этим условиям составь компактную таблицу проверок: предусловие, ввод, действие, ожидаемый результат. Не добавляй правила округления или валюту. Отдельно перечисли вопросы, если поведение при десятичной дроби не задано». Модель должна отметить неопределённость для дробей, а не принимать решение за владельца продукта.

Проверьте таблицу: есть нижняя и верхняя границы; крайние значения включены; отрицательное значение запрещено; неизвестный случай помечен открытым вопросом. Если модель пропустила 0 или решила, что пустое значение равно нулю, уточните требование и попросите пересобрать только этот набор.

Свяжите сценарии с требованиями

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

Попросите коллегу проверить, что сценарии понятны без объяснения автора. При изменении правила обновите связанные тесты. Храните результаты и версию требования вместе, чтобы не использовать старый список при новом релизе.

Не принимайте тесты на веру

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

Свяжите сценарий с требованием

Чтобы не получить набор случайных проверок, укажите рядом с каждым сценарием исходное требование. Для правила «пользователь видит подтверждение после сохранения» сценарий должен описывать ввод данных, действие сохранения и наблюдаемое подтверждение. Отдельно проверьте ситуацию, когда сохранение не удалось: текст ошибки, возможность повторить действие и сохранность введённых значений.

Попросите модель отметить сценарии без проверяемого результата. Фраза «проверить удобство» сама по себе не говорит, что именно следует сделать и как оценить ответ. Её можно преобразовать в задачу наблюдения: новый пользователь выполняет заданный путь без подсказки, наблюдатель фиксирует места остановки и ошибки. Для числовых ограничений добавьте значения на границе: допустимое минимальное, значение ниже него и максимальное. Такой набор обычно обнаруживает больше проблем, чем десяток почти одинаковых обычных примеров.

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

Частые вопросы