Мы же всё протестировали, или откуда берутся баги на проде (часть 1)
«Критичный баг на проде!»
Это сообщение в рабочем мессенджере, пожалуй, самый страшный сон тестировщика/QA-специалиста.
Баг на проде (источник — Интернет)
Всем привет! Меня зовут Александра Ерёмина, я QA Lead Engineer и автор блога «Всё о тестировании и QA» (@eremina.proqa).
В тестировании я уже больше 10 лет, попробовала себя в разных ролях на 40+ проектах. И конечно, уже давно понимаю, что поиск багов — это не главная цель тестирования. Найти все баги в приложении/фиче — это вообще цель очень далёкая от реалистичности. Да и не цель вовсе.
Но тем не менее, за последние лет 15 мало что изменилось в ожиданиях от тестировщика на проекте: наша результативность так или иначе продолжает измеряться количеством найденных и зарепортанных багов. Найденных и зарепортанных до релиза, естественно.
В целом спорить не буду: безусловно, критичные дефекты находить нужно и дОлжно.
А вот почему они всё-таки могут просочиться на прод и каков порядок действий тестировщика в таком случае, — это один из важных вопросов в построении не только QA-процессов, но и в целом — ВСЕХ процессов на проекте. И, к слову, один из самых распространенных вопросов в собеседованиях на позицию QA-специалиста.
Вот этот вопрос я и предлагаю рассмотреть и обсудить.
В первую очередь всегда важно помнить, что при обнаружении бага на проде не должно быть места панике и самобичеванию. Зато должно найтись место для т.н. root cause analysis — анализа причин, почему баг, который не был обнаружен при тестировании ДО релиза, появился на проде ПОСЛЕ релиза.
Заранее оговорюсь, что в этой статье будут рассматриваться проекты и команды, где:
Есть отдельно выделенная роль тестировщика/QA-специалиста.
Тестировщик — это не стажёр/джун (или джун, но помимо него, в команде тестирования есть еще тестировщики уровня middle и/или выше).
В команде есть договоренность о том, что тестирование проводится ДО релиза на прод.
Автоматизация тестирования и баги, связанные с ней, в этот обзор включаться не будут.
Итак, в этой статье я рассмотрю ТОП-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. Тестовые данные отличаются от реальных данных с прода.
История из жизни.
И снова крупный заказик. На этот раз в сфере консалтинга. Приложение работает с огромными массивами данных ритейл-компаний.
Изначально, понимая, что данные могут быть весьма специфичными, согласовываем с заказчиком возможность генерации похожих данных. Заказчик соглашается и предоставляет данные, по его словам, похожие на данные с прода (к проду команда доступа не имела).
После каждого релиза с прода приходят баги, которые не воспроизводятся на точно таком же тестовом окружении. В ходе анализа выясняется, что проблема в данных: на проде они реальные и поэтому образуют такие комбинации, существование которых команда просто не может предугадать, не говоря уже об их проверке при разработке и тестировании.
Заказчику были предложены варианты:
Передать для тестирования данные с прода, изменив или удалив информацию о компаниях, датах и прочую информацию, по которой можно было бы «вычислить» компании, людей, счета и т.д.
Дать доступ к проду хотя бы кому-то из команды разработки и/или тестирования (даже с подписанием дополнительного договора о неразглашении).
Включить в команду представителя компании-заказчика, который мог бы проверять тестовые сценарии на предмет добавления дополнительных проверок исходя из возможных особенностей в текущих продовских данных.
В нашем случае все варианты заказчиком были отвергнуты. Но теперь, уже понимая причину появления багов на проде, заказчик согласился с тем, что для него эти баги — допустимые и будут исправляться по мере фидбэка от пользователей.
Мы же, естественно, по мере обнаружения новых багов обновляли и дополняли свои тестовые данные. И приблизительно через полгода количество багов, которые обнаруживали пользователи на проде из-за разницы между сгенерированными и реальными данными, существенно уменьшилось.
В дальнейшем я неоднократно сталкивалась с проблемой отличия реальных пользовательских и тестовых данных: адреса, идентификационные номера, денежные транзакции, страховые анкеты и т.д.
Какие же выводы?
Всегда согласовывайте с продакт-менеджером или другим лицом, отвечающим за развитие продукта:
откуда команда может брать данные как для тестирования, так и для разработки;
насколько имеющиеся данные соответствуют реальным бизнес- и пользовательским данным;
какие специфичные наборы данных могут быть в реальности.
И по мере обнаружения багов, связанных с разницей в данных на тестовом стенде и проде, обновляйте и дополняйте свои тестовые данные, а также добавляйте чек-проверки или тест-кейсы для них.
Конечно же, это не все причины, из-за которых могут появляться баги на проде. Моя коллекция таких причин (не зависящих напрямую от тестировщиков) состоит приблизительно из 20 пунктов.
Так что если эта статья вам будет интересна, то с удовольствием напишу продолжение.
А пока всем небезразличным предлагаю в комментариях поделиться своими ТОП-5 причин появления багов на проде. Думаю, практически у каждого ИТ-шника (и не только тестировщика) есть похожий список на тему «Что виновато и как делать?»
