Многие думают: QA — это человек, который кликает кнопки и ищет баги. Пришёл, потыкал, нашёл ошибку, отдал разработчику. На этом работа заканчивается.

Я тоже так думал, пока не попал в профессию. Реальность оказалась глубже.

QA контролирует качество на всех этапах. От первой строчки требований до момента, когда продукт уходит клиенту.

Этап первый. Анализ требований

QA подключается раньше, чем разработчик садится за код. Он читает требования и задаёт неудобные вопросы. Что если пользователь введёт пустое поле? Что если запрос придёт дважды? Что если сервер упадёт в момент оплаты?

На этом этапе QA находит дыры в логике. Пока они стоят копейки. Потом каждая такая дыра превращается в баг, который стоит денег и времени.

Этап второй. Планирование

QA решает, что и как тестировать. Оценивает риски. Выбирает техники. Смотрит, где вероятность ошибки выше. Где цена ошибки критична. Где можно сэкономить силы.

Это стратегическая работа. Не просто «пойду потыкаю». А «я потрачу два часа здесь, потому что тут платёжный шлюз, а тут проверю быстро, потому что это косметика».

Этап третий. Тест-дизайн

QA проектирует проверки. Использует математику. Классы эквивалентности. Граничные значения. Попарное тестирование. Таблицы решений.

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

Этап четвёртый. Автоматизация

QA пишет автотесты. Не только для себя. Для всей команды. Чтобы регрессия проходила за минуты. Чтобы новые фичи не ломали старое.

Автоматизация — отдельный мир. Нужно знать Python, фреймворки, CI/CD. Уметь построить архитектуру тестов. Поддерживать её. Обновлять.

Этап пятый. Ручное тестирование

Часть проверок остаётся ручной. Исследовательское тестирование. Юзабилити. Проверка сценариев, которые сложно автоматизировать.

QA садится за продукт и думает как пользователь. Где он запутается? Что его разозлит? Где он уйдёт? Это эмпатия плюс аналитика.

Этап шестой. Регрессия

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

Это рутина. Но без неё продукт развалится за месяц.

Этап седьмой. Работа с багами

QA находит баг. Описывает его. Приоритизирует. Договаривается с разработчиком. Иногда спорит. Доказывает, что это критично. Или соглашается, что можно отложить.

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

Этап восьмой. Релиз и мониторинг

Продукт уходит клиенту. QA смотрит на метрики. Анализирует инциденты. Собирает обратную связь. Возвращается к требованиям. Цикл замыкается.

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

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

Через месяц выяснилось: именно этот сценарий использовали крупные клиенты. Если бы баг ушёл в прод, компания потеряла бы миллионы. QA предотвратил катастрофу. Просто потому что задал вопрос и не отступил.

Что в итоге:

Хороший QA видит картину целиком. Он думает о бизнесе, о пользователе, о команде. Он предотвращает проблемы.

А вы замечали, как QA влияет на успех продукта, или до сих пор считаете, что это просто «тестировщики»?