В требовании описан только успешный сценарий. Как определить границы негативных проверок, не додумывая бизнес-правила?
Негативные проверки нужно выводить только из явно заданных ограничений, связанных требований, бизнес-правил и согласованных критериев приемки. Если ожидаемое поведение для невалидного случая не определено, тестировщик фиксирует вопрос или риск и не объявляет произвольный результат дефектом.
Такой подход появился из практической необходимости отделять проверку продукта от угадывания требований. Ручной тестировщик часто видит успешный сценарий, но отсутствие описания ошибок не означает, что любое найденное поведение автоматически является дефектом.
Работа с границами требований помогает сделать тестирование воспроизводимым: команда заранее договаривается, какие условия считаются допустимыми, а какие требуют уточнения.
Успешный сценарий показывает, что происходит при корректных входных данных, но не определяет реакцию системы на пропуски, неверный формат, запрещённые значения, недостаточные права или конфликт состояний.
Если тестировщик сам придумывает ожидаемый результат, возможны две ошибки: реальный дефект будет пропущен как якобы допустимое поведение, либо корректная реализация будет ошибочно зарегистрирована как дефект. Особенно опасна ситуация, когда разные участники команды предполагают разные правила.
Сначала нужно выделить из требования все явные ограничения: обязательность полей, допустимые форматы и диапазоны, роли пользователей, предусловия, ограничения по состояниям и последствия успешной операции. Затем следует проверить связанные требования, макеты, критерии приемки и уже согласованные бизнес-правила.
После этого негативные проверки группируют по источнику нарушения:
Для каждой проверки ожидаемый результат должен быть подтверждён источником. Если источник не определяет поведение, вопрос выносят владельцу требования или команде: нужно уточнить, отклоняется ли запрос, показывается ли сообщение, сохраняются ли частичные данные и изменяется ли состояние объекта.
До получения ответа такую проверку можно выполнить как исследовательскую, чтобы обнаружить риск или фактическое поведение системы. Однако результат следует пометить как требующий решения, а не безоговорочно считать дефектом.
Компромисс заключается между полнотой и скоростью: нельзя проверять все мыслимые ошибочные вводы без связи с рисками продукта. Приоритет получают случаи, которые нарушают безопасность, целостность данных, ключевые бизнес-ограничения или часто встречаются у пользователей.
В требовании сказано: «Пользователь может оформить заявку, указав контактный номер». Успешный сценарий описан подробно, но не указано, что делать с пустым номером, буквами, номером другой страны и уже существующей заявкой.
Рассматривались два варианта. Первый — считать обязательным любой номер, который выглядит разумно: это быстро, но создаёт риск выдумать бизнес-правило. Второй — ограничиться проверкой успешного ввода: это формально безопаснее, но оставляет без внимания очевидные риски качества данных.
Выбранное решение — проверить успешный сценарий и отдельно зафиксировать вопросы по обязательности, формату, повторной заявке и допустимым странам. До уточнения требования наблюдения по этим случаям оформить как риски или вопросы, а после согласования превратить в проверяемые тесты. Это сохраняет пользу ранней проверки и не подменяет решение бизнеса предположением тестировщика.
1. Можно ли считать отсутствие негативного сценария в требовании разрешением принимать любые данные?
Нет. Отсутствие правила означает неопределённость, а не разрешение. Нужно проверить связанные источники и запросить решение у ответственного за требования; иначе тестировщик незаметно становится автором бизнес-логики.
2. Нужно ли регистрировать дефект, если система принимает явно некорректное значение, но требование это не запрещает?
Не обязательно. Сначала нужно определить, существует ли подтверждённое правило, нарушение целостности данных, угроза безопасности или иной согласованный критерий качества. Если основание пока отсутствует, корректнее оформить вопрос или риск и указать фактическое поведение системы.
3. Как понять, что негативная проверка всё же входит в объём текущей задачи?
Нужно связать её с изменённым поведением, затронутыми ограничениями и рисками. Если проверка относится к соседней функции и не влияет на изменённый сценарий, её можно вынести в отдельную задачу или регрессионный набор; если же она проверяет нарушение нового ограничения, она входит в текущий объём.