Готов ли релиз: отчёт QA, который помогает принять решение

Почему пройденные тесты ещё не означают, что обновление готово к выпуску

Перед выпуском новой версии команда часто обсуждает цифры: сколько тестов выполнено, сколько прошло и сколько ошибок найдено. Например, из 100 тестов успешно прошли 98.

Кажется, что результат хороший. Но можно ли на его основании выпускать обновление?

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

Поэтому главный вопрос перед выпуском — не только «Сколько тестов прошло?», но и «Что эти проверки говорят о готовности обновления?»

Разберём это на учебном примере интернет-магазина.

Начните с того, что изменилось

Релиз — это выпуск новой версии приложения для пользователей.

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

• промокод SALE10 даёт скидку 10% на товары;
• скидка не распространяется на доставку;
• просроченный промокод не должен работать;
• итоговая сумма должна оставаться одинаковой в корзине, созданном заказе и при оплате.

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

Начните подготовку к выпуску с трёх вопросов:

1. Что изменилось?
2. Какие действия пользователей затрагивает изменение?
3. Что произойдёт, если новая функция сработает неправильно?

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

Свяжите проверки с последствиями ошибки

Риск — это возможность того, что что-то пойдёт не так, и последствия этого события.

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

Чтобы не ограничиваться общей записью «Промокоды проверены», опишите конкретные действия и ожидаемый результат.

Что может пойти не так	Как проверить	Что должно получиться
Неправильно рассчитывается скидка	Добавить товар за 1 000 ₽ и применить SALE10	Стоимость товара уменьшится до 900 ₽
Скидка ошибочно применяется к доставке	Добавить товар за 1 000 ₽ и доставку за 200 ₽, затем применить SALE10	Товар будет стоить 900 ₽, доставка — 200 ₽. Итого — 1 100 ₽
При оплате скидка исчезает	Применить промокод и оформить заказ с тестовой оплатой	Сумма в корзине, заказе и платеже будет одинаковой
Просроченный промокод продолжает работать	Ввести промокод с истёкшим сроком действия	Скидка не применится, появится сообщение об истечении срока
После применения промокода нельзя оформить заказ	Применить промокод, заполнить данные покупателя и завершить оформление	Заказ успешно создастся
Сообщение об ошибке мешает покупке	Ввести неверный промокод на телефоне	Сообщение будет читаемым и не перекроет поля или кнопку оформления

Эта таблица описывает план проверок. Она ещё не доказывает, что функция работает.

После выполнения проверок нужно зафиксировать фактические результаты.

«Должна получиться сумма 1 100 ₽» — ожидаемый результат.

«Получилась сумма 1 080 ₽» — фактический результат.

Разница между ними — повод зарегистрировать ошибку и разобраться в её причине.

Покажите результаты, а не только список тестов

В отчёте перед выпуском должно быть видно, что действительно проверено на версии, которую команда собирается выпустить.

Например, результаты учебного тестирования могут выглядеть так:

Проверка	Результат	Что это означает для выпуска
Скидка на товар за 1 000 ₽	Пройдено: стоимость уменьшилась до 900 ₽	Проверенный сценарий работает по требованиям
Скидка не применяется к доставке	Ошибка: итоговая сумма — 1 080 ₽ вместо 1 100 ₽	Расчёт неверный. Команда решила не включать функцию до исправления
Сумма не меняется при оплате	Пройдено: суммы совпадают	В проверенном сценарии расхождений нет
Применение промокода на iPhone	Не проверено	Поведение на этой платформе пока неизвестно

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

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

Не путайте «не проверено» и «ошибок не найдено»

Предположим, тестировщик проверил промокод на компьютере и Android, но не успел проверить на iPhone.

Корректная запись:

Применение промокода на iPhone не проверено. Результат неизвестен.

Фраза «Ошибок на iPhone не найдено» здесь вводит в заблуждение: читатель может решить, что проверка состоялась.

Разделяйте три состояния:

• Проверено, результат соответствует требованиям.
• Проверено, обнаружена ошибка.
• Не проверено, результат неизвестен.

Для непроверенного сценария укажите причину и дальнейшее действие:

Нет доступного устройства для проверки на iPhone. Команда решила завершить эту проверку до включения функции для пользователей.

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

Не считайте каждое падение автотеста подтверждённым багом

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

В отчёте важно различать:

• подтверждённую ошибку приложения;
• ошибку самого теста;
• проблему тестового окружения;
• падение, причина которого ещё не установлена.

Если разобраться пока не удалось, напишите прямо:

Автотест оплаты упал. Причина не установлена. Успешная работа этого сценария пока не подтверждена.

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

Для решения о выпуске важно понимать, есть ли надёжный результат проверки важного сценария.

Соберите короткий отчёт перед выпуском

Начать можно с трёх разделов.

1. Что проверили

Перечислите важные сценарии и их результаты.

Проверили расчёт скидки на товары, обработку просроченных промокодов и сохранение суммы при тестовой оплате.

Избегайте слишком широких формулировок вроде «Оплата работает», если проверили только один способ оплаты в одном браузере.

2. Какие ошибки остаются

Опишите не только название ошибки, но и её влияние.

Промокод уменьшает стоимость доставки, хотя по требованиям скидка должна применяться только к товарам. В проверенном примере покупатель платит на 20 ₽ меньше положенного.

Так читателю проще понять, почему ошибка важна.

3. Что осталось неизвестным

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

Применение промокода на iPhone не проверено. Причина падения одного из автотестов оплаты ещё не установлена.

Такой отчёт полезнее одного процента успешных тестов: он показывает, что команда знает об обновлении и где остаются пробелы.

Заранее определите, что делать при проблеме после выпуска

Даже после успешных проверок стоит подготовить план действий на случай ошибки у пользователей.

Для функции промокодов ответьте на вопросы:

• При какой проблеме нужно отключить функцию?
• Кто сможет её отключить?
• Как именно выполняется отключение?
• Смогут ли пользователи после этого оформлять заказы без промокода?
• Что делать с заказами, в которых уже применена неправильная скидка?
• Как проверить, что отключение сработало?

Например:

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

Это учебный пример. Конкретные условия остановки и восстановления нужно согласовать для своего продукта.

Откат — возврат к предыдущей версии приложения. Он не обязательно исправляет данные, которые новая версия уже успела создать или изменить. Поэтому возврат версии и восстановление данных стоит рассматривать отдельно.

Зафиксируйте, кто принимает решение о выпуске

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

Но решение о выпуске не должно незаметно превращаться в личную ответственность QA. Команде нужно заранее определить, кто согласует выпуск и принимает оставшийся риск.

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

Запись «Выпускаем с известной ошибкой» недостаточна. Лучше указать:

На узком экране сообщение об ошибке промокода отображается с нарушением отступов. Текст читается, поля и кнопки доступны. Ответственный за выпуск согласовал публикацию с этой проблемой. Исправление запланировано отдельно.

Здесь понятны сама проблема, её влияние и принятое решение.

Чек-лист перед выпуском

• Понятно, что изменилось в новой версии.
• Определены важные пользовательские сценарии.
• Зафиксированы результаты их проверки на выпускаемой версии.
• Описаны оставшиеся ошибки и их последствия.
• Отдельно перечислено то, что не проверено.
• Для важных падений автотестов установлена причина или явно указана неизвестность.
• Подготовлены действия на случай проблемы после выпуска.
• Понятно, кто принимает окончательное решение.

Хороший отчёт не обещает, что ошибок больше нет. Он помогает команде принять обоснованное решение: что уже подтверждено, какие проблемы известны и с какой неопределённостью предстоит выпускать обновление.