Добавить в корзинуПозвонить
Найти в Дзене
Тестировщик по жизни

Баг в проде – пиши «пропало»?

Ни один QA от этого не застрахован, и рано или поздно это случится с каждым: баг проскользнёт на прод. Это неприятно. Иногда даже очень! Но это не конец карьеры и точно не автоматическое увольнение. Первое, что нужно сделать: Как говорит Николай Картозия (продюсер и ген. директор телеканала «Пятница») в своих интервью: «Стадия о*уевания не является обязательной». Паника только всё усугубляет и толкает на необдуманные слова и действия. Потом будут вспоминать не баг, который вы пропустили, а то, как вы себя повели после этого. «Я же говорил!». «Это не моя зона ответственности!». «Это разработчики накосячили!». Это точно не то, что коллеги должны от вас услышать. Нужно понять: Самым правильным действием в данной ситуации будет максимальная помощь команде: Тогда вы уже тушите пожар вместе с командой и это очень сильно меняет отношение к вам. Уже после того, как пожар потушен, нужно понять: На моём опыте это чаще проблема процесса, а не конкретного человека. Из всей этой неприятной ситуации
Оглавление

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

Это неприятно. Иногда даже очень! Но это не конец карьеры и точно не автоматическое увольнение.

Первое, что нужно сделать:

0. Не паниковать! (по возможности)

Как говорит Николай Картозия (продюсер и ген. директор телеканала «Пятница») в своих интервью: «Стадия о*уевания не является обязательной».

Паника только всё усугубляет и толкает на необдуманные слова и действия.

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

1. Зафиксировать проблему

«Я же говорил!». «Это не моя зона ответственности!». «Это разработчики накосячили!». Это точно не то, что коллеги должны от вас услышать.

Нужно понять:

  • Воспроизводится ли баг стабильно?
  • У кого проявляется (один пользователь, группа, регион, у всех)?
  • Задокументировать баг.

2. Включиться в решение проблемы

Самым правильным действием в данной ситуации будет максимальная помощь команде:

  • проверить гипотезы
  • быстро протестировать фикс
  • предложить временный workaround

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

3. Разобраться, почему баг не нашли

Уже после того, как пожар потушен, нужно понять:

  • Был ли тест-кейс?
  • Были ли сжаты сроки?
  • Это просчёт отдельного сотрудника или слабое место в процессе разработки?

На моём опыте это чаще проблема процесса, а не конкретного человека.

4. Делаем выводы и устраняем проблемы

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

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

Сильный QA не тот, у кого нет багов в проде, а тот, у кого один и тот же тип бага не повторяется дважды.

5. Совет для джунов

Джуны часто думают: «Всё! Меня точно уволят!».

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

Кстати, на собеседованиях могут спросить о пропущенных багах на проде. И там лучше не врать, что у вас всё идеально. Лучше расскажите о своём негативном опыте, но сделайте упор на том, что вы сделали после пожара и как вам это помогло улучшить процессы.

Делитесь своими историями в комментариях!