1. Последовательность действий

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

Здесь же необходимо описать любые альтернативные пути, приводящие к возникновению ошибки.

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

2. Наблюдаемое поведение

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

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

Здесь наиболее полезными могут стать скриншоты и видеоролики, на которых представлено проявление ошибки.

3. Ожидаемое поведение

Здесь может быть описание того, как по вашему мнению должна вести себя программа вопреки наблюдаемому поведению. Желательно, чтобы это самое ваше мнение было чем-либо подтверждено. Для этого подтверждения и служит следующий подраздел.

4. Ссылка на требования

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

Вариантами заполнения могут быть:

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

- ссылки на требования или документ, содержащий требования, с указанием раздела и/или номера страницы, на которой эти требования можно найти;

- объяснение в произвольной форме, но обязательно с указанием источника, из которого эти требования исходят. Источником может быть как документ, так и участник команды, отвечающий за постановку/формализацию требований (в т.ч. им может быть и представитель Заказчика);

- не требуется. Данная резолюция указывается тогда, когда ошибка очевидна (например, падение формы), и дополнительных объяснений и указаний не требуется.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Для своевременного (без задержек) выполнения работ по исправлению ошибок и тестированию.

2. Для информированности всех участников проекта о текущем состоянии ошибок.

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

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

Сноски

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