Lesson 78

Gaudeamus igitur,
Juvenes dum sumus!

Нелегко таки жилось студентам, гимн грустный...

И даже
Vivat Academia!
Vivant professores!

не спасают от
Nemini parcetur!

Ну а в целом,
Transeas ad inferos, Quivis antiburschius atque irrisores!

Слово Канеру:

Знай процессную стоимость отчета об ошибке.

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

Багрепорты участвуют в процессе. Они требуют времени на написание. Затем программист и/или менеджер проекта читает их. В некоторых компаниях группа Контроля За Изменениями просматривает их, чтоб оценить их. В других компаниях репорты попадают в группу Контроля после того как программист или менеджер решат, что баг не нужно исправлять. Это очень много читателей. Сложите все это время и вы обнаружите, что компания потратила 8 человеко-часов на рассмотрение и отклонение небольшой ошибки. В контексте проекта, если ты флудишь некритичными багрепортами, то ты можешь в одиночку уничтожить производительность команды программистов или менеджеров. Вы можете вызвать удивительный объем негодования и обиды небольшим количеством репортов о незначительных(или неясно описанных) проблемах.

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

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