“Критичный баг на проде!” Это сообщение в рабочем мессенджере, пожалуй, самый страшный сон тестировщика/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 причин появления багов на проде. Думаю, практически у каждого ИТ-шника (и не только тестировщика) есть похожий список на тему “Что виновато и как делать?”  QA Lead, автор и преподаватель курсов, ментор