БЛОК 3. Основы тестирования — 9. Happy Path и негативные сценарии

🧭 Введение: почему нельзя проверять только «идеальный» путь

На старте карьеры QA часто кажется, что главное — проверить, что «всё работает нормально». Это и есть happy path: пользователь делает всё правильно, система отвечает без ошибок.
Проблема в том, что в реальной жизни пользователи ошибаются, сеть падает, данные приходят в неожиданном виде, и именно там появляются инциденты.

Happy path и негативные сценарии всегда идут парой. Первый показывает, что функция вообще работает, второй — что она не ломается при проблемах.

💡 Совет:

Если на фичу есть только happy path, считайте покрытие незавершённым.

✅ Вывод:

Сильный junior QA проверяет не только «как должно быть», но и «что будет, если что-то пойдёт не так».

⚠️ Проблема -> решение

Когда команда тестирует только позитивный поток, релиз может выглядеть «зелёным», но это ложная уверенность. На проде пользователи быстро находят ситуации, которые никто не проверил: пустые поля, невалидные форматы, повторные клики, таймауты API.

Решение — проектировать проверку сразу в двух плоскостях:

happy path (основной рабочий поток);
negative scenarios (ошибки пользователя, системные отказы, пограничные условия).

🟢 Если совсем просто:

Happy path показывает, что функция работает, negative — что функция не разваливается.

🎯 Как понять, что этап прошёл успешно:

По каждой ключевой функции есть минимум один happy path и несколько негативных веток с ожидаемым результатом.

🛠️ Чем помогает и как работает

Эта связка помогает команде заранее видеть риски релиза, а не узнавать о них от пользователей. Для junior QA это ещё и способ структурировать свои проверки: сначала основной поток, потом контролируемый набор отказов.

Как это работает:

Шаг 1: выделяем бизнес-цель пользователя и основной успешный поток.
Шаг 2: фиксируем expected result для happy path.
Шаг 3: добавляем ошибки пользователя (пусто, неверный формат, дубликат, недоступные действия).
Шаг 4: добавляем системные сбои (timeout, 5xx, недоступный сервис, гонки).
Шаг 5: определяем приоритеты (critical/high/medium) по риску для бизнеса.
Шаг 6: переводим сценарии в тест-кейсы и чек-листы на исполнение.

✅ Вывод:

Happy + negative — это базовый каркас, который делает тестирование предсказуемым и защищает релиз.

📚 Ключевые термины (простыми словами)

Happy Path (успешный путь) — основной сценарий, где пользователь делает корректные действия и получает ожидаемый результат.
Negative Scenario (негативный сценарий) — проверка того, как система ведёт себя при ошибках пользователя или сбоях.
Expected Result (ожидаемый результат) — чёткое описание, что считается правильным исходом.
Validation (валидация) — проверка корректности данных на входе.
Error Handling (обработка ошибок) — логика реакции системы на нештатные ситуации.
Fallback (резервное поведение) — безопасный сценарий, когда основной путь недоступен.
Risk (риск) — вероятность и последствия дефекта для пользователя/бизнеса.
Coverage (покрытие) — насколько полно сценарии закрывают реальные варианты поведения функции.

1. Happy Path: основной рабочий поток

Happy path нужен, чтобы подтвердить базовую работоспособность фичи по требованиям. Это первый тест в любом наборе, но не единственный.

🟢 Если совсем просто:

Happy path отвечает на вопрос: «может ли пользователь успешно выполнить задачу».

🎯 Как понять, что этап прошёл успешно:

Есть один однозначный успешный сценарий с валидными данными и чётким expected result.

Назначение:

Проверить, что функция выполняет свою основную бизнес-задачу.

Простыми словами:

Это идеальная дорожка без ошибок и помех.

Для новичка:

Сначала всегда проверяем «нормальный» путь, чтобы понять, что функция вообще работает.

Аналогия:

Как проверка нового замка: сначала убеждаемся, что он открывается родным ключом.

Пример:

Фича: Регистрация пользователяHappy Path:1) Ввести валидный email и пароль2) Нажать "Зарегистрироваться"3) Получить успешный ответ и вход в аккаунтExpected: аккаунт создан, пользователь авторизован

🔎 Как это происходит на практике:

QA берёт acceptance criteria.
Выбирает один базовый пользовательский поток.
Фиксирует ожидаемый результат без двусмысленности.

Характеристики:

✅ Проверяет основную ценность фичи.
✅ Быстро показывает грубые блокеры.
✅ Нужен как baseline перед негативными ветками.

Когда использовать:

Всегда первым при проверке новой фичи и после критичных изменений.

✅ Вывод:

Happy path — обязательная база, но без negative сценариев он даёт неполную картину качества.

2. Негативные сценарии: проверки на ошибки и отказы

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

🟢 Если совсем просто:

Негативный сценарий проверяет, что система «ошибается правильно».

🎯 Как понять, что этап прошёл успешно:

Для каждого важного риска есть негативная проверка и ожидаемая реакция системы.

Назначение:

Проверить обработку нештатных ситуаций без поломки пользовательского потока.

Простыми словами:

Мы специально создаём проблемы и смотрим, как система на них реагирует.

Для новичка:

Если можно ошибиться — это нужно проверить отдельно, а не «надеяться, что всё нормально».

Аналогия:

Как тест ремня безопасности: важен не только комфорт поездки, но и поведение при аварии.

Пример:

Фича: Вход в системуNegative scenarios:1) Неверный пароль -> сообщение "Неверный логин или пароль"2) Пустой пароль -> подсветка обязательного поля3) 5 неудачных попыток -> временная блокировкаExpected: контролируемые сообщения, без раскрытия чувствительных данных

🔎 Как это происходит на практике:

QA собирает список типовых ошибок пользователя.
Добавляет системные сбои (timeout, 500, network fail).
Сверяет сообщения/коды/логику с требованиями и security-политикой.

Характеристики:

✅ Снижает риск прод-инцидентов.
✅ Проверяет устойчивость и предсказуемость поведения.
✅ Помогает найти дефекты в валидации и обработке ошибок.

Когда использовать:

После фиксации happy path и при каждом регрессе критичных пользовательских потоков.

✅ Вывод:

Негативные сценарии превращают «работает в идеале» в «надёжно работает в реальности».

2.1 Классификация negative-сценариев: что именно проверять

Чтобы junior QA не сводил весь negative только к «пустому полю», полезно раскладывать негативные проверки на подтипы. Так вы быстрее видите пробелы в покрытии.

🟢 Если совсем просто:

Negative-сценарии — это не один тип ошибок, а несколько разных групп рисков.

🎯 Как понять, что этап прошёл успешно:

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

Негативы бывают:

1) Ошибки пользователя

пустые поля;
неверный формат (email, телефон, дата);
неверный пароль или код подтверждения.

2) Бизнес-ограничения

duplicate email;
заблокированный аккаунт;
превышен лимит попыток.

3) Системные сбои

timeout;
HTTP 500;
недоступная внешняя интеграция.

4) Опасные действия/гонки

повторный клик по кнопке;
двойная отправка формы;
refresh в критический момент.

✅ Вывод:

Такая классификация даёт «карту рисков» и помогает не пропустить важные негативные ветки.

2.2 Negative vs Edge: как не путать

Эти понятия часто смешивают, особенно на старте. На практике их лучше разделять явно: так проще проектировать покрытие и объяснять выбор сценариев на ревью.

🟢 Если совсем просто:

Negative — это ошибка/нарушение потока, edge — это работа на границе допустимого.

🎯 Как понять, что этап прошёл успешно:

Для одной и той же функции у вас отдельно описаны негативные проверки и edge-проверки на границах.

Правило:

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

Пример (пароль 8–20 символов):

Negative:- пустой пароль- пароль без обязательного символа Edge:- 7 символов- 8 символов- 20 символов- 21 символ

✅ Вывод:

Если вы разделяете negative и edge, сценарии становятся точнее, а покрытие — понятнее для всей команды.

3. Баланс Happy и Negative: как не утонуть в объёме

Частая ошибка — либо проверяют только happy path, либо пишут бесконечный список негативных кейсов без приоритета. Оба подхода плохие. Нужен баланс по риску и ценности.

🟢 Если совсем просто:

Сначала критичный happy, затем негативы с максимальным риском, потом остальное.

🎯 Как понять, что этап прошёл успешно:

У команды есть ограниченный, но риск-ориентированный набор сценариев для релиза.

Назначение:

Построить реалистичный план проверок при ограниченном времени.

Простыми словами:

Проверяем не «всё подряд», а то, что сильнее всего ударит по пользователю и бизнесу.

Для новичка:

Если времени мало, сначала закрывай критичные потоки и их основные отказы.

Аналогия:

Как в медицине: сначала стабилизируют жизненно важные функции, затем второстепенные симптомы.

Пример:

Приоритеты для релиза:Critical: login, payment, order submitHigh: валидация форм, повторный submit, timeout APIMedium: редкие edge-кейсы интерфейса

🔎 Как это происходит на практике:

QA маркирует сценарии по уровню риска.
Согласует приоритеты с PO и разработкой.
Явно фиксирует, что вошло и что не вошло в текущий прогон.

Характеристики:

✅ Экономит время без потери управляемости.
✅ Делает релизное решение прозрачным.
✅ Уменьшает споры «почему это не проверили».

Когда использовать:

В каждом спринте и особенно перед релизным окном.

✅ Вывод:

Баланс happy/negative — это про качество решений, а не про количество тестов.

4. Как из требования получить Happy + Negative набор

Набор сценариев должен рождаться из требований, а не из случайных идей. Простой рабочий алгоритм помогает junior QA не терять важные ветки.

🟢 Если совсем просто:

Берём цель пользователя, строим happy, затем системно добавляем негативы.

🎯 Как понять, что этап прошёл успешно:

По каждому AC есть успешная ветка и набор негативных проверок с expected result.

Назначение:

Сделать переход от требований к тест-дизайну повторяемым.

Простыми словами:

Это рецепт, который каждый раз приводит к полному и понятному набору проверок.

Для новичка:

Не придумывай сценарии хаотично: иди по шагам и фиксируй результаты.

Пример:

Алгоритм:1) Кто пользователь и какая цель2) Как выглядит успешный путь3) Какие пользовательские ошибки возможны4) Какие системные отказы вероятны5) Что считаем корректной реакцией6) Какие сценарии критичны для релиза

🔎 Как это происходит на практике:

На grooming QA выписывает AC и риски.
После уточнений формирует Scenario Map.
Перед execution команда подтверждает приоритеты и ожидаемые результаты.

Характеристики:

✅ Снижает пропуски в покрытии.
✅ Ускоряет ревью сценариев в команде.
✅ Упрощает переход к тест-кейсам.

Когда использовать:

Для любой новой фичи, изменения поведения и регресса после инцидента.

✅ Вывод:

Алгоритм превращает тест-дизайн из «интуиции» в управляемый процесс.

📊 Сравнение: Happy Path vs Negative Scenario

Критерий	Happy Path	Negative Scenario
Главная цель	Проверить основной успешный поток	Проверить устойчивость к ошибкам и сбоям
Данные	Валидные	Невалидные/пограничные/сбойные
Тип результата	Функция успешно выполняется	Ошибка обрабатывается корректно
Риск пропуска	Ложная уверенность в качестве	Инциденты на проде из-за нештатных кейсов
Когда запускать	Всегда первым	Сразу после happy, по приоритету риска

✅ Must-Know для junior QA

Happy path обязателен, но сам по себе не покрывает качество фичи.
Негативные сценарии нужны для ошибок пользователя и системных отказов.
У каждого сценария должен быть expected result, иначе нельзя объективно оценить pass/fail.
При дефиците времени используем risk-based приоритизацию.
Negative-покрытие должно включать и валидацию, и обработку backend-ошибок.
Формулировка «проверил форму» не считается сценарием без контекста и результата.
Scenario coverage оцениваем по потокам, а не по числу тестов.

❌ Частые мифы

❌ Миф:
Если happy path прошёл, фича готова к релизу. ✅ Как правильно:
После happy path обязательно проверяем ключевые негативные и edge-сценарии. 📎 Почему это важно:
Большинство критичных багов живёт в ошибочных ветках, а не в идеальном потоке.

❌ Миф:
Негативные сценарии — это только «пустое поле». ✅ Как правильно:
Negative включает ошибки пользователя, системные отказы, гонки, повторные действия и лимиты. 📎 Почему это важно:
Иначе тестирование покрывает только малую часть реальных рисков.

❌ Миф:
Чем больше негативных тестов, тем лучше. ✅ Как правильно:
Нужен приоритет по риску: критичное покрываем в первую очередь. 📎 Почему это важно:
Без приоритета команда тратит время, но всё равно может пропустить важные дефекты.

❌ Миф:
Expected result можно уточнить «по факту». ✅ Как правильно:
Expected result фиксируют до выполнения сценария. 📎 Почему это важно:
Иначе появляются споры и субъективные оценки результата.

❓ Часто спрашивают на собеседованиях

❓ Вопрос:
Чем отличается happy path от негативного сценария? ✅ Ответ:
Happy path проверяет успешный основной поток, а негативный сценарий — корректную реакцию системы на ошибки и отказы.

❓ Вопрос:
Почему нельзя ограничиться только happy path? ✅ Ответ:
Потому что релизные дефекты чаще возникают в нештатных ситуациях: невалидный ввод, таймауты, дубликаты, сбои интеграций.

❓ Вопрос:
Как выбрать негативные сценарии при ограниченном времени? ✅ Ответ:
Через риск-ориентированный подход: сначала сценарии с максимальным влиянием на деньги, доступы, ключевые пользовательские потоки.

❓ Вопрос:
Что обязательно должно быть в формулировке сценария? ✅ Ответ:
Контекст, условие запуска, ожидаемый результат и связь с требованием или риском.

❓ Вопрос:
Как проверить, что покрытие happy/negative достаточное? ✅ Ответ:
Сверить набор с AC, рисками и типовыми отказами системы; убедиться, что закрыты основные пользовательские и ошибочные ветки.

🚫 Типичные ошибки

Ошибка 1: «Проверили только успешный путь»

❌ Неправильно:

Оставить только happy path без негативных веток.

✅ Правильно:

На каждый критичный happy-сценарий добавить минимум 1–2 негативных проверки.

Почему:

Иначе покрытие не отражает реальное поведение продукта.

Ошибка 2: Нет expected result

❌ Неправильно:

Формулировка «проверить регистрацию» без критериев результата.

✅ Правильно:

Фиксировать ожидаемую реакцию системы заранее.

Почему:

Без expected result невозможно однозначно определить pass/fail.

Ошибка 3: Негативы без приоритета

❌ Неправильно:

Пытаться проверить все негативы одинаково глубоко.

✅ Правильно:

Сначала закрывать риски critical/high, затем medium/low.

Почему:

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

Ошибка 4: Путают сценарий и тест-кейс

❌ Неправильно:

Сценарий сразу превращают в длинную пошаговую инструкцию.

✅ Правильно:

Сначала фиксируют поток на уровне сценария, затем детализируют в тест-кейсы.

Почему:

Так проще управлять покрытием и избежать дублирования.

🧩 Best Practices

Для каждой фичи сначала фиксируйте один эталонный happy path.
Негативные сценарии группируйте по типам: пользовательские ошибки, системные отказы, edge-кейсы.
Всегда пишите expected result до исполнения.
Привязывайте сценарии к AC, рискам и прошлым инцидентам.
Используйте простую risk-матрицу (critical/high/medium) перед релизом.
Регулярно пересматривайте набор сценариев после изменений требований.

🏁 Заключение

Happy Path и негативные сценарии — это не конкуренты, а две обязательные части одного процесса.
Happy path подтверждает, что функция работает, negative — что она надёжна при ошибках.

Если вы умеете системно строить оба типа сценариев, вы уже работаете как зрелый junior QA: осознанно, предсказуемо и с понятной ценностью для команды.

БЛОК 3. Основы тестирования — 9. Happy Path и негативные сценарии

БЛОК 3. Основы тестирования — 9. Happy Path и негативные сценарии

🧭 Введение: почему нельзя проверять только «идеальный» путь

⚠️ Проблема -> решение

🛠️ Чем помогает и как работает

📚 Ключевые термины (простыми словами)

1. Happy Path: основной рабочий поток

2. Негативные сценарии: проверки на ошибки и отказы

2.1 Классификация negative-сценариев: что именно проверять

2.2 Negative vs Edge: как не путать

3. Баланс Happy и Negative: как не утонуть в объёме

4. Как из требования получить Happy + Negative набор

📊 Сравнение: Happy Path vs Negative Scenario

✅ Must-Know для junior QA

❌ Частые мифы

❓ Часто спрашивают на собеседованиях

🚫 Типичные ошибки

Ошибка 1: «Проверили только успешный путь»

Ошибка 2: Нет expected result

Ошибка 3: Негативы без приоритета

Ошибка 4: Путают сценарий и тест-кейс

🧩 Best Practices

🏁 Заключение

Проверьте знания