Пятница, 17:40. Через два часа ваша команда должна выпустить новую версию личного кабинета.
На финальной проверке вы находите несколько ошибок. Часть выглядит страшно, часть почти безобидно, но времени на фиксы и полный повторный прогон уже нет.
Сможете ли вы решить, какие ошибки должны заблокировать выезд, а какие можно выкатить в прод?
Правила оценки
Перед выпуском новой версии необходимо оценивать не сам факт бага, а его последствия. Наличие ошибок еще не означает, что релиз нужно переносить. Главный вопрос, который нужно задавать себе: «Что случится с пользователем, продуктом и командой, если мы выпустим релиз в текущем состоянии?».
Кого затронет ошибка
Насколько широко проявляется проблема? У одного пользователя или у половины клиентов? Здесь важно не скатиться в простую арифметику, иногда редковоспроизводимый баг в оплате, выдаче доступов или сохранении данных опаснее массовой ошибки в необязательном баннере.
Полезные вопросы:
Сколько пользователей столкнется с ошибкой?
Это новые пользователи, платящие клиенты, администраторы или внутренняя команда?
Ошибка в основном сценарии или в редком дополнительном/обходном?
Есть ли сейчас повышенный трафик клиентов, который вы ожидаете? Типа рассылок, новых рекламных кампаний, сезонного пика или крупного запуска.
Если ошибка затрагивает небольшой процент пользователей, но находится в важном сценарии, ее нельзя автоматически считать незначительной.
Что именно ломается
Дальше нужно понять, что пользователь теряет из-за ошибки. Особенно внимательно стоит относиться к ошибкам, которые затрагивают:
Что затронуто |
Почему это опасно |
|---|---|
Деньги |
Возможны неверные списания, двойные операции, споры с клиентами |
Данные |
Пользователь может потерять результат работы или получить неверную информацию |
Доступ |
Человек не может войти, выйти, восстановить пароль или ограничить доступ к профилю |
Личные сведения |
Даже временное отображение данных после выхода из аккаунта может быть серьёзным риском |
Заявки и заказы |
Ошибка может напрямую повлиять на продажи и работу поддержки |
Отчёты |
Неверные цифры могут привести к неправильным решениям внутри компании |
Главное правило. Если ошибка искажает деньги, данные, доступ или личную информацию, её нужно разбирать жёстче, даже если она воспроизводится не всегда.
Можно ли обойти проблему
Иногда ошибка неприятная, но у пользователя или команды есть простой обходной путь. Например, заявку можно отправить повторно, письмо можно выслать вручную, а отчёт можно временно смотреть в старой версии.
Но обходной путь снижает риск только при нескольких условиях:
Он понятен пользователю или поддержке.
Он не требует сложных ручных действий.
Он не создает новых ошибок.
Команда готова использовать его сразу после релиза.
О нем заранее знают саппорты.
Если поддержка не предупреждена, инструкции нет, а ошибка может массово прийти в обращения, выпускать версию опасно.
Можно ли быстро исправить или откатить изменение
На решение влияет не только сама ошибка, но и то, насколько команда готова действовать после релиза.
Вопросы, которые стоит уточнить для этого раздела:
Можно ли отключить этот функционал отдельно?
Есть ли способ быстро вернуть старую версию?
Сколько времени займет исправление?
Есть ли риск испортить уже существующие данные?
Кто будет принимать решения и решать проблему ночью или в выходные, если проблема проявится позже?
Если после релиза фиксы будут особенно сложные, а последствия критичные, релизить нельзя.
Увидит ли команда проблему после выпуска
Есть ли у вас возможность отследить количество воспроизведений бага пользователями? Если после релиза вы не сможете увидеть, сколько клиентов столкнулось с проблемой и узнавать будете о ней только из жалоб, то это плохой признак.
Перед релизом необходимо понять:
Записывается ли баг в логи?
Видно ли количество срабатываний бага?
Можно ли отличить единичный сбой от массового?
Есть ли человек, который будет следить за багом после релиза?
Понятно ли, при каких признаках необходимо откатить версию?
Если новая часть продукта важная, а наблюдать за ней невозможно, это может быть причиной перенести релиз.
Что будет, если ничего не сделать до утра
Этот вопрос звучит как самый простой, но он же является очень полезным. Если за ночь накопится несколько увиденных пользователями некрасивых экранов это одно. Если за ночь появятся сотни обращений в поддержку, заказы с неверными данными, потерянные заявки, повторные списания и т. д. - это уже совсем другой уровень проблемы.
Чем сложнее будет разбирать последствия, тем осторожнее нужно принимать решение. Так что перед тем как одобрить или запретить релиз, пройдитесь по этим правилам оценки и только после этого принимайте решение.
Баг 1. После оплаты пользователь видит бесконечную загрузку
Пользователь оформляет заказ, переходит на страницу оплаты, успешно оплачивает покупку и возвращается обратно в личный кабинет. Но вместо страницы с подтверждением заказа видит ее бесконечную загрузку.
На первый взгляд это выглядит как серьёзная ошибка: сценарий оплаты визуально не завершился, пользователь не понимает, прошёл заказ или нет, и может начать нажимать назад, обновлять страницу или писать в поддержку.
Что известно на момент проверки:
Вводная |
Значение |
|---|---|
Деньги списываются |
Да |
Заказ создаётся в системе |
Да |
Письмо с подтверждением уходит |
Да |
Повторного списания нет |
Не обнаружено |
Ошибка воспроизводится |
Примерно 1 раз из 20 |
Условия воспроизведения |
Чаще на медленном интернете |
Поддержка может найти заказ вручную |
Да |
Пользователь видит номер заказа на экране |
Нет |
Релизим?
Скрытый текст
Резкое решение здесь принять легко, потому что оплата же сломана. Однако это не совсем точная формулировка, поскольку сломана не оплата, а отображение ее результата. И это важное различие. Если деньги списываются, заказ создаётся, письмо уходит, а повторных списаний нет, то система сохраняет главное: операция проходит, данные не теряются, пользователь получает подтверждение по почте.
Но есть и обратная сторона. Для пользователя сценарий всё равно выглядит сломанным. Он не видит финального подтверждения, не понимает, оформлен ли заказ, и может потерять доверие к сервису. Особенно если речь идёт о дорогой покупке, бронировании, обучении, медицине, билетах или другом чувствительном сценарии.
Что нужно проверить?
Сначала нужно убедиться, что ошибка действительно ограничена только экраном подтверждения. Минимальный список проверок:
Что проверить |
Зачем |
|---|---|
Создаётся ли заказ каждый раз |
Чтобы исключить потерю оплаченных заказов |
Нет ли двойного списания |
Чтобы исключить финансовый риск |
Уходит ли письмо с подтверждением |
Чтобы пользователь получил хотя бы один надёжный признак успешной оплаты |
Отображается ли заказ в личном кабинете после обновления страницы |
Чтобы понять, может ли пользователь сам убедиться в успехе |
Видит ли поддержка такой заказ в системе |
Чтобы можно было быстро помочь пользователю |
Есть ли запись об ошибке в журнале |
Чтобы команда понимала масштаб проблемы после выпуска |
Можно ли временно отключить новый экран подтверждения |
Чтобы снизить риск без отмены всего выпуска |
Особенно важно проверить не один успешный пример, а несколько повторов: быстрый интернет, медленный интернет, мобильное соединение, разные браузеры, повторный переход после оплаты, обновление страницы, возврат кнопкой «Назад».
В этой ситуации, как и в других, я бы рассуждала не от факта бага, а от последствий которые он принесет.
Теряются ли деньги или заказы? Если да - релиз нужно останавливать.
Может ли пользователь понять, что заказ оформлен? Если письмо приходит сразу, а заказ появляется в личном кабинете, риск ниже. Если пользователь нигде не видит подтверждения, риск выше.
Можно ли быстро заметить возникновение проблемы, до жалоб пользователей? Если команда узнает о проблеме только по жалобам, выпускать опаснее.
Можно ли снизить риск временным решением? Например вернуть старую страницу успешной оплаты, отключить новый экран или предупредить поддержку.
Если в данной ситуации соблюдаются три условия: деньги списываются корректно, заказ всегда создается, нет потерь данных и повторных списаний, я бы не стала блокировать релиз до исправления.
Баг 2. Профиль сохраняется без обязательного телефона
В новой версии личного кабинета изменили форму профиля. Теперь телефон помечен как обязательное поле, потому что без него менеджер не сможет быстро связаться с пользователем по заявке.
На финальной проверке выяснилось, что проверку можно обойти. Если сначала заполнить профиль полностью, потом удалить телефон и сразу нажать «Сохранить», форма сохраняется без ошибки. На экране появляется сообщение «Изменения сохранены».
Что известно на момент проверки:
Вводная |
Значение |
|---|---|
Поле «телефон» отмечено как обязательное |
Да |
Форму можно сохранить без телефона |
Да |
Ошибка воспроизводится стабильно |
Да, при определённом порядке действий |
Старые пользователи обычно уже имеют телефон в профиле |
Да |
Новые пользователи могут оставить профиль без телефона |
Да |
Заявка без телефона создаётся |
Да |
Менеджер видит такую заявку |
Да |
Связаться с пользователем можно по почте |
Да |
Автоматическая обработка заявки ломается |
Требует проверки |
Релизим?
Скрытый текст
Опять же, смотрим на последствия. Обязательное поле может быть обязательным по разным причинам.
Если телефон нужен только для удобства менеджера, а заявка всё равно создаётся и пользователь доступен по почте, риск один. Это неприятно, но не обязательно останавливает релиз.
Если же без телефона заявка не проходит дальше, не попадает в обработку, теряется в очереди или ломает автоматический сценарий, ситуация становится намного серьёзнее. Тогда ошибка уже влияет не на форму, а на получение заявок и работу бизнеса.
Поэтому правильный вопрос звучит не так: «Можно ли сохранить форму без обязательного поля?» Правильный вопрос: что происходит с пользователем и заявкой после такого сохранения?
Что нужно проверить?
Сначала нужно пройти путь пользователя дальше, а не останавливаться на самой форме.
Минимальный список проверок:
Что проверить |
Зачем |
|---|---|
Создаётся ли заявка без телефона |
Чтобы понять, теряется ли пользовательское действие |
Попадает ли заявка в очередь менеджеров |
Чтобы исключить потерю заявки внутри системы |
Видит ли менеджер, что телефона нет |
Чтобы не было скрытой ошибки в обработке |
Можно ли связаться с пользователем по почте |
Чтобы оценить наличие обходного пути |
Не ломается ли автоматическая обработка |
Чтобы исключить технический сбой после формы |
Не уходит ли заявка в неверный статус |
Чтобы пользователь не завис без ответа |
Можно ли добавить проверку на стороне сервера |
Чтобы быстро закрыть риск, а не только внешний симптом |
Сколько новых пользователей ожидается после выпуска |
Чтобы оценить масштаб проблемы |
Какой ход мысли здесь правильный
У этой проблемы два уровня.
Первый уровень ошибка в форме. Пользователь может сохранить профиль без поля, которое обозначено как обязательное. Это дефект, его нужно исправлять.
Второй уровень последствия для процесса. Вот он и определяет, можно ли выпускать версию.
Если заявка без телефона создаётся, попадает менеджеру, видна в системе, а пользователь доступен по почте, риск управляемый. Да, менеджеру будет неудобнее. Да, часть заявок придётся обрабатывать вручную. Но пользовательское действие не потеряно.
Если же заявка без телефона не попадает в обработку, зависает в промежуточном статусе или ломает интеграцию с другой системой, это уже риск потери заявок. Тогда релизить нельзя.
Если подтверждено, что: заявка создается и видна менеджеру, пользователь доступен по почте, автоматическая обработка не падает и поддержка или менеджеры понимают, что делать с такими заявками, то релиз можно не блокировать.
Если же заявка без телефона не проходит дальше, теряется, не видна менеджеру или ломает связанный процесс, релиз нужно отложить до исправления.
Баг 3. В отчете неверно считается итоговая сумма
В новой версии изменили отчёт по заказам. Теперь в нём отдельно показываются сумма до скидки, размер скидки, итоговая сумма и сумма по каждому заказу.
На финальной проверке вы заметили странность. Если в отчёте есть заказы со скидкой и копейками, итоговая сумма иногда отличается от суммы строк. Разница небольшая, несколько копеек или рублей, но она есть.
На первый взгляд ошибка может показаться не самой опасной. Платежи проходят правильно, заказы создаются, пользователи ничего не теряют. Проблема только в отчёте.
Но перед выпуском нужно понять, кто пользуется этим отчётом и какие решения принимает на его основе.
Что известно на момент проверки:
Вводная |
Значение |
|---|---|
Ошибка возникает в отчёте по заказам |
Да |
Платежи проходят корректно |
Да |
Сумма в самом заказе корректная |
Да |
Ошибка появляется при скидках и округлении |
Да |
Разница обычно небольшая |
От копеек до нескольких рублей |
Пользовательские заказы не теряются |
Нет |
Отчёт используют менеджеры и бухгалтерия |
Да |
Старый отчёт пока можно открыть |
Да |
Новый отчёт должен пойти в выпуск вместе с версией |
Да |
Релизим?
Скрытый текст
Здесь легко ошибиться в обе стороны.
С одной стороны платежи не ломаются, значит это неважно. Но отчет это не просто красивое отображение данных, по ним сверяют суммы, ищут расхождения, принимают управленческие решения, разбирают спорные заказы и готовят данные для других отделов.
С другой стороны, автоматически заблокировать релиз из-за любой ошибки в сумме, тоже ошибка. Если новый отчёт пока не является основным, старый отчёт доступен, а данные в заказах и платежах корректны, возможно, достаточно временно отключить новый отчёт или не давать его бухгалтерии до исправления.
Правильный вопрос здесь может ли эта ошибка привести к неверным решениям, лишней ручной работе или потере доверия к данным?
Даже разница в несколько рублей может быть серьёзной, если отчёт используют для сверки, закрытия периода или расчётов с клиентами. И наоборот, такая же разница может быть терпимой, если отчёт внутренний, предварительный и рядом есть надёжный источник данных.
Что нужно проверить перед решением
Минимальный список проверок:
Что проверить |
Зачем |
|---|---|
Корректна ли сумма в самом заказе |
Чтобы понять, затронуты ли реальные данные |
Корректна ли сумма платежа |
Чтобы исключить ошибку в деньгах |
Где появляется расхождение: в строках или только в итоговой сумме |
Чтобы найти место ошибки |
Как считается скидка |
Чтобы проверить порядок округления |
Совпадают ли данные в старом отчёте |
Чтобы понять, есть ли надёжный обходной путь |
Кто пользуется новым отчётом |
Чтобы оценить последствия |
Будут ли данные выгружаться наружу |
Чтобы исключить передачу неверных сумм дальше |
Можно ли временно скрыть новый отчёт |
Чтобы не задерживать весь выпуск, если проблема изолирована |
Особенно важно проверить, не расходятся ли данные между разными частями системы.
Первое, что нужно сделать, это пройти по реальным операциям. Нужно убедиться, что пользователь оплатил правильную сумму, заказ создан с правильной стоимостью, скидка применена корректно, а платёжная информация не искажена. Если в этой части есть ошибки - релиз нужно блокировать.
Далее смотрим на само отчетное представление. Если реальные данные корректны, а ошибка только в новом отчёте, решение зависит от того, насколько этот отчёт важен сразу после выпуска.
Если отчёт используют бухгалтерия, руководители или отдел продаж для сверки и принятия решений, баг становится критичным. Даже если пользователь ничего не видит, команда внутри продукта начинает работать с неверными числами. Это может привести к ручным проверкам, спорам, неправильным выводам и потере доверия к отчётам.
Если же новый отчёт пока можно не показывать, а старый отчёт считает правильно, риск можно снизить. Зарелизить версию без нового отчёта или оставить его только для внутренней проверки.
Я бы не выпускала новый отчёт в открытое использование, пока итоговая сумма считается неверно. Решение здесь зависит от того, можно ли отделить отчёт от остальных изменений.
Если подтверждено, что: платежи проходят правильно, суммы в заказах корректные, старый отчет доступен и считает верно, новый отчет можно скрыть или не использовать, ошибка не попадает в выгрузки, документы и новые системы, то релиз можно не блокировать, но новый отчёт все равно нужно отключить до исправления.
Если же новый отчёт нельзя отключить, он сразу попадёт к бухгалтерии, используется для расчётов с клиентами или уходит в выгрузки, откладываем релиз до исправления.
На финальных прогонах мы принимаем решение не по факту возникновения багов, а по его последствиям. В описанных выше кейсах нет универсального ответа релизить или нет, но именно это и говорит о том, что QA не просто говорит команде о найденных багах. Он помогает оценить риск, выбрать временное решения и вовремя остановить релиз там, где последствия невозможно безопасно контролировать.
Если вы только присматриваетесь к профессии QA или хотите систематизировать базу, начать можно с подготовительного курса OTUS «Ручное тестирование». Он поможет разобраться в логике проверок, видах дефектов, тестовой документации и подходе к оценке качества продукта.
Познакомиться с подходом можно на бесплатных открытых уроках OTUS. Их проводят преподаватели-практики, а формат помогает заранее посмотреть, как устроено обучение, задать вопросы и разобрать прикладные инструменты, которые QA использует в работе с API, автотестами и проверкой критичных сценариев.
21 мая, 20:00. «ИИ как ассистент QA: пишем API-тесты с нуля». Записаться
4 июня, 20:00. «API под контролем: тестирование сервисов с помощью Postman». Записаться