Управление дефектами в тестировании программного обеспечения

Как и в приведенном выше случае, если сообщение о дефекте делается устно, вскоре все становится очень сложным. Для контроля и эффективного управления ошибками необходим жизненный цикл дефекта.

Что такое процесс управления дефектами?

Управление дефектами – это систематический процесс выявления и устранения ошибок. Цикл управления дефектами содержит следующие этапы:

1. Обнаружение дефекта
2. Категоризация дефекта
3. Устранение дефекта разработчиками
4. Проверка тестерами
5. Закрытие дефекта
6. Отчеты о дефектах в конце проекта

В этой теме вы узнаете, как применить процесс управления дефектами к ИТ проекту. Вы можете выполнить следующие шаги для управления дефектами.

Открытие

На этапе обнаружения проектные группы должны обнаружить как можно больше дефектов , прежде чем конечный клиент сможет их обнаружить. Считается, что дефект обнаружен и изменен на статус принятого, когда он признан и принят разработчиками

В приведенном выше сценарии тестеры обнаружили 84 дефекта в программном продукте.

Давайте рассмотрим такой сценарий.
Ваша группа тестирования обнаружила некоторые проблемы по проекту. Они рассматривают их как дефекты и сообщают команде разработчиков, но есть проблема:

В таком случае, как менеджер тестов, что вы будете делать?

А) Согласиться с командой тестирования, что это дефект
Б) Менеджер теста берет на себя роль судьи, чтобы решить, является ли проблема дефектом или нет
В) договориться с командой разработчиков, что не является дефектом

Для разрешения конфликта, вы (менеджер проекта) берете на себя роль судьи, который решает, является ли проблема продукта дефектом или нет.

Категории ошибок

Классификация дефектов помогает разработчикам программного обеспечения определять приоритеты своих задач и в первую очередь устранить те дефекты, которые больше прочих угрожают работоспособности продукта.

Критический – дефект должен быть устранены немедленно, иначе это может привести к большим потерям для продукта
Например: функция входа на сайт не работает должным образом.
Вход в систему является одной из основных функций банковского сайта, если эта функция не работает, это серьезные ошибки.

Высокий – дефект негативно влияет на основные функции продукта
Например: производительность сайта слишком низкая.

Средний – дефект вносит минимальные отклонения от требований к к продукту
Например: не корректно отображается интерфейс на мобильных устройствах.

Низкий – минимальное не функциональное влияние на продукт
Например: некоторые ссылки не работают.

Решение

После того, как дефекты приняты и классифицированы, вы можете выполнить следующие шаги, чтобы исправить их.

• Назначение: проблемы отправлены разработчику или другому техническому специалисту для исправления и изменило статус на отвечающий.
• График устранения: сторона разработчика берет на себя ответственность на этом этапе, они создадут график для устранения этих дефектов в зависимости от их приоритета.
• Исправление: пока группа разработчиков устраняет дефекты, диспетчер тестов отслеживает процесс устранения проблем, исходя из графика.
• Сообщить о решении: получите отчет об устранении бага от разработчиков, когда дефекты устранены.

Верификация

После того, как команда разработчиков исправила дефект и сообщила об этом, команда тестирования проверяет, действительно ли устранены все заявленные дефекты.

Закрытие

После устранения и проверки дефекта его статус меняется на закрытый. Если он не устранен, вы отправляете уведомление в отдел разработки, чтобы они проверили дефект еще раз.

Составление отчетов

Далее вы должны сообщить правлению текущую ситуацию с дефектами, чтобы получить от них обратную связь. Они должно видеть и понимать процесс управления дефектами, чтобы поддержать вас в случае необходимости.

Как измерить и оценить качество выполнения теста?

Это вопрос, который хочет знать каждый менеджер в тестировании. Есть 2 параметра, которые вы можете рассмотреть следующим образом...

В приведенном выше сценарии можно рассчитать коэффициент отклонения брака (DRR), равный 20/84 = 0,238 (23,8%).

Другой пример: предположительно, в продукте всего 64 дефекта, но ваша группа по тестированию обнаружила только 44 дефекта, т.е. они пропустили 20 дефектов. Следовательно, можно рассчитать коэффициент утечки дефектов (DLR), равный 20/64 = 0,312 (31,2%).

Вывод, качество выполнения теста оценивается по следующим двум параметрам.

Defect reject ratio (DRR) – 23,8%
Defect leakage ratio (DLR) – 31,2%

Чем меньше значение DRR и DLR, тем, соответственно, лучше качество тестирования. Какой диапазон коэффициентов является приемлемым? Этот диапазон может быть определен и принят за основу в проекте исходя из целей, или вы можете ссылаться на показатели аналогичных проектов.

В рассматриваемом нами проекте рекомендуемое значение показателей качества тестирования должно составлять 5 ~ 10%. Это означает, что качество выполнения теста низкое.

Чтобы уменьшить эти коэффициенты:

• Улучшите навыки тестирования участников проекта.
• Тратьте больше времени на выполнение тестов и на просмотр результатов.