Инструменты управления отчётами о дефектах
Инструментальных средств управления отчётами о дефектах (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-недельной итерации разработки проекта в терминологии гибких методологий управления проектами), во время которого был обнаружен дефект.
Многие дополнительные поля и возможности становятся доступными при других операциях с дефектами (просмотром или редактированием созданного дефекта, просмотре отчётов и т.д.)