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

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

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

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

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

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

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

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