27.02.2018

Баг в проде: кто виноват?

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

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

Но насколько обосновано подобное обвинение? Вот лишь несколько ситуаций, в которых тестировщик может быть объективно оправдан:

• Баг пропущен потому, что этот сценарий/правило не упомянут(о) в спецификации.
• Команда тестировщиков уже занесла отчет о подобном баге, который еще не устранен. Поэтому данный баг оказался в продакшн.
• Баг пропущен потому, что данный функционал не тестировался на более поздних циклах. Этот функционал не включен в область тестирования.
• Баг возник из-за изменений, внесенных разработчиками в последний момент. Менеджеры проекта должны придерживаться стратегии, согласно которой изменения вдогонку выходу в прод запрещены.
• Тестирование проводилось в спешке в силу нехватки времени. Чтобы избежать этого в будущем, менеджерам проекта следует создать эффективный план тестирования.

Больше аргументов в пользу тестировщиков вы сможете узнать на “круглом столе” ТМРА School 2018, который пройдет 4 марта 2018 года в Саратове.

Ресурс: http://softwaretestingtimes.com/2011/12/excuses-for-testers-when-bugs-are.html