Своевременная обработка ошибок

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

Сразу оговорюсь, что в своей деятельности мы используем автоматизированную систему отслеживания ошибок. Поэтому, говоря об изменении статусов (и о других операциях), я имею в виду изменение статуса запроса (и выполнение других операций) в этой автоматизированной системе. Хотя, думаю, что данные положения будут справедливы и в том случае, если учет ошибок ведется любым другим способом.

Рассмотрим простой пример:

На разработчика Р назначено 10 ошибок. Все ошибки имеют статус «Открыта».

Разработчик Р с воодушевлением (естественно, чувствуя свою вину и ответственность:)) берется за исправление этих ошибок. Забыв про обед, он усердно работает и исправляет все ошибки за рекордно короткий срок — 2 часа. Молодец! С чувством выполненного долга он выкладывает исправленные исходники и идет на поздний обед или погружается в любимый форум, искренне ожидая, что его работа будет оценена по заслугам, после тестирования тестировщиком Т.

Но Т полагая, что Р, как всегда, целый день провозится с исправлением ошибок, спокойно занимается другими задачами, не зная о том, что заведенные им ошибки исправлены и можно (а точнее нужно) приступать к их вторичному тестированию. Потом еще другими и еще...

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

Другой пример:

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

Второй день оказывается не менее продуктивным и Т находит еще 30 ошибок, войдя в азарт (все также добросовестно записывая их в свой блокнот).

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

Итог такой: тестировщик потратил целых 3 дня на тестирование функциональности. А что в это время делал разработчик? Надеюсь, что занимался разработкой другой функциональности или рефакторингом существующей (но как правило, в ожидании появления ошибок разработчики занимаются всем, чем угодно, только не кодом:)). А если через 2 дня релиз (а именно столько времени необходимо разработчику на исправление всех ошибок)? Боюсь, что при таком подходе Заказчик и ваше руководство останется недовольно, а вы не получите премию.

А вот если бы тестировщик описывал ошибки в систему управления ошибками по мере их нахождения, то на момент окончания тестирования практически все ошибки были бы уже исправлены. Я уже не говорю о том, что сам процесс тестирования сократился бы за счет оперативного занесения ошибок (не пришлось бы тратить целый день на их перенос).

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

Мораль такова: при работе с ошибками необходимы не только точность, понятность, строгость и т.п., но и СВОЕВРЕМЕННСТЬ и АКТУАЛЬНОСТЬ их заведения и выставление/изменение статусов.

Т.е. если вы обнаружили ошибку и вам удалось ее еще раз воспроизвести — сразу заведите ее (и даже если воспроизвести второй раз не удалось), если вы протестировали исправленную ошибку и она не воспроизвелась — сразу же закройте ее (или переоткройте, ее, если она не исправлена).

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

Для чего нам необходима своевременная обработка ошибок?

1. Для своевременного (без задержек) выполнения работ по исправлению ошибок и тестированию.
2. Для информированности всех участников проекта о текущем состоянии ошибок.
3. Для корректной оценки текущего уровня качества тестируемой функциональности. Для этой цели нам могут служить следующие метрики (которые строятся на базе ошибок):

Сноски

Под запросом понимается запись в системе отслеживания ошибок. К основным типам запросов можно отнести следующие: ошибка, задача, информация, предложение и т.п. Т.е. ошибка в данном контексте представляет собой один из типов запросов в BTS.