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

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

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

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

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

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

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, то это явная ошибка кодирования.
  • Ошибка проектирования. Программа соответствует программной документации, но в определенном вопросе тестировщик или пользователь с этой документацией не согласен.
  • Расхождение с документацией. Программа ведет себя не так, как описано в ТЗ, руководстве или интерактивной справке. В этом случае в отчете следует указать, в каком именно документе и на какой странице найдено несоответствие. При этом в отчете вовсе не утверждается, что ошибка именно в документации, а не в самой программе. Отчеты о расхождении с документацией обязательно должны рассматриваться совместно с программистом и автором документации. О функциях программы, которые вообще нигде не описаны, также следует составлять отчеты данного типа.
  • Предложение. Отчет такого типа не означает, что в программе что-то не так. В нем описывается идея, реализация которой, по мнению тестировщика или пользователя, может улучшить программу. Отчеты данного типа должны описывать лишь улучшения или незначительные видоизменения (интерфейс, удобство использования и т.п.) уже существующей функциональности (не путать с отчетами типа Новая функциональность и Задача).
  • Задача. Отчет данного типа подразумевает внесение в уже существующую функциональность каких-то значительных изменений. На каждое такое изменение (или группу изменений) должно быть написано ТЗ, которое необходимо прикреплять к отчету.
  • Новая функциональность. Подразумевает разработку совершенно новой функциональности или даже новых программных модулей, которая ранее не реализовывалась в рамках рассматриваемой программы. К отчету этого типа обязательно должно прикрепляться ТЗ на разрабатываемую функциональность.
  • Вопрос. Программа делает что-то, чего тестировщик или пользователь не ожидает или не понимает. Отчет-вопрос стоит составить при любых сомнениях. Если они окажутся основанными на действительной ошибке, программист ее исправит. При необходимости можно будет составить отчет об ошибке кодирования или проектирования.
  • Информация. Любая дополнительная информация, которую тестировщик или пользователь желает донести до программистов.
Степень важности В этой графе тестировщик или пользователь указывает, насколько, по его мнению, серьезна выявленная проблема. Ниже приводится примерное описание каждой степени важности применительно к ошибкам.
  • Фатальная. Ошибка, которая не позволяет осуществлять дальнейшую работу с программой. К данной категории могут относиться как ошибки, которые «подвешивают» систему, так и ошибки, которые приводят к искажению данных.
  • Критичная. Явное искажение функциональности, приводящее к ошибочному результату как при корректных, так и при некорректных входных данных.
  • Важная. Программа ведет себя корректно и выдает корректные выходные данные при корректных входных действиях или данных. Но некорректные входные данные или последовательность действий приводят к сбою программы или искажению данных.
  • Незначительная. Данная категория ошибок не влияет на функциональность системы, и связана с некоторыми косметическими доработками. Например, удобство использования, округления и т.п.
  • Дизайн. Оформление пользовательского интерфейса, синтаксические и орфографические ошибки, расположение и размер элементов управления и т.п.
Приложения К отчету о найденной ошибке можно приложить файл с тестовыми данными или программу, эмулирующую действия пользователя, при которых проявляется данная ошибка. Можно приложить распечатки (файлы), копии экрана или собственные дополнительные пояснения. Проще говоря, все, что поможет программисту разобраться в ситуации и понять вашу точку зрения, следует передать ему вместе с отчетом и перечислить в графе Приложения, чтобы эти материалы случайно не затерялись.
Проблема В этой графе суть проблемы формулируется очень коротко — в одной-двух строчках. Но при этом описание должно быть и достаточно информативным, чтобы прочитавший его сотрудник смог сразу составить себе четкое представление о проблеме. Именно по нему он будет искать нужный отчет, если захочет возвратиться к нему повторно. Кроме того, следует иметь в виду, что в сводных перечнях ошибок, как правило, будут присутствовать всего несколько полей: Номер отчета, Степень важности, возможно Тип отчета и Проблема.
Можете ли вы воспроизвести проблемную ситуацию Ответом может быть Да, Нет или Не всегда. Если с повторением ситуации возникли сложности, лучше отложить составление отчета до тех пор, пока дело не прояснится: либо вы убедитесь, что не знаете, как ее воспроизвести (и напишите Нет), либо поймете, что она носит нерегулярный характер (и напишите Не всегда). В последнем случае описать способ воспроизведения ситуации нужно особенно тщательно, указав, при каких обстоятельствах ошибка проявляется, а при каких — нет. Следует помнить, что если написать в отчете Да или Не всегда, программист может попросить продемонстрировать описанную ситуацию.
Подробное описание проблемы и как ее воспроизвести* Прежде всего следует подробно написать, в чем состоит проблема, и если это не очевидно, то почему вы считаете, что что-то не в порядке. Необходимо описать все шаги и симптомы, все подробности, включая и сообщение об ошибке. В этом разделе отчета лучше предоставить избыточную информацию, чем написать слишком мало. Если воспроизвести ошибку не удается даже после многих попыток, но при этом вы абсолютно уверены, что видели ее, составьте о ней максимально подробный отчет. Опишите все сообщения об ошибках, расскажите, что пытались делать.
Предлагаемое исправление Эта графа отчета не является обязательной. Если решение проблемы очевидно или, наоборот, у вас нет конкретного предложения, оставьте ее пустой.
Отчет предоставлен сотрудником Здесь необходимо обязательно указать фамилию составителя отчета. Если у программиста возникнут вопросы, он должен знать, к кому обратиться.
Дата В этой графе следует указать дату обнаружения проблемы. Это не дата написания отчета и не дата ввода его в компьютер. В некоторых случаях дата помогает идентифицировать версию программы, к которой он относится.

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