Ответ.

Автоматизация негативных сценариев — неотъемлемая часть полноценной системы тестирования. Это проверки, при которых валидируется устойчивость системы к ошибочным действиям, некорректным данным, отказам сервисов и иным нештатным ситуациям.

История вопроса:

Ранее основное внимание уделялось позитивным сценариям (happy paths), потому что их проще автоматизировать и поддерживать. Однако требования к качеству выросли, и всё больше багов возникает именно на границах, с ошибочными или неочевидно некорректными условиями. Их ручное тестирование быстро устаревает, а автоматизация позволяет отслеживать деградации.

Проблема:

Определение и покрытие всех возможных негативных сценариев
Корректная проверка сообщений об ошибках, валидности состояния системы после провала операции
Поддержка тестов при изменениях бизнес-логики

Решение:

Выделение негативных сценариев и их систематизация (Boundary Value Analysis, Equivalence Partitioning)
Использование кастомных asserts и валидаторов для проверки текстов ошибок, HTTP-кодов, исключений
Автоматическое "очищение" состояния системы после негативного теста

Ключевые особенности:

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

Вопросы с подвохом.

Достаточно ли проверить только какие ошибки возвращаются при негативном тестировании?

Нет. Важно проверить не только содержание ошибки, но и что после ошибки не произошло изменения состояния системы (например, не добавилась некорректная запись в БД).

Нужно ли автоматизировать все возможные негативные сценарии?

Нет. Их может быть бесконечно много; нужно выделять наиболее вероятные и критичные (Boundary Value, Null/Empty, неверный тип, SQL-инъекции и т.п.), а остальные — по мере поступления багов.

Можно ли использовать одинаковую обработку для всех негативных кейсов?

Нет. Разные негативные сценарии требуют разных проверок, обработки исключений и rollback'ов, шаблонных asserts недостаточно.

Типовые ошибки и анти-паттерны

Игнорирование негативных сценариев или покрытие их "для галочки"
Неубедительная проверка ошибки (например, только код 500, но не проверка текста или побочного эффекта)
Неочищенное тестовое окружение после падения теста

Пример из жизни

Негативный кейс

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

Плюсы:

Простая поддержка тестов
Малое количество автотестов и быстрый прогон

Минусы:

Уходят в бой критичные баги
Растут издержки на исправление и откат

Позитивный кейс

Для каждого негативного сценария (отсутствие email, некорректный формат, sql-инъекция) есть автоматизированный тест, который явно проверяет отсутствие нового аккаунта и содержание сообщения об ошибке.