Мы же всё протестировали, откуда баги на проде? Разбор от QA с 10+ годами опыта

«Критичный баг на проде!»

Это сообщение в рабочем мессенджере, пожалуй, самый страшный сон тестировщика. 

Почему они всё-таки могут просочиться на прод? Каков порядок действий? Расскажу коммьюнити dev.by. 

---

Кто пишет: Александра Ерёмина, QA Lead Engineer с опытом работы на 40+ проектах, преподаватель и автор блога «Всё о тестировании и QA». 

Если вы хотите поделится необычными практиками, которые вы используете в работе с коммьюнити, пишите на [email protected].

---

Дисклеймер. В этой статье рассматриваем ситуации, когда:

1. В команде есть тестировщик/QA-специалиста.

2. Тестировщик — не стажёр/джун (или джун, но помимо него, в команде тестирования есть еще тестировщики уровня middle и/или выше).

3. В команде есть договоренность о том, что тестирование проводится до релиза на прод.

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

Команда решила зарелизить новый или изменить существующий функционал, не поставив в известность тестировщиков

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

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

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

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

Выяснилось, что релиз всё-таки был. Проджект-менеджер договорился с командой разработки залить его на прод в обход команды тестирования. 

Команда разработки делала рефакторинг кода. По договоренности с проджект-менеджером задача под это в Jira не заводилась и на общих дейликах это не озвучивалось. Разработчики самостоятельно провели тестирование и подтвердили, что всё работает. В пятницу вечером, по окончании рабочего дня новый код выкатили на прод.

А в субботу утром выяснились две новости.

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

Плохая: почему-то при этом в кошельке компании баланс уменьшился на пятизначную сумму. В долларах. И продолжает быстро уменьшаться. 

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

На мой вопрос «А зачем вы это сделали?» был ответ: «Если бы мы вам [тестировщикам] сказали о релизе, вы бы его тестили, еще бы и регрессию сделали, нашли баги, релиз бы затормозился, мы бы потеряли время»…

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

Но не тестировщик решает:

• какой приоритет у багов;

• какие баги и в какие сроки должны быть пофикшены;

• может ли фича уйти в релиз с текущими багами или нет.

Это ответственность менеджера, не тестировщика. 

Выводы:

• заранее информировать о фичах в релизе всю команду;

• регулярно обновлять статус этих фич;

• если тестирование фичи завершено со статусом «Failed» из-за найденных багов, то «уполномоченное лицо» должно аппрувнуть, какие из багов должны быть пофикшены до релиза, а какие могут быть отложены или отменены; 

• регулярно обсуждать и обновлять приоритет/статус багов, найденных в релизных фичах;

• спорные вопросы (например, если тестировщик считает, что продакт-менеджер недооценил критичность бага) должны быть обсуждены на отдельном митинге с привлечением необходимых лиц (например, ВА, дев-лида и т. д.).

Решение о внесении изменений было сделано уже после завершения тестирования

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

Релизили абсолютно новый функционал — менеджер задач. Работали над ним несколько месяцев. Все стори (больше 10) были протестированы, регрессия почти завершена. Релиз запланирован на послезавтра. И под конец регрессии абсолютно случайно замечаю, что одна из новых фич в статусе «Ready for Release» работает неправильно. А именно — находится в том состоянии, в котором нам ее впервые когда-то передали в тестирование: те же баги, функционал нерабочий и к релизу не готов. 

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

Но, видимо что-то перепутали: в результате заодно откатились и изменения за последние несколько дней в других фичах. И никто этого не заметил. 

Выводы:

• Код фриз (code freeze) — замораживание любых изменений на тестовом окружении, где уже проводится тестирование.
• Нужно обсуждать любые изменения и обязательно ставить в известность команду тестирования.

Баг обнаружен на окружении (браузер, ОС, девайс, разрешение экрана и т. д.), на котором тестирование не проводилось

На одном из крупных проектов я спросила про окружение. Lead Product Manager сбросил список браузеров, ОС и девайсов и даже указал приоритеты окружений.

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

Выяснилось, что, например, через десктопный браузер Mozilla FF (под Windows) в нашем приложении работает менее 2% пользователей. А этот браузер по приоритету у нас значился вторым после Google Chrome! Почти 15% юзеров пользовались приложением через мобильный браузер Safari, который вообще не входил в тестовое окружение. 

Список тестового окружения актуализировали. С тех пор баги от пользователей мобильного браузера Safari нам больше не приходили.

Выводы: 

• На новом проекте всегда спрашивайте про окружение, почему оно выбрано и когда список последний раз актуализировался. 
  Если заранее оговоренного тестового окружения нет (или на проекте нет продакт-менеджера), попросите того, кто отвечает за развитие продукта, это окружение вам предоставить. В крайнем случае составьте такой список сами и согласуйте с тем, кто отвечает за развитие продукта.
• Уточняйте, на каком окружении обнаружен баг и насколько это популярно у пользователей. 
• Если список тестового окружения большой и/или текущий проектный треугольник не позволяет постоянно проводить тестирование на всём запланированном окружении, то выберите 2-3 наиболее приоритетных. Остальные окружения вынесите в регулярно проводимую отдельную регрессию (например, 1 окружение 1 раз в месяц или реже).

Баг был обнаружен в той части функционала, которая не была покрыта тестами

Как-то меня попросили подключиться к проекту, где скопилась большая очередь задач на тестирование (больше 1000 задач на 2 тестировщика) и нужно было помочь коллегам эту очередь «расчистить». 

На мой вопрос, как так получилось, мне рассказали предысторию.

Жил да был крупный европейский заказчик с интернет-магазином в 20+ странах. И нанял он подрядчика на разработку и поддержку этого интернет-магазина. А подрядчик нанял нашу компанию на работу в shadow mode. Наши тестировщики работали хорошо, а команда ВА+dev подрядчика — не очень, поэтому багов в каждой фиче находилось очень много.

И в какой-то момент европейский заказчик задал вопрос: «А почему это у нас зарепортано так много багов? У нас что, плохие разработчики?»

Подрядчик задумался, да и придумал: сократить количество багов можно… (барабанная дробь) сократив часть команды тестирования. 

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

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

Минусы: зато теперь больше багов стали находить пользователи. На проде.

А «бонусом» проектная команда получила еще и bottleneck в тестировании новых фич. И теперь уже к тестированию пришлось подключать самих разработчиков. Естественно, качество тестирования таких фич стало еще хуже.

И вот уже европейский заказчик пришёл с новым вопросом: «А как так получается, что у нас выросло количество багов на проде?»

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

Выводы:

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

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

• Согласуйте, насколько глубоко и широко можно успеть протестировать все фичи за утвержденный срок силами текущей команды тестирования. Например, будет проведен только смоук-тест, а тест критического пути и расширенное тестирование проводиться не будут.
  Чек-лист проверок нужно пошарить на всех ключевых членов команды: проджект-менеджер, продакт-менеджер/ВА, лида команды разработки, — и попросить их в течение какого-то разумного срока указать те критичные проверки, которые необходимо добавить вместо существующих (или в дополнение к ним). И согласовать, иначе ваш чек-лист будет считаться аппрувнутым по умолчанию.
• Если первый вариант не подходит, согласуйте, какие именно фичи целиком может проверить команда тестирования, а тестирование каких фич целиком могут взять на себя другие члены проектной команды.
• Если на проектах постоянно не хватает рук, то имеет смысл написать краткую тест-стратегию и зафиксировать в ней договоренность о глубине/ширине тестирования, а также о том, кто будет в нем участвовать.
• Если на проекте ведётся детализированная документация, можно всей командой тестировать одну фичу. Например, смоук-тест проводят разработчики, тест критического пути — QA, а расширенное тестирование — BA.  

Тестовые данные отличаются от реальных данных с прода

История из жизни. И снова крупный заказчик. На этот раз в сфере консалтинга. Приложение работает с огромными массивами данных ритейл-компаний.

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

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

Заказчику были предложены варианты:

1. Передать для тестирования данные с прода, изменив или удалив информацию о компаниях, датах и прочую информацию, по которой можно было бы «вычислить» компании, людей, счета и т. д.

2. Дать доступ к проду хотя бы кому-то из команды разработки и/или тестирования (даже с подписанием дополнительного договора о неразглашении).

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

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

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

Выводы:

• Всегда согласовывайте с продакт-менеджером или другим лицом, отвечающим за развитие продукта, откуда команда может брать данные для тестирования и разработки; насколько они соответствуют реальным бизнес- и пользовательским данным и какие специфичные наборы данных могут быть в реальности.
• По мере обнаружения багов, связанных с разницей в данных на тестовом стенде и проде, обновляйте и дополняйте свои тестовые данные, а также добавляйте чек-проверки или тест-кейсы для них.

Этот список неполный, моя коллекция причин состоит из примерно 20 пунктов. Если статья понравится коммьюнити dev.by, с удовольствием напишу продолжение. 

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

Первоначально этот текст был опубликован на habr.ru. Публикуем его с незначительными изменениями. 

Мнение автора может не совпадать с мнением редакции. 

---

dev.by, как и другим честным медиа, сегодня очень сложно: редакция работает за пределами страны, а наши рекламные доходы сократились в несколько раз. Но мы справляемся — с вашей помощью. Это вы делитесь с нами инфоповодами, мнениями, опытом, временем и вниманием. А 220 читателей поддерживают нас донатами.

В 2023 году мы хотим собрать 1000 читателей-подписчиков.

Помочь нам можно через Patreon. 
Из Беларуси — через Donorbox.
И ещё криптой, тут кошельки.
Спасибо, что прочитали это сообщение.

Что ещё почитать про тестирование: 

• Тестирование — это не «простая точка входа в ИТ». Мифы разрушает Артём Русов; 
• Как научиться тестировать самому и найти работу в трудные времена; 
• Найдёт код, сымитирует собес, поможет с английским. 19 нейросеток для учёбы и работы (не ChatGPT);