Перейти к содержимому

babar.igor

Регистрация: 12 дек 2012
Offline Активность: 26 мар 2016 13:19
-----

Мои темы

Протоколирование причин багов

09 декабря 2015 - 14:28

Добрый день.

 

Как QA Engineer TL, как бы Вы построили процесс протоколирования багов у себя на проекте? Или как построен такой процесс?

 

Предусловия

Есть огромный проект, есть трекер, есть заведенные в него баги. В среднем в месяце кол-во открытых багов составляет около 200 с учетом того что фиксятся старые и находятся новые.

Причины багов разные - процессы, люди, технические проблемы и те, о котрых мы можем не знать.

Цель - сократить количество багов на живом продукте.

Задача номер 1- научиться фиксировать причины багов, по которым они попали на живой продукт, чтобы видеть какие из причин преобладают и устранить или минимизировать  их.

 

Вопросы

1) Кто и на каком этапе должен это делать?

2) Какие дополнительные поля в трекер следует добавить?

3) Что в этих полях указывать?

 

Условие

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

 

Например.

Перед взятием бага на фикс разработчик должен указать (с помощью git) - кто проводил в последний раз изменения по текущей фиче и в рамках какой ветки (или задачи). Для этого вводятся поля: Bug reason (branch), Bug reason (developer). Ответственный за аналитику по багам проводит дальнейшие расследования почему это произошло и т.д.