Своевременная обработка ошибок
Я уже писал о том, как, когда и каким образом необходимо проставлять отметки о прохождении/сбое тест-кейсов (раздел, посвященный тест-кейсам). Также я описал свое видение того, почему проставление отметок о прохождении/сбое нельзя откладывать до лучших времен. В данном разделе рассмотрим аналогичный аспект, но уже применительно к ошибкам. Т.е. когда, как и (самое главное) для чего необходимо своевременно изменять статусы ошибок.
Сразу оговорюсь, что в своей деятельности мы используем автоматизированную систему отслеживания ошибок. Поэтому, говоря об изменении статусов (и о других операциях), я имею в виду изменение статуса запроса (и выполнение других операций) в этой автоматизированной системе. Хотя, думаю, что данные положения будут справедливы и в том случае, если учет ошибок ведется любым другим способом.
Рассмотрим простой пример:
На разработчика Р назначено 10 ошибок. Все ошибки имеют статус «Открыта».
Разработчик Р с воодушевлением (естественно, чувствуя свою вину и ответственность :)) берется за исправление этих ошибок. Забыв про обед, он усердно работает и исправляет все ошибки за рекордно короткий срок — 2 часа. Молодец! С чувством выполненного долга он выкладывает исправленные исходники и идет на поздний обед или погружается в любимый форум, искренне ожидая, что его работа будет оценена по заслугам, после тестирования тестировщиком Т.
Но Т полагая, что Р, как всегда, целый день провозится с исправлением ошибок, спокойно занимается другими задачами, не зная о том, что заведенные им ошибки исправлены и можно (а точнее нужно) приступать к их вторичному тестированию. Потом еще другими и еще...
В результате работа так и не завершена только из-за того, что разработчик забыл (или забИл, как чаще всего бывает) изменить статус ошибок на «Решена», что должно стать сигналом тестировщику для вторичного тестирования ошибок и функциональности, в которой они найдены.
Другой пример:
Тестировщик Т тестирует программу X. Тестировщик очень любит свою работу и еще больше ему нравится находить ошибки. Он на 100% уверен, что программ без ошибок не бывает! А если он не нашел ошибки, то значит он плохо работал! Такой настрой очень сильно ему помогает и в течение дня он находит 20 ошибок, 7 из которых являются ошибками проектирования и требует очень серьезного пересмотра архитектуры программы. Т очень прилежный тестировщик и, чтобы не забыть, записывает подробное описание всех ошибок в своем личном блокноте, чтобы по окончании тестирования перенести их в систему отслеживания ошибок.
Второй день оказывается не менее продуктивным и Т находит еще 30 ошибок, войдя в азарт (все также добросовестно записывая их в свой блокнот).
Ура! Все тест-кейсы пройдены, все принципиальные (и по возможности остальные) ошибки найдены. И тестировщик начинает все также тщательно и качественно переносить описания ошибок из блокнота в систему отслеживания ошибок. У него уходит на это целый рабочий день.
Итог такой: тестировщик потратил целых 3 дня на тестирование функциональности. А что в это время делал разработчик? Надеюсь, что занимался разработкой другой функциональности или рефакторингом существующей (но как правило, в ожидании появления ошибок разработчики занимаются всем, чем угодно, только не кодом :)). А если через 2 дня релиз (а именно столько времени необходимо разработчику на исправление всех ошибок)? Боюсь, что при таком подходе Заказчик и ваше руководство останется недовольно, а вы не получите премию.
А вот если бы тестировщик описывал ошибки в систему управления ошибками по мере их нахождения, то на момент окончания тестирования практически все ошибки были бы уже исправлены. Я уже не говорю о том, что сам процесс тестирования сократился бы за счет оперативного занесения ошибок (не пришлось бы тратить целый день на их перенос).
Я бы мог привести еще множество различных неудачных примеров, но не буду это делать. Т.к. уверен, что в вашей практике их тоже предостаточно.
Мораль такова: при работе с ошибками необходимы не только точность, понятность, строгость и т.п., но и СВОЕВРЕМЕННСТЬ и АКТУАЛЬНОСТЬ их заведения и выставление/изменение статусов.
Т.е. если вы обнаружили ошибку и вам удалось ее еще раз воспроизвести — сразу заведите ее (и даже если воспроизвести второй раз не удалось), если вы протестировали исправленную ошибку и она не воспроизвелась — сразу же закройте ее (или переоткройте, ее, если она не исправлена).
То же самое касается и разработчиков. Необходимо своевременно назначать ошибки на исполнителей при их заведении, а также переводить в соответствующие статусы при исправлении ошибок (реализации задачи) и выкладке тестовой версии.
Для чего нам необходима своевременная обработка ошибок?
- Для своевременного (без задержек) выполнения работ по исправлению ошибок и тестированию.
- Для информированности всех участников проекта о текущем состоянии ошибок.
- Для корректной оценки текущего уровня качества тестируемой функциональности. Для этой цели нам могут служить следующие метрики (которые строятся на базе ошибок):
| Наименование метрики | Описание | Классификация |
| Количество ошибок | В процессе тестирования производится вычисление количества выявленных ошибок, включая количество разрешенных и оставшихся ошибок. | Качество |
| Степень серьезности ошибок | Количество ошибок, распределенных по уровням приоритета. Эта метрика показывает количество проблем системы, о которых были составлены отчеты, перечисляемые согласно приоритетам. | Качество |
| Коэффициент обнаружения ошибок | Общее количество найденных дефектов / количество выполненных тестов. Эта метрика используется для анализа и поддержки решения о целесообразности выпуска продукта. | Ход выполнения работ |
| Плотность дефектов | Общее количество найденных дефектов / количество тестов на функцию (т.е. на сценарий использования системы или на требование к тестам). Плотность дефектов помогает обнаружить тот факт, что в одной из частей тестируемой функциональности появляется особенно большое число ошибок. | Качество |
Сноски
Под запросом понимается запись в системе отслеживания ошибок. К основным типам запросов можно отнести следующие: ошибка, задача, информация, предложение и т.п. Т.е. ошибка в данном контексте представляет собой один из типов запросов в BTS.