Тест-план: как составить точное задание для инструмента

Зачем нужен точный ввод

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

Поле «Ваш текст или идея» принимает до 8000 символов, поле «Платформа или приложение» — до 1000 символов. Этого достаточно, чтобы описать функцию, её назначение, ключевые сценарии и особые условия. Не нужно писать техническое задание целиком — достаточно сжатого, но точного описания.

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

Плохо: «форма сброса пароля». Хорошо: «Веб-форма сброса пароля: пользователь вводит email, получает письмо со ссылкой одноразового действия, переходит по ней и задаёт новый пароль. Платформа: веб, десктоп и мобильные браузеры. Ограничения: ссылка действует 15 минут, повторная отправка не чаще раза в минуту».

Что указать во вводе: контекст и цель

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

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

Не смешивайте цель и способ реализации. Инструмент не знает вашу кодовую базу, поэтому фразы вроде «проверить, что функция validateEmail возвращает true» бесполезны. Описывайте поведение, видимое пользователю или системе.

Контекст: «Мобильное приложение для заказа такси, экран подтверждения поездки». Цель: «Убедиться, что пользователь может подтвердить поездку, отменить её до прибытия водителя и получить корректное сообщение при потере сети».

Формат и ограничения: что добавить

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

Ограничения — это правила, которые нельзя нарушать. Например: «пароль должен содержать минимум 8 символов, одну цифру и одну заглавную букву», «ссылка одноразовая», «максимум 5 попыток ввода кода». Ограничения превращаются в граничные случаи: ровно 8 символов, 7 символов, 9 символов, отсутствие цифры, повторное использование ссылки.

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

Ограничения: «Код подтверждения состоит из 6 цифр, действует 10 минут, допускается 3 попытки ввода. После третьей неудачной попытки форма блокируется на 5 минут».

Пример плохого и хорошего задания

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

Хорошее задание: «Веб-приложение, вход по email и паролю. Цель: проверить успешный вход, ошибки при неверных данных и блокировку после 5 неудачных попыток. Ограничения: пароль от 8 до 32 символов, блокировка на 15 минут, сессия истекает через 30 минут бездействия. Платформа: десктопные браузеры Chrome и Firefox. Нужны успешные, провальные и граничные случаи с шагами воспроизведения».

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

Хороший ввод для инструмента: «Веб-форма сброса пароля. Пользователь вводит email, получает письмо со ссылкой одноразового действия, переходит по ней и задаёт новый пароль. Платформа: веб, десктоп и мобильные браузеры. Ограничения: ссылка действует 15 минут, повторная отправка не чаще раза в минуту, новый пароль от 8 символов. Нужны успешные, провальные и граничные случаи».

Как проверить сгенерированный план

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

Сверьте случаи с вашими ограничениями. Если в плане есть проверка на 7 символов пароля, а минимальная длина 8, это граничный случай. Если проверка на 100 символов, а максимум 32, это тоже граница. Убедитесь, что такие случаи не противоречат вашим правилам.

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

Проверка: в плане для сброса пароля есть случай «переход по ссылке после 15 минут». Это граничный случай, соответствующий ограничению. Если бы в плане был случай «ссылка действует 24 часа», это противоречило бы вводу.

Ограничения инструмента и типичные ошибки

Инструмент работает только с текстом: он не запускает тесты, не подключается к вашему приложению и не проверяет реальное поведение. Результат — это черновик плана, который нужно адаптировать под ваш проект. Он не заменяет исследовательское тестирование и не гарантирует обнаружение всех дефектов.

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

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

Помните о лимитах: поле ввода до 8000 символов, поле платформы до 1000 символов. Если описание слишком длинное, сократите его до сути. Инструмент не сохраняет историю и не выполняет пакетную обработку, поэтому каждый запрос нужно формировать отдельно.

Ошибка: «Протестировать всё». Результат будет общим. Исправление: «Протестировать оформление заказа в интернет-магазине: выбор товара, корзина, ввод адреса, оплата картой. Ограничения: минимальная сумма 500 рублей, доставка только по России. Нужны случаи для успешной оплаты, отказа банка и неверного адреса».