Инструментальных средств управления отчётами о дефектах (bug tracking system, defect management tool) очень много, к тому же, многие компании разрабатывают свои внутренние средства решения этой задачи. Зачастую такие инструментальные средства являются частями инструментальных средств управления тестированием.
Общий набор функций багтрекинговых систем:
- создание отчётов о дефектах, управление их жизненным циклом с учётом контроля версий, прав доступа и разрешённых переходов из состояния в состояние;
- сбор, анализ и предоставление статистики в удобной для восприятия человеком форме;
- рассылка уведомлений, напоминаний и иных артефактов соответствующим сотрудникам;
- организация взаимосвязей между отчётами о дефектах, тест-кейсами, требованиями и анализ таких связей с возможностью формирования рекомендаций;
- подготовка информации для включения в отчёт о результатах тестирования;
- интеграция с системами управления проектами.
Наиболее популярные проекты:
Поля отчёта о дефекте в Jira
- Project (проект) позволяет указать, к какому проекту относится дефект.
- Issue type (тип записи/артефакта) позволяет указать, что именно представляет собой создаваемый артефакт. JIRA позволяет создавать не только отчёты о дефектах, но и множество других артефактов, типы которых можно настраивать.
- Improvement (предложение по улучшению) — предложение на улучшение компонента, функциональности.
- New feature (новая особенность) — описание новой функциональности, нового свойства, новой особенности продукта.
- Task (задание) — некое задание для выполнения тем или иным участником проектной команды.
- Custom issue (произвольный артефакт) — как правило, это значение при настройке JIRA удаляют, заменяя своими вариантами, или переименовывают в Issue.
- Summary (краткое описание) позволяет указать краткое описание дефекта.
- Priority (срочность) позволяет указать срочность исправления дефекта. По умолчанию JIRA предлагает следующие варианты:
- Highest (самая высокая срочность).
- High (высокая срочность).
- Medium (обычная срочность).
- Low (низкая срочность).
- Lowest (самая низкая срочность).
Обратите внимание: по умолчанию поля severity (важность) нет. Но его можно добавить.
- Components (компоненты) содержит перечень компонентов приложения, затронутых дефектом (но иногда здесь перечисляют симптомы дефектов).
- Affected versions (затронутые версии) содержит перечень версий продукта, в которых проявляется дефект.
- Environment (окружение) содержит описание аппаратной и программной конфигурации, в которой проявляется дефект.
- Description (подробное описание) позволяет указать подробное описание дефекта.
- Original estimate (начальная оценка времени исправления) позволяет указать начальную оценку того, сколько времени займёт устранение дефекта.
- Remaining estimate (расчётное остаточное время исправления) показывает, сколько времени осталось от начальной оценки.
- Story points (оценочные единицы) позволяет указать сложность дефекта (или иного артефакта) в специальных оценочных единицах, принятых в гибких методологиях управления проектами.
- Labels (метки) содержит метки (теги, ключевые слова), по которым можно группировать и классифицировать дефекты и иные артефакты.
- Epic/Theme (история/область) содержит перечень высокоуровневых меток, описывающих относящиеся к дефекту крупные области требований, крупные модули приложения, крупные части предметной области, объёмные пользовательские истории и т.д.
- External issue id (идентификатор внешнего артефакта) позволяет связать отчёт о дефекте или иной артефакт с внешним документом.
- Epic link (ссылка на историю/область) содержит ссылку на историю/область, наиболее близко относящуюся к дефекту.
- Has a story/s (истории) содержит ссылки и/или описание пользовательских историй, связанных с дефектом (как правило, здесь приводятся ссылки на внешние документы).
- Tester (тестировщик) содержит имя автора описания дефекта.
- Additional information (дополнительная информация) содержит полезную дополнительную информацию о дефекте.
- Sprint (спринт) содержит номер спринта (2–4-недельной итерации разработки проекта в терминологии гибких методологий управления проектами), во время которого был обнаружен дефект.
Многие дополнительные поля и возможности становятся доступными при других операциях с дефектами (просмотром или редактированием созданного дефекта, просмотре отчётов и т.д.)
