Доброго времени суток.
Вопрос тут возник, так как не могу понять как удобнее и правильнее поступать с найденными багами. Являюсь менеджером и в моих силах принять решение о том каков должен быть жизненный цикл баги, но для этого хочу узнать каким он должен быть и какой он в вашем отделе.
Раньше работал в большой фирме (более 200 человек в местном офисе и еще отдел, который находился в другой стране и состоял еще из более 100 человек). Когда мы находили баги, то действовали следующим образом:
1) Убеждались в том, что бага - это бага, а не кривые руки
2) Делали поиск по багобазе и проверяли, что бага еще не запощена
3) Убеждались в том, что багу можно уверенно воспроизвести и она не относится к сложновоспроизводимым
4) Писали саму багу
5) Проходили по шагам, которые сами написали и еще раз убеждались в том, что бага воспроизводилась, если выполнить все действия описанные нами
6) Сабмитили багу
7) Ждали фикса или каких-нибудь комментариев от разработчиков
Данная система была мне понятно, хоть и была через чур бюрократична в виду кучи переписок с разработчиками, которые ассайнили багу друг на друга и выяснения всех обстоятельств начиналось снова.
Нынче работаю в фирме, которая состоит из 5 разработчиков и 3 тестеров, все находимся в одном помещении, поэтому никакой бюрократии в виде переписок по е-майлу или скайпу. Удобно тем, что всегда можно на лету задать вопрос и выяснить какие-то интересующие моменты, но... Стал замечать, что последнее время каждая бага репортится по такому сценарию:
1) Нашли багу
2) Убеждаемся, что бага - это бага (применяем правило 20 минут)
3) Бежим к разработчику, который предположительно писал эту строку кода
4) Выясняем все подробности, обсуждаем багу
5) Репортим её и ждем фикса
Так вот... Правильно ли это, что, после первых двух шагов, тестеры идут обсуждать детали баги к разработчику? Стоит ли как-то изменить систему и поступать так, как это было принято в большой фирме? Или всё-таки стоит пользоваться такой возможностью, что все вопросы можно сразу выяснить напрямую у разработчиков?
Лично я не против сложившейся системы, но в то же время понимаю, что постоянно отвлекать девелоперов не есть хорошо, да и если заглянуть в будущее, то когда фирма расшириться хотя бы еще на 3-4 человека, то уже будет слишком шумно и напряжно постоянно ходить и доставать кодеров. А может пока маленький коллектив, действовать так, как действуем сейчас, а уж когда расширимся, менять "политику партии"?
В общем, нужен совет, а так же с удовольствием послушаю о том каков жизненный цикл баги в вашем коллективе (размер коллектива указывайте тоже).
С уважением и благодарностью,
Андреевич
