Home

Автор: Артём Ваулин

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

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

Такой вот каламбур получается — ошибки про ошибки :)

С первой частью материала можно познакомиться здесь.

Управление ошибками

6. Написание запросов в системе отслеживания ошибок

Не помню кто точно, но кто-то из классиков тестирования писал, что основным продуктом, который производят тестировщики, является ошибка.

Действительно, если задуматься, основным результатом работы программиста является программный код (желательно работающий :)), аналитика — формализованные требования и т.д. А что же производят тестировщики? Что является результатом их труда?

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

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

В связи с этим, хочу дать несколько рекомендаций относительно того, как лучше оформлять ошибки.

1. Базу ошибок лучше вести в специализированной автоматизированной системе отслеживания ошибок (Bug Tracking System — BTS). Платность или бесплатность данной системы не имеет никого значения. Я знаю, что сейчас существует несколько вполне приличных бесплатных BTS, функциональность которых практически не уступает своим платным аналогам. Если набор функций какой-либо существующей системы вас не устраивает, то можно доработать недостающие функции, либо разработать собственную BTS специальность для своих нужд (хотя я категорически не рекомендую этого делать — не стоит изобретать колесо).

Использование автоматизированной BTS имеет следующие основные преимущества перед ручным хранением и мониторингом ошибок (документы MS Word, MS Excel и т.п.):

- единое хранилище запросов [1];

- возможность совместного доступа и совместной работы с запросами;

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

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

- настройка политики безопасности;

- настройка системы оповещения;

- возможность отслеживания текущего состояния запросов;

- построение различных выборок по интересующим запросам;

- возможность импорта/экспорта в другие форматы.

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

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

Поэтому я советую никогда не жалеть времени и не экономить его на создании отчетов об ошибках. Время, которое на ваш взгляд удалось сэкономить на написании запроса, выйдет вам боком при объяснении программисту, что же в нем все-таки имелось в виду и как его можно воспроизвести. А это обязательно произойдет, если вы недостаточно полно и недостаточно понятно опишите ошибку (это в лучшем случае). В худшем случае программист может просто «забить» на ошибку (или отложить до лучших времен, которые, как правило, наступают непосредственно перед релизом :)), разобраться в которой он не может.

Исходя из своего опыта могу сказать, что на оформление более или менее серьезной ошибки у меня может уходить до 10-ти минут. Но это время с лихвой окупается, когда программист один раз прочитав и поняв ошибку, сразу приступает к ее исправлению, не задавая дополнительных вопросов.

Для большей понятности и наглядности ваших запросов очень сильно советую использовать различные программы для получения/редактирования скриншотов, записи видеороликов, воспроизводящих ошибок и т.п. Для этих целей можно использовать такие программы как SnagIt, Camtasia Studio, HyperSnap-DX, Captivate и т.п. После того, как вы сняли скриншот или видеоролик, вы можете просто прикрепить его к описанию ошибки вместо мучительного описания того, как ее можно воспроизвести.

3. И, наконец, в заключении этого раздела хочу представить некоторый формат описания ошибки.

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

* Для наибольшей информативности я предлагаю следующую структуризацию раздела с подробным описанием проблемы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сноски

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