Что пишут в блогах

Подписаться

Что пишут в блогах (EN)

Разделы портала

Онлайн-тренинги

.
TOP 13 ошибок тестировщиков. Часть II. Управление ошибками
29.09.2008 10:36

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

НазваниеОписание

Программа

Необходимо указать систему, в которой обнаружена. Также необходимо указать функциональную область системы, в которой обнаружена проблема, например, в формате <Модуль>.<Функциональная область>. При необходимости данный формат можно детализировать путем добавления нужных элементов, заключенных в <>.

Выпуск и версия

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

Тип отчета

Указывается тип обнаруженной проблемы:

  • Ошибка кодирования. Программа ведет себя не так, как должна по мнению тестировщика или пользователя. Например, если программа утверждает, что 2+2=3, то это явная ошибка кодирования.
  • Ошибка проектирования. Программа соответствует программной документации, но в определенном вопросе тестировщик или пользователь с этой документацией не согласен.
  • Расхождение с документацией. Программа ведет себя не так, как описано в ТЗ, руководстве или интерактивной справке. В этом случае в отчете следует указать, в каком именно документе и на какой странице найдено несоответствие. При этом в отчете вовсе не утверждается, что ошибка именно в документации, а не в самой программе. Отчеты о расхождении с документацией обязательно должны рассматриваться совместно с программистом и автором документации. О функциях программы, которые вообще нигде не описаны, также следует составлять отчеты данного типа.
  • Предложение. Отчет такого типа не означает, что в программе что-то не так. В нем описывается идея, реализация которой, по мнению тестировщика или пользователя, может улучшить программу. Отчеты данного типа должны описывать лишь улучшения или незначительные видоизменения (интерфейс, удобство использования и т.п.) уже существующей функциональности (не путать с отчетами типа Новая функциональность и Задача).
  • Задача. Отчет данного типа подразумевает внесение в уже существующую функциональность каких-то значительных изменений. На каждое такое изменение (или группу изменений) должно быть написано ТЗ, которое необходимо прикреплять к отчету.
  • Новая функциональность. Подразумевает разработку совершенно новой функциональности или даже новых программных модулей, которая ранее не реализовывалась в рамках рассматриваемой программы. К отчету этого типа обязательно должно прикрепляться ТЗ на разрабатываемую функциональность.
  • Вопрос. Программа делает что-то, чего тестировщик или пользователь не ожидает или не понимает. Отчет-вопрос стоит составить при любых сомнениях. Если они окажутся основанными на действительной ошибке, программист ее исправит. При необходимости можно будет составить отчет об ошибке кодирования или проектирования.
  • Информация. Любая дополнительная информация, которую тестировщик или пользователь желает донести до программистов.

Степень важности

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

Ниже приводится примерное описание каждой степени важности применительно к ошибкам.

  • Фатальная. Ошибка, которая не позволяет осуществлять дальнейшую работу с программой. К данной категории могут относиться как ошибки, которые «подвешивают» систему, так и ошибки, которые приводят к искажению данных.
  • Критичная. Явное искажение функциональности, приводящее к ошибочному результату как при корректных, так и при некорректных входных данных.
  • Важная. Программа ведет себя корректно и выдает корректные выходные данные при корректных входных действиях или данных. Но некорректные входные данные или последовательность действий приводят к сбою программы или искажению данных.
  • Незначительная. Данная категория ошибок не влияет на функциональность системы, и связана с некоторыми косметическими доработками. Например, удобство использования, округления и т.п.
  • Дизайн. Оформление пользовательского интерфейса, синтаксические и орфографические ошибки, расположение и размер элементов управления и т.п.

Приложения

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

Проблема

В этой графе суть проблемы формулируется очень коротко — в одной-двух строчках. Но при этом описание должно быть и достаточно информативным, чтобы прочитавший его сотрудник смог сразу составить себе четкое представление о проблеме. Именно по нему он будет искать нужный отчет, если захочет возвратиться к нему повторно. Кроме того, следует иметь в виду, что в сводных перечнях ошибок, как правило, будут присутствовать всего несколько полей: Номер отчета, Степень важности, возможно Тип отчета и Проблема.

Можете ли вы воспроизвести проблемную ситуацию

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

Подробное описание проблемы и как ее воспроизвести*

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

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

Предлагаемое исправление

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

Отчет предоставлен сотрудником

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

Дата

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Количество ошибок

В процессе тестирования производится вычисление количества выявленных ошибок, включая количество разрешенных и оставшихся ошибок.

Качество

Степень серьезности ошибок

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

Качество

Коэффициент обнаружения ошибок

Общее количество найденных дефектов / количество выполненных тестов. Эта метрика используется для анализа и поддержки решения о целесообразности выпуска продукта.

Ход выполнения работ

Плотность дефектов

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

Качество

Сноски

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