Не помню кто точно, но кто-то из классиков тестирования писал, что основным продуктом, который производят тестировщики, является ошибка.
Действительно, если задуматься, основным результатом работы программиста является программный код (желательно работающий:)), аналитика — формализованные требования и т.д. А что же производят тестировщики? Что является результатом их труда?
Бесспорно, в процессе тестирования тестировщики подготавливают множество различных артефактов: план тестирования, различные спецификации, тест-кейсы, отчеты и т.п. Но все это лишь вспомогательные ступени на пути к качественному продукту (хотя знаю, что на некоторых проектах многие из этих документов в том числе являются основным продуктом деятельности тестировщиков).
Основным результатом нашей с вами деятельности все-таки являются ошибки, а если точнее, то не сами ошибки, а их формальное описание, с которым в дальнейшем будут работать программисты, аналитики, тестировщики и т.д.
В связи с этим, хочу дать несколько рекомендаций относительно того, как лучше оформлять ошибки.
1. Базу ошибок лучше вести в специализированной автоматизированной системе отслеживания ошибок (Bug Tracking System — BTS). Платность или бесплатность данной системы не имеет никого значения. Я знаю, что сейчас существует несколько вполне приличных бесплатных BTS, функциональность которых практически не уступает своим платным аналогам. Если набор функций какой-либо существующей системы вас не устраивает, то можно доработать недостающие функции, либо разработать собственную BTS специальность для своих нужд (хотя я категорически не рекомендую этого делать — не стоит изобретать колесо).
Использование автоматизированной BTS имеет следующие основные преимущества перед ручным хранением и мониторингом ошибок (документы MS Word, MS Excel и т.п.):
- единое хранилище запросов [1];
- возможность совместного доступа и совместной работы с запросами;
- возможность гибкой настройки жизненных циклов запросов;
- возможность гибкой настройки необходимых атрибутов запросов;
- настройка политики безопасности;
- настройка системы оповещения;
- возможность отслеживания текущего состояния запросов;
- построение различных выборок по интересующим запросам;
- возможность импорта/экспорта в другие форматы.
2. В разделе, посвященном правилам написания приемочных тест-кейсов, я уже делал акцент на том, каким образом необходимо писать тест-кейсы, которыми будут пользоваться другие люди. Здесь еще раз повторюсь, но уже применительно к описанию ошибок.
Написание ошибок (в BTS или любым другим способом) направлено прежде всего на то, чтобы эти самые ошибки были исправлены (или хотя бы были приняты, рассмотрены и поняты человеком, отвечающим за исправление этих самых ошибок). Как в случае с исправлением, так и в случае с понимаем ошибки ключевым моментом является то, насколько доступно данная ошибка была описана тестировщиком. Поэтому пишите ошибки таким образом, чтобы они были понятны не только вам, но и любому другому человеку (может быть даже не посвященному в бизнес-логику и/или предметную область).
Поэтому я советую никогда не жалеть времени и не экономить его на создании отчетов об ошибках. Время, которое на ваш взгляд удалось сэкономить на написании запроса, выйдет вам боком при объяснении программисту, что же в нем все-таки имелось в виду и как его можно воспроизвести. А это обязательно произойдет, если вы недостаточно полно и недостаточно понятно опишите ошибку (это в лучшем случае). В худшем случае программист может просто «забить» на ошибку (или отложить до лучших времен, которые, как правило, наступают непосредственно перед релизом:)), разобраться в которой он не может.
Исходя из своего опыта могу сказать, что на оформление более или менее серьезной ошибки у меня может уходить до 10-ти минут. Но это время с лихвой окупается, когда программист один раз прочитав и поняв ошибку, сразу приступает к ее исправлению, не задавая дополнительных вопросов.
Для большей понятности и наглядности ваших запросов очень сильно советую использовать различные программы для получения/редактирования скриншотов, записи видеороликов, воспроизводящих ошибок и т.п. Для этих целей можно использовать такие программы как SnagIt, Camtasia Studio, HyperSnap-DX, Captivate и т.п. После того, как вы сняли скриншот или видеоролик, вы можете просто прикрепить его к описанию ошибки вместо мучительного описания того, как ее можно воспроизвести.
3. И, наконец, в заключении этого раздела хочу представить некоторый формат описания ошибки.
Любая ошибка обязательно должна обладать следующими атрибутами (независимо от того, какую систему отслеживания ошибок вы используете или не используете вообще):
| Название | Описание |
| Программа | Необходимо указать систему, в которой обнаружена. Также необходимо указать функциональную область системы, в которой обнаружена проблема, например, в формате <Модуль>.<Функциональная область>. При необходимости данный формат можно детализировать путем добавления нужных элементов, заключенных в <>. |
| Выпуск и версия | В отчете обязательно должно быть указано, к какой именно версии (релизу) программного кода он относится. |
| Тип отчета | Указывается тип обнаруженной проблемы:
|
| Степень важности | В этой графе тестировщик или пользователь указывает, насколько, по его мнению, серьезна выявленная проблема.
Ниже приводится примерное описание каждой степени важности применительно к ошибкам.
|
| Приложения | К отчету о найденной ошибке можно приложить файл с тестовыми данными или программу, эмулирующую действия пользователя, при которых проявляется данная ошибка. Можно приложить распечатки (файлы), копии экрана или собственные дополнительные пояснения. Проще говоря, все, что поможет программисту разобраться в ситуации и понять вашу точку зрения, следует передать ему вместе с отчетом и перечислить в графе Приложения, чтобы эти материалы случайно не затерялись. |
| Проблема | В этой графе суть проблемы формулируется очень коротко — в одной-двух строчках. Но при этом описание должно быть и достаточно информативным, чтобы прочитавший его сотрудник смог сразу составить себе четкое представление о проблеме. Именно по нему он будет искать нужный отчет, если захочет возвратиться к нему повторно. Кроме того, следует иметь в виду, что в сводных перечнях ошибок, как правило, будут присутствовать всего несколько полей: Номер отчета, Степень важности, возможно Тип отчета и Проблема. |
| Можете ли вы воспроизвести проблемную ситуацию | Ответом может быть Да, Нет или Не всегда. Если с повторением ситуации возникли сложности, лучше отложить составление отчета до тех пор, пока дело не прояснится: либо вы убедитесь, что не знаете, как ее воспроизвести (и напишите Нет), либо поймете, что она носит нерегулярный характер (и напишите Не всегда). В последнем случае описать способ воспроизведения ситуации нужно особенно тщательно, указав, при каких обстоятельствах ошибка проявляется, а при каких — нет. Следует помнить, что если написать в отчете Да или Не всегда, программист может попросить продемонстрировать описанную ситуацию. |
| Подробное описание проблемы и как ее воспроизвести* | Прежде всего следует подробно написать, в чем состоит проблема, и если это не очевидно, то почему вы считаете, что что-то не в порядке. Необходимо описать все шаги и симптомы, все подробности, включая и сообщение об ошибке. В этом разделе отчета лучше предоставить избыточную информацию, чем написать слишком мало. Если воспроизвести ошибку не удается даже после многих попыток, но при этом вы абсолютно уверены, что видели ее, составьте о ней максимально подробный отчет. Опишите все сообщения об ошибках, расскажите, что пытались делать. |
| Предлагаемое исправление | Эта графа отчета не является обязательной. Если решение проблемы очевидно или, наоборот, у вас нет конкретного предложения, оставьте ее пустой. |
| Отчет предоставлен сотрудником | Здесь необходимо обязательно указать фамилию составителя отчета. Если у программиста возникнут вопросы, он должен знать, к кому обратиться. |
| Дата | В этой графе следует указать дату обнаружения проблемы. Это не дата написания отчета и не дата ввода его в компьютер. В некоторых случаях дата помогает идентифицировать версию программы, к которой он относится. |
* Для наибольшей информативности я предлагаю следующую структуризацию раздела с подробным описанием проблемы:
