Как продакту работать с QA

Кто такой QA и зачем он продакту

QA (Quality Assurance) — это специалист, который проверяет, что продукт работает так, как задумано. И не просто «нажимает кнопочки», а думает за злого пользователя, ищет краевые случаи, ловит регрессы и не пускает в прод то, что сломано.

Боль без хорошего QA выглядит так: команда выкатывает фичу, через два дня в поддержку прилетают жалобы, что «не работает на iPhone X с маленьким экраном при медленном интернете». Продакт срочно дёргает разработчиков, разработчики бросают новый спринт ради хотфикса, метрики проседают, выручка теряется. С QA таких историй сильно меньше — он ловит это до прода.

Для продакта QA — это союзник, а не «ещё одна шестерёнка». Он часто видит продукт глазами пользователя лучше, чем продакт, потому что специально ищет, где сломается.

Критерии приёмки

Критерии приёмки (acceptance criteria) — это список условий, при выполнении которых задача считается готовой. Без них QA проверяет «по ощущениям», и каждый раз вы получаете разный результат.

Хорошие критерии приёмки:

• Конкретные и проверяемые. «Должно работать быстро» — плохо. «P95 загрузки страницы менее 2 секунд» — хорошо.
• Покрывают позитивный и негативный сценарии. Что должно произойти при правильном вводе И при неправильном.
• Включают граничные случаи. Что при пустом значении, длинной строке, отрицательном числе.
• Учитывают аналитику. Какие события улетают, с какими параметрами.
• Описывают разные платформы и состояния, если они отличаются.

Шаблон, который работает: формат «Дано — Когда — Тогда» (Given-When-Then).

Дано: пользователь авторизован и находится на странице корзины.
Когда: он нажимает «Оплатить» с пустой корзиной.
Тогда: показывается сообщение «Корзина пуста», страница не уходит на оплату,
       событие checkout_blocked отправлено в аналитику.

Критерии пишет продакт, согласовывает с QA до начала разработки. Если QA говорит «не понятно, как это проверить» — критерий плохой, переписывайте.

Тест-кейсы и регресс

Тест-кейс — это последовательность шагов, которые QA выполняет, чтобы проверить конкретный сценарий. Тест-кейсы пишет QA, продакт их согласовывает.

Виды тестов, которые стоит знать продакту:

• Функциональные — проверяют, что фича работает по требованиям.
• Регрессионные — проверяют, что не сломалось то, что работало раньше.
• Smoke — быстрая проверка ключевых сценариев перед релизом.
• Нагрузочные — что произойдёт при большом количестве пользователей.
• Тесты безопасности — попытки сломать продукт намеренно.

Регрессия — это место, где много фич превращается в катастрофу. Каждая новая фича может сломать старую. Без хорошего регресса вы будете чинить старые фичи в каждом релизе.

Что помогает:

• Автотесты на ключевые сценарии. Платно по времени QA, но возвращается через спринт-два.
• Регрессионный чек-лист, который запускается на каждый релиз.
• Среды для тестирования — staging, который похож на прод.

Если автотестов нет — это одна из первых инвестиций, на которые стоит давить продакту. Это не «техническая роскошь», это страховка от факапов на проде.

Баги: приоритизация и работа

Баги делятся по приоритету и тяжести. Не путайте эти понятия:

• Тяжесть (severity) — насколько сильно сломано. Critical (продукт не работает), High (важная функция сломана), Medium (есть обходной путь), Low (косметика).
• Приоритет (priority) — насколько срочно чинить. Зависит от тяжести И от бизнес-контекста: сколько пользователей затронуто, есть ли обходной путь, сколько денег теряется.

Приоритет ставит продакт. Тяжесть ставит QA. Иногда они расходятся: косметический баг (Low severity) на главной странице может быть Critical priority, потому что портит впечатление миллиону пользователей в день.

Что важно в работе с багами:

• Не сваливать всё в один бэклог с фичами. Баги тушите быстрее.
• Регулярно делать «bug bash» — день, когда команда специально ищет баги.
• Считать общее количество открытых багов и не давать ему расти. Если баги копятся — что-то не так с процессом.
• Постмортемить критические баги. Не «кто виноват», а «как сделать, чтобы такого не повторилось».

Релизы и go/no-go

Решение «релизить или нет» (go/no-go) принимает продакт, на основе данных от QA. Это не «QA сказал — значит так». Это диалог.

Что нужно знать перед go:

• Все критерии приёмки выполнены.
• Регресс пройден на ключевых сценариях.
• Critical и High баги починены или явно отложены с обоснованием.
• Аналитика подключена и работает.
• Есть план отката, если что-то пойдёт не так.

Что делать, если QA против релиза:

• Слушайте. У него есть данные, которых у вас нет.
• Разбирайтесь конкретно: что именно сломано, кого затронет, как часто.
• Принимайте решение совместно. Иногда выгоднее релизнуть с известным багом, чем сдвигать. Иногда — нет.
• Если решили релизить с риском — фиксируйте это письменно. Чтобы потом не было «а я говорил».

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

Частые ошибки

• Не подключать QA до разработки. QA должен видеть критерии приёмки и спорить с ними ДО, а не после.
• Игнорировать регресс. «Зачем тестить старое, мы же не трогали» — самая частая причина проседания качества.
• Считать QA «нажимателем кнопок». Хороший QA — это инженер, который умеет в архитектуру и даёт ценные советы.
• Релизить с критическими багами «потом починим». «Потом» обычно не наступает, и продукт превращается в свалку.
• Не давать QA доступ к аналитике. Без аналитики он не может проверить, что события отправляются.
• Не делать постмортемы. Каждый критический баг — урок. Без разбора уроки повторяются.
• Давить на QA сроками. Это приводит к пропущенным багам и потере доверия.

Связанные темы

• Как продакту работать с разработчиками
• Как продакту работать с дизайнером
• Как продакту ставить задачи команде
• Как продакту разрешать конфликты в команде

FAQ

Нужен ли QA в маленькой команде?

Лучше, чтобы был. В стартапах часто эту роль совмещает разработчик или продакт, но качество всегда страдает.

Кто пишет тест-кейсы — продакт или QA?

QA пишет, продакт ревьюит и согласовывает. Продакт даёт критерии приёмки, не сами кейсы.

Что делать, если QA пропустил критический баг?

Разбирать процесс, не человека. Где была дыра: не было критерия приёмки, не было регресса, не было автотеста? Чините процесс.

Стоит ли вкладываться в автотесты?

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

Как считать качество продукта?

Через метрики: количество критических багов в проде, MTBF (среднее время между сбоями), доля пользователей, столкнувшихся с ошибкой, скорость исправления.

Можно ли релизить с известными багами?

Да, если они не критичные и есть план починки. Главное — фиксировать решение и не оставлять баги в подвешенном состоянии.

---

Готовьтесь к собесу на продакта — откройте тренажёр с 1500+ вопросами по аналитике и продукту.