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

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

Всем привет! Меня зовут Александра Ерёмина, я QA Lead Engineer и автор блога "Всё о тестировании и QA" (@eremina.proqa).

В тестировании я уже больше 10 лет, попробовала себя в разных ролях на 40+ проектах. И конечно, уже давно понимаю, что поиск багов - это не главная цель тестирования. Найти все баги в приложении/фиче - это вообще цель очень далёкая от реалистичности. Да и не цель вовсе.

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

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

А вот почему они всё-таки могут просочиться на прод и каков порядок действий тестировщика в таком случае, - это один из важных вопросов в построении не только QA-процессов, но и в целом - ВСЕХ процессов на проекте. И, к слову, один из самых распространенных вопросов в собеседованиях на позицию QA-специалиста.

Вот этот вопрос я и предлагаю рассмотреть и обсудить. 

В первую очередь всегда важно помнить, что при обнаружении бага на проде не должно быть места панике и самобичеванию. Зато должно найтись место для т.н. root cause analysis - анализа причин, почему баг, который не был обнаружен при тестировании ДО релиза, появился на проде ПОСЛЕ релиза.

Заранее оговорюсь, что в этой статье будут рассматриваться проекты и команды, где:

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

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

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

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

Итак, в этой статье я рассмотрю ТОП-5 наиболее распространенных причин появления багов на проде, которые НЕ зависят напрямую от тестировщиков. Данный список составлен на основании моего опыта и опыта моих коллег. 

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

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

Ответ: и может, и приходит. 

Хотя надо отдать должное: я не сталкивалась с такими ситуациями на крупных серьёзных проектах в аутсорсе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эти решения принимает проджект-менеджер, продакт-менеджер, деливери-менеджер, … (где как принято), но НЕ тестировщик.

Какие выводы? 

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

• заранее информировать ВСЮ команду, какие фичи будут включены в релиз;

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

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

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

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

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

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

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

• “Ой, мы ведь просто откатили изменения к тем, что были протестированы раньше”;

• “Да мы тут буквально одну мелкую правку внесли и сами все потестили”;

• “Тут просто поле/чек-бокс/надпись убрали/скрыли, стиль поменяли”;

• и т.д.

Когда я присоединилась к одному из проектов, там, как выяснилось, такая ситуация была регулярной. И я с ней “познакомилась” сразу же перед ближайшим релизом.

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

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

Тестировщикам ничего говорить не стали.

Но, видимо, все-таки что-то перепутали: оказалось, что в результате заодно откатились и изменения за последние несколько дней в других фичах. А вот это, к сожалению, ни продакт-менеджер, ни разработчики уже не заметили. Ведь они проверили только поле ввода, а с ним всё было в порядке.

Какие выводы?

На самом деле есть такая хорошая практика: код фриз (code freeze) - замораживание любых изменений на тестовом окружении, где уже проводится тестирование. Конечно, не везде уже построенный git flow позволяет это делать, но в целом, по крайней мере на тех проектах, где я эту практику наблюдала, благодаря такому код фризу релизы были гораздо более “чистыми”. К слову, на этом проекте такой подход тоже помог.

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

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

Есть ТОП-5 вопросов, которые должен задать тестировщик, присоединяясь к проекту. И вопрос про тестовое окружение - один из них!

Как-то я присоединилась к крупному проекту (веб-приложение). И естественно, спросила про тестовое окружение. Lead Product Manager сбросил список браузеров, ОС и девайсов, на которых надо было тестировать функционал. И даже указал приоритеты окружений.

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

Я попросила продакт-менеджера перепроверить, откуда к нам сейчас приходят пользователи.

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

А вот почти 15% юзеров пользовались приложением через мобильный браузер Safari, который вообще не входил в тестовое окружение. 

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

Какие выводы?

1. При подключении к новому проекту всегда уточняйте у продакт-менеджера (или другого лица, отвечающего за развитие продукта):

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

б) почему выбрано именно это окружение (к слову, так вы еще и дополнительно узнаете больше о группах ваших пользователей, их географии и предпочтениях);

в) когда последний раз оно актуализировалось.

Если заранее оговоренного тестового окружения нет (или на проекте нет продакт-менеджера), попросите того, кто отвечает за развитие продукта, это окружение вам предоставить. Естественно, объясните ему, зачем это нужно и к каким негативным последствиям может привести отсутствие данного списка. 

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

2. Всегда при обнаружении бага на проде в первую очередь уточняйте, на каком окружении (браузер, ОС, девайс, разрешение экрана и т.д.) он был обнаружен. Переуточняйте у продакт-менеджера, насколько это окружение “популярно” у пользователей и нужно ли его добавлять в список для тестирования на постоянной основе (если его там нет). 

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

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

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

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

Мой ответ: не всегда. 

Конечно, если какой-то тест был пропущен QA-командой в силу плохого тест-дизайна, недостаточной квалификации тестировщика для выполнения задачи и других подобных причин (которые мы разберем в следующей статье), то это уже зона прямой ответственности команды тестирования. 

Но вот, если, например, из тестового скоупа намеренно исключаются какие-то проверки:

• в силу сжатых сроков на тестирование;

• большого скоупа срочных задач;

• неприоритетности каких-то юз-кейсов для тестирования;

• и т.д.,

и это согласовано с командой проекта, то тогда это уже не ответственность только лишь тестировщиков. 

Приведу пример.  

Есть такой бородатый и (не)смешной анекдот:

- Как проще всего сделать так, чтобы багов стало меньше?

- Сократить команду тестировщиков!

К большому сожалению, это не анекдот, а вполне себе правда жизни. 

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

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

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

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

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

А что? Вполне логично: меньше тестировщиков -> меньше времени на тестирование -> меньше зарепортанных багов.

Итак, количество тестировщиков уменьшилось. Количество новых фич осталось прежним. Соответственно, пришлось отказаться от глубокого и широкого тестового покрытия. 

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

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

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

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

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

Мораль этой истории и выводы?

В первую очередь: заранее и честно информируйте проджект-менеджера и команду о том, в какие РЕАЛЬНЫЕ сроки может быть протестирован принятый скоуп задач при широком и глубоком тестовом покрытии.

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

1. Согласуйте, насколько глубоко/широко можно успеть протестировать ВСЕ фичи за утвержденный срок силами текущей команды тестирования. 

Например, будет проведен только смоук-тест, а тест критического пути и расширенное тестирование проводиться не будут. 

При этом чек-лист тех проверок, которые вы планируете проводить, нужно пошарить на всех ключевых членов команды (проджект-менеджер, продакт-менеджер/ВА, лид команды разработки) и попросить их в течение какого-то разумного срока указать те критичные проверки, которые необходимо добавить вместо существующих (или в дополнение к ним). И согласовать, что иначе ваш чек-лист будет считаться аппрувнутым по умолчанию.

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

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

Почему я не предлагаю вариант, когда одну и ту же фичу по чуть-чуть тестируют все? Например, смоук-тест проводят разработчики, тест критического пути - QA, а расширенное тестирование - BA. 

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

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

Если такая ситуация возникает постоянно и понятно, что текущая QA-команда недостаточно укомплектована для тестирования принятого скоупа задач в утвержденные сроки, то имеет смысл написать краткую тест-стратегию и зафиксировать в ней договоренность о глубине/ширине тестирования, а также о том, кто будет в нем участвовать.

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

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

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

История из жизни.

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

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

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

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

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

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

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

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

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

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

Какие же выводы?

Всегда согласовывайте с продакт-менеджером или другим лицом, отвечающим за развитие продукта:

• откуда команда может брать данные как для тестирования, так и для разработки;

• насколько имеющиеся данные соответствуют реальным бизнес- и пользовательским данным;

• какие специфичные наборы данных могут быть в реальности.

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

Конечно же, это не все причины, из-за которых могут появляться баги на проде. Моя коллекция таких причин (не зависящих напрямую от тестировщиков) состоит приблизительно из 20 пунктов. 

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

А пока всем небезразличным предлагаю в комментариях поделиться своими ТОП-5 причин появления багов на проде. Думаю, практически у каждого ИТ-шника (и не только тестировщика) есть похожий список на тему “Что виновато и как делать?”