Тестирование ПО

Инструменты управления отчётами о дефектах

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

Многие дополнительные поля и возможности становятся доступными при других операциях с дефектами (просмотром или редактированием созданного дефекта, просмотре отчётов и т.д.)

0 0 vote
Article Rating
Подписаться
Уведомление о
guest
0 Комментарий
Inline Feedbacks
View all comments