Новички в тестировании часто начинают с самого очевидного: проверить, работает ли функциональность «как задумано». Это и есть позитивное тестирование. А вот про негативные сценарии — когда пользователь делает не то, что от него ждали — вспоминают не все. А зря: именно там зарываются самые интересные баги.
В этой статье разберём, что такое позитивное и негативное тестирование, чем они отличаются, зачем нужны оба подхода и как правильно их применять. Всё с примерами, типичными ошибками и советами, чтобы прокачать ваш скилл QA.
Что такое позитивное тестирование?
Позитивное тестирование (positive testing) — это проверка, при которой система получает ожидаемые, корректные данные. То есть — пользователь делает всё по правилам.
Цель: убедиться, что система работает как задумано, когда всё «по учебнику».
Пример:
Проверка формы регистрации, где вводятся:
- Имя: «Алексей»
- Email: «test@example.com»
- Пароль: «12345Qwerty»
Ожидаемый результат: пользователь успешно регистрируется и попадает в личный кабинет.
Что такое негативное тестирование?
Негативное тестирование (negative testing) — это проверка поведения системы при некорректных, неожиданных или граничных вводах. Здесь мы специально «ломаем» сценарий, чтобы проверить устойчивость системы.
Цель: убедиться, что система адекватно обрабатывает ошибки, не падает и сообщает пользователю, в чём проблема.
Пример:
Проверка той же формы регистрации с вводом:
- Имя: «@#$%»
- Email: «qwerty»
- Пароль: «123»
Ожидаемый результат: система не даёт зарегистрироваться, показывает корректные сообщения об ошибке (например: «Некорректный email», «Пароль слишком короткий»).
Основные отличия
Почему важно тестировать и то, и другое?
- Позитивные сценарии проверяют, что система реализует заявленные функции.
- Негативные сценарии защищают продукт от краха при неправильных действиях пользователя.
Без позитивного тестирования мы не узнаем, работает ли базовая функциональность. Без негативного — не поймём, насколько продукт надёжен в нестандартных ситуациях.
Примеры позитивных и негативных кейсов
Пример 1: Авторизация
Позитивный кейс:
- Ввести правильный логин и пароль
- Ожидание: успешный вход
Негативные кейсы:
- Ввести неверный пароль
- Ввести пустое поле логина
- Ввести SQL-инъекцию admin' --
- Ввести 300-символьный логин
Ожидание: система не входит, даёт понятную ошибку, не падает и не пропускает опасные инъекции.
Пример 2: Загрузка изображения
Позитивный кейс:
- Загрузить JPG-файл размером 1 МБ
Негативные кейсы:
- Загрузить EXE-файл
- Файл весом 10 МБ (если лимит 5 МБ)
- Попробовать загрузить 0-байтовый файл
Пример 3: Калькулятор стоимости заказа
Позитивный кейс:
- Ввести количество = 2, цена за штуку = 100
- Ожидание: сумма = 200
Негативные кейсы:
- Ввести количество = -5
- Ввести цену = «сто рублей»
- Оставить поля пустыми
Типичные ошибки новичков
- Тестируются только «счастливые» пути.
Часто из страха ошибиться новички проверяют только то, что должно работать. - Негативные кейсы не описаны в тест-кейсах.
«А вдруг это неважно…» — думают джуны. А зря. Как раз негативные кейсы выявляют нестабильность. - Слабое воображение.
Новичку сложно представить, как «глупо» может себя повести пользователь.
Как составлять позитивные и негативные тесты
✔Изучите требования.
Поймите, какие вводы и сценарии считаются корректными.
✔Проведите анализ граничных значений.
Например, если поле принимает числа от 1 до 100:
- Позитивные: 1, 50, 100
- Негативные: 0, -1, 101, «abc»
✔Используйте техники тест-дизайна:
- Эквивалентное разбиение — разделите вводы на валидные/невалидные группы
- Анализ граничных значений — проверяйте крайние допустимые данные
- Попарное тестирование — найдите минимум кейсов для покрытия всех комбинаций
✔Пишите чётко и предсказуемо.
Каждый кейс должен быть понятен другому человеку: шаги, входные данные, ожидания.
Кейс из практики
Ситуация:
Джун протестировал новую форму входа на сайт. Всё работает: логин, пароль — супер. Через неделю прод падает — в форму можно вставить скрипт, который крашит страницу.
Почему произошло:
Джун не протестировал XSS-инъекции (вставка <script>alert('Hi')</script>), хотя это классический негативный кейс.
Вывод:
Иногда именно негативные кейсы ловят критические уязвимости.
Как комбинировать позитивное и негативное тестирование
Хорошая стратегия — использовать оба типа в каждом тестовом наборе:
- Начать с позитивных — убедиться, что система работает
- Затем добавить негативные — проверить, что она «не ломается»
Совет: если вы делаете чек-лист или пишете тест-кейсы — обязательно отмечайте, какие из них позитивные, а какие — негативные.
📚 Инструменты, которые помогут
- TestRail / Qase / TestLink — для хранения тест-кейсов
- Postman — можно тестировать API как с корректными, так и с «ломающими» данными
- Fiddler / Charles Proxy — позволяют посмотреть, как система реагирует на неожиданные запросы
Заключение
Позитивное тестирование показывает, что продукт делает то, что должен.
Негативное — что он не делает того, чего не должен.
Оба типа нужны как крылья самолёту. И если вы хотите стать надёжным QA-инженером, учитесь мыслить не только как пользователь, но и как вредный пользователь. Тогда ни один баг не проскользнёт мимо.
Хочешь больше таких разборов? Подписывайся на канал — впереди ещё больше кейсов и пользы для QA!