❓ Как правильно проводить тестирование, чтобы не допустить блокеров?

"Я сейчас пропущу блокер/крит — и меня уволят" - один из вечных страхов начинающих QA-инженеров, которые впервые сталкиваются с реальными продуктовыми задачами.

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

1️⃣ Начните с контекста от разработчика
В продуктовых задачах очень важно, чтобы разработчик оставлял для тестировщика короткую памятку:
- Что было сделано?
- Как было/как стало?
- Какой функционал был затронут?
- Идеально - разработчик самостоятельно укажет платформы для проверки
Это не "одолжение QA", а нормальная часть командной работы. Потому что тестировщик не всегда может по названию задачи понять весь технический и продуктовый контекст. Разработчик изначально знает то, что он написал в коде, у него больше контекста/информации по задаче.

Хороший комментарий от разработчика может сэкономить часы тестирования и помочь найти критичный дефект ещё до релиза.

2️⃣ Сначала проверяем основной сценарий
Не нужно сразу пытаться "сломать всё вокруг".

Сначала важно убедиться, что функциональность вообще работает так, как заявлено в требованиях. Если требования расходятся с комментарием разработчика - уточняем, насколько это релевантно.

Например:
- кнопка сохраняет данные;
- пользователь может оформить заказ;
- фильтр действительно фильтрует;
- новая настройка влияет на поведение системы;
- форма отправляется с валидными данными.

Это можно назвать позитивным тестированием или проверкой happy path - когда мы идём по основному пользовательскому сценарию и убеждаемся, что он работает.

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

3️⃣ Подключаем базовую теорию тестирования
Когда happy path проверен, пора расширять покрытие.
Здесь помогают классические техники тест-дизайна: эквивалентные классы, граничные значения, таблица принятия решений. Это простые практики тестирования, которые не тяжелые для освоения. Вспомнить или изучить их можно тут, тут и особенно тут

4️⃣ Проверяем негативные сценарии
После основного поведения стоит посмотреть, как система реагирует на неправильные действия пользователя.

Например:
- пустые обязательные поля
- неверный формат данных
- слишком длинные значения
- повторные клики
- отсутствие прав
- истёкшая сессия
- ошибка сети
- попытка открыть чужие данные

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

5️⃣ Не забываем про зоны влияния
Один из главных источников блокеров - это не сама задача, а то, что она случайно сломала рядом.

Например:
- изменили регистрацию -> проверьте авторизацию;
- изменили корзину -> проверьте оформление заказа;
- изменили роли -> проверьте доступы;
- изменили отображение цены -> проверьте оплату, скидки, валюты;
- изменили API -> проверьте клиентов, которые его используют.

Здесь снова помогает памятка от разработчика: какие модули затронуты и где может быть побочный эффект.
Но! Мы не можем полностью доверять разработчику (такая у нас работа, чтож), поэтому включаем здравый смысл и голову и смотрим весь "смежный" функционал.

6️⃣ Проверяем нефункциональные требования
Если задача влияет на пользовательский интерфейс или важные пользовательские сценарии, не стоит забывать про нефункциональные проверки.

Например:
- кроссбраузерность
- адаптивность на разных разрешениях
- локализация
- корректность текстов
- производительность
- доступность
- стабильность при медленном интернете
- отображение в светлой/тёмной теме, если есть

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

Общий вывод, чтобы не нервничать при получении задачи:
Чтобы снизить риск блокеров, QA нужно не "тыкать всё подряд" (monkey testing), а идти по понятной стратегии.

✍️ @removespreadblog