Bug prod что это

Home

Мало что сравнится по степени кошмарности для тестировщика с осознанием того, что на проде найден баг. В этой статьей я приведу набор шагов, помогающих тестировщику разобраться с багами на проде и предотвратить их появление в будущем.

Шаг 1: сохраняйте спокойствие.

Так как именно мы – те самые люди, которые тестировали продукт и передавали его в релиз, легко удариться в панику при обнаружении бага на проде. Мы тут же спрашиваем себя «Как же это могло произойти?», и можем начать агонизировать в поиске ответов. Однако это непродуктивно – нашей приоритетной задачей должно быть убеждение, что баг исправлен. Если мы не сохраним спокойствие, то можем недоисследовать проблему или недотестировать исправление.

Шаг 2: воспроизведите проблему.

Если о проблеме сообщил заказчик или другой человек внутри компании, то первое, что нужно сделать – это посмотреть, можете ли вы ее воспроизвести. Возможно, это просто пользовательская ошибка или проблема конфигурации. Однако не делайте поспешных выводов! Удостоверьтесь, что вы тщательно прошли по всем описанным пользователем шагам, и при возможности убедитесь, что пользуетесь тем же ПО и железом, что и он. К примеру, используйте тот же тип мобильного устройства и тот же билд, или же ту же ОС и тот же браузер. Если воспроизвести проблему не удается, запросите дополнительную информацию и продолжайте пробовать. Посмотрите статью «как воспроизвести баг», если вам нужны подсказки.

Шаг 3: узнайте как можно больше.

Теперь, когда проблема воспроизведена, соберите максимум информации о ней. Воспроизводится ли она на тест-стенде? Проявляется ли в предыдущем билде? Если это так, на каком билде она не проявляется? Проявляется ли она на какой-то определенной ОС/в определенном браузере? Необходимы ли для ее воспроизведения определенные настройки конфигурации? Чем больше информации вы соберете, тем быстрее разработчики смогут исправить баг.

Шаг 4: выявите первопричину.

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

Шаг 5: решите, когда исправлять проблему

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

Решая, когда исправлять баг, подумайте вот о чем:

Сколько пользователей им затронуто?
Насколько он серьезен?

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

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

Шаг 6: протестируйте исправление.

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

Шаг 7: проанализируйте, что пошло не так.

Крайне заманчиво вздохнуть с облегчением и перейти к чему-то другому, когда баг прода исправлен. Однако тут очень важно найти время на то, чтобы понять, как именно он попал на прод. Это не относится к поиску виноватых и козлов отпущения – все совершают ошибки, неважно, разработчики ли, тестировщики, продакт-оунеры, менеджеры или релизные инженеры. Суть в том, чтобы понять, что произошло, чтобы не допустить такой проблемы впредь.

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

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

Шаг 8: проведите мозговой штурм для выявления способов предотвращения схожих проблем.

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

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

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

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