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

Подписаться

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

Конференции

Что пишут в блогах (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. И, наконец, в заключении этого раздела хочу предст