Процесс управления дефектами при тестировании программного обеспечения
Томас Гамильтон
Что такое процесс управления дефектами?
Управление дефектами — это систематический процесс выявления и исправления ошибок. Цикл управления дефектами состоит из следующих этапов: 1) Обнаружение дефекта, 2) Категоризация дефекта, 3) Исправление дефекта разработчиками, 4) Проверка тестировщиками, 5) Закрытие дефекта, 6) Отчеты о дефектах в конце проекта.
В этом разделе вы узнаете, как применить процесс управления дефектами на веб-сайте проекта Guru99 Bank. Вы можете выполнить следующие шаги для управления дефектами.
Шаг 1) Открытие
На этапе открытия проектные группы должны выяснить, как многих дефекты как возможно, прежде чем конечный покупатель сможет это обнаружить. Говорят, что дефект обнаружен и переходит в статус принятый когда это подтверждено и принято разработчиками
В приведенном выше сценарии тестеры обнаружили 84 дефекта на сайте Guru99.
Давайте посмотрим на следующий сценарий; ваша группа тестирования обнаружила некоторые проблемы на сайте Guru99 Bank. Они считают их дефектами и сообщают команде разработчиков, но возникает конфликт —
Что вы будете делать в таком случае как менеджер по тестированию?
Б) Менеджер по тестированию берет на себя роль судьи, решающего, является ли проблема дефектом или нет.
В) Согласиться с командой разработчиков, что это не является дефектом
В таком случае для разрешения конфликта следует применить процесс разрешения. Вы берете на себя роль судьи, который решает, является ли проблема веб-сайта дефектом или нет.
Шаг 2) Категоризация
Категоризация дефектов помогает разработчикам программного обеспечения расставить приоритеты в своих задачах. Это означает, что такой приоритет помогает разработчикам в первую очередь исправлять те дефекты, которые имеют решающее значение.
Дефекты обычно классифицируются менеджером по тестированию:
Давайте выполним небольшое упражнение, как показано ниже.
Перетащите приоритет дефекта ниже| 1) Работа сайта слишком медленная. |
|
| 2) Функция входа на сайт не работает должным образом. |
|
| 3) Графический интерфейс веб-сайта отображается неправильно на Мобильный телефон устройств |
|
| 4) Веб-сайт не смог запомнить сеанс входа пользователя. |
|
| 5) Некоторые ссылки не работают. |
|
Вот рекомендуемые ответы
| Нет. | Описание | приоритет | объяснение |
|---|---|---|---|
|
1 |
Работа сайта слишком медленная |
Высокий |
Ошибка производительности может причинить пользователю огромные неудобства. |
|
2 |
Функция входа на сайт не работает должным образом |
критический |
Вход в систему — одна из основных функций банковского сайта. Если эта функция не работает, это серьезные ошибки. |
|
3 |
Графический интерфейс веб-сайта отображается неправильно на мобильных устройствах. |
Средний |
Дефект затрагивает пользователя, который использует смартфон для просмотра веб-сайта. |
|
4 |
Веб-сайту не удалось запомнить сеанс входа пользователя. |
Высокий |
Это серьезная проблема, поскольку пользователь сможет войти в систему, но не сможет выполнять дальнейшие транзакции. |
|
5 |
Некоторые ссылки не работают |
Низкий |
Это легко исправить для разработчиков, и пользователь все равно сможет получить доступ к сайту без этих ссылок. |
Шаг 3) Разрешение дефектов
Разрешение дефектов Тестирование программного обеспечения — это пошаговый процесс исправления дефектов. Процесс разрешения дефектов начинается с назначения дефектов разработчикам, затем разработчики планируют исправление дефекта в соответствии с приоритетом, затем дефекты исправляются и, наконец, разработчики отправляют отчет о разрешении менеджеру по тестированию. Этот процесс помогает легко исправлять и отслеживать дефекты.
Чтобы исправить дефект, вы можете выполнить следующие шаги.
- Назначение: поручено разработчику или другому техническому специалисту для исправления и изменен статус на Реагирование.
- Исправление расписания: Ответственность на этом этапе берет на себя разработчик. Они составят график устранения этих дефектов в зависимости от приоритета дефекта.
- Исправить дефект: Пока команда разработчиков исправляет дефекты, Менеджер по тестированию отслеживает процесс исправления дефектов в соответствии с приведенным выше графиком.
- Сообщить о решении: Получите отчет о разрешении от разработчиков при устранении дефектов.
Шаг 4) Проверка
После того, как команда разработчиков фиксированной и сообщило дефект, группа тестирования проверяет что дефекты действительно устранены.
Например, в приведенном выше сценарии, когда команда разработчиков сообщила, что они уже исправили 61 дефект, ваша команда проведет повторное тестирование, чтобы убедиться, что эти дефекты действительно исправлены или нет.
Шаг 5) Закрытие
После устранения и проверки дефекта статус дефекта меняется на закрыто. Если нет, вы отправите уведомление разработчикам, чтобы они еще раз проверили дефект.
Шаг 6) Отчет о дефектах
Отчет о дефектах В тестировании программного обеспечения — это процесс, в котором менеджеры по тестированию готовят и отправляют отчет о дефектах команде управления для получения обратной связи о процессе управления дефектами и статусе дефектов. Затем команда управления проверяет отчет о дефектах и отправляет отзыв или при необходимости предоставляет дополнительную поддержку. Отчеты о дефектах помогают лучше общаться, отслеживать и подробно объяснять дефекты.
Правление имеет право знать статус неисправности. Они должны понимать процесс управления дефектами, чтобы поддержать вас в этом проекте. Поэтому вы должны сообщить им о текущей ситуации с дефектами, чтобы получить от них обратную связь.
Зачем вам нужен процесс управления дефектами?
Ваша команда обнаружила ошибки при тестировании проекта Guru99 Banking.
Через неделю разработчик отвечает –
На следующей неделе тестер ответит
Как и в приведенном выше случае, если сообщение о дефекте осуществляется устно, вскоре все становится очень сложным. Для контроля и эффективного управления ошибками вам необходим жизненный цикл дефекта.
Важные показатели дефектов
Вернитесь к приведенному выше сценарию. Команды разработчиков и тестировщиков проверяют выявленные дефекты. Вот результат этого обсуждения
Как измерить и оценить качество выполнения теста?
Это вопрос, который каждый Test Manager хочет знать. Есть 2 параметра, которые вы можете рассматривать как следующие:
В приведенном выше сценарии вы можете рассчитать коэффициент отклонения дезертирства (СРБ) – это 20/84 = 0.238 (23.8 %).
Другой пример, предположим, что на сайте банка Guru99 имеется всего 64 дефекты, но ваша команда тестирования обнаруживает только 44 дефекты, т.е. они пропущены 20 дефекты. Следовательно, можно рассчитать коэффициент утечки дефектов (DLR) равный 20/64 = 0.312 (31.2%).
Вывод: качество выполнения теста оценивается по двум параметрам.
Чем меньше значение DRR и DLR, тем выше качество выполнения теста. Каков диапазон соотношений, который приемлемый? Этот диапазон может быть определен и принят в качестве основы для цели проекта или вы можете использовать показатели аналогичных проектов.
В этом проекте рекомендуемое значение приемлемого соотношения составляет 5 ~ 10%. Это означает, что качество выполнения тестов низкое. Вам следует найти контрмеры для уменьшения этих соотношений, например:
- Совершенствовать навыки тестирования участника.
- Проводи больше времени для выполнения тестирования, особенно для просмотра результатов выполнения теста.
Часто задаваемые вопросы
Нажмите здесь если видео недоступно
Ресурсы:
Загрузите образец шаблона отчета о дефектах
