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

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

Управление дефектами — это систематический процесс выявления и исправления ошибок. Цикл управления дефектами включает в себя следующее:wing этапы 1) Обнаружение дефекта, 2) Категоризация дефекта 3) Исправление дефекта разработчиками 4) Проверка тестировщиками, 5) Закрытие дефекта 6) Отчеты о дефектах в конце проекта

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

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

Шаг 1) Открытие

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

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

Открытие

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

Что вы будете делать в таком случае как менеджер по тестированию?

А) Согласитесь с командой тестирования, что это дефект.

Б) Менеджер по тестированию берет на себя роль судьи, решающего, является ли проблема дефектом или нет.

В) Согласиться с командой разработчиков, что это не является дефектом

Верный
Неверно

В таком случае для разрешения конфликта следует применить процесс разрешения. Вы берете на себя роль судьи, который решает, является ли проблема веб-сайта дефектом или нет.

Шаг 2) Категоризация

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

Категоризация

Дефекты обычно классифицируются менеджером по тестированию:

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

Перетащите приоритет дефекта ниже
1) Работа сайта слишком медленная.
2) Функция входа на сайт не работает должным образом.
3) Графический интерфейс веб-сайта отображается неправильно на Мобильный телефон устройств
4) Веб-сайт не смог запомнить сеанс входа пользователя.
5) Некоторые ссылки не работают.

Вот рекомендуемые ответы

Нет. Описание приоритет объяснение

1

Работа сайта слишком медленная

Высокий

Ошибка производительности может причинить пользователю огромные неудобства.

2

Функция входа на сайт не работает должным образом

критический

Вход в систему — одна из основных функций банковского сайта. Если эта функция не работает, это серьезные ошибки.

3

Графический интерфейс веб-сайта отображается неправильно на мобильных устройствах.

Средний

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

4

Веб-сайту не удалось запомнить сеанс входа пользователя.

Высокий

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

5

Некоторые ссылки не работают

Низкий

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

Шаг 3) Разрешение дефектов

Разрешение дефектов Тестирование программного обеспечения — это пошаговый процесс исправления дефектов. Процесс разрешения дефектов начинается с назначения дефектов разработчикам, затем разработчики планируют исправление дефекта в соответствии с приоритетом, затем дефекты исправляются и, наконец, разработчики отправляют отчет о разрешении менеджеру по тестированию. Этот процесс помогает легко исправлять и отслеживать дефекты.

Вы можете следить за следующимwing действия по устранению неисправности.

Разрешение дефектов

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

Шаг 4) Проверка

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

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

Шаг 5) Закрытие

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

Шаг 6) Отчет о дефектах

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

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

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

Ваша команда обнаружила ошибки при тестировании проекта Guru99 Banking.

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

Через неделю разработчик отвечает –

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

На следующей неделе тестер ответит

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

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

Важные показатели дефектов

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

Важные показатели дефектов

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

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

Важные показатели дефектов

В приведенном выше сценарии вы можете рассчитать коэффициент отклонения дезертирства (СРБ) – это 20/84 = 0.238 (23.8 %).

Другой пример, предположим, что на сайте банка Guru99 имеется всего 64 дефекты, но ваша команда тестирования обнаруживает только 44 дефекты, т.е. они пропущены 20 дефекты. Следовательно, можно рассчитать коэффициент утечки дефектов (DLR) равный 20/64 = 0.312 (31.2%).

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

Важные показатели дефектов

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

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

  • Совершенствовать навыки тестирования участника.
  • Проводи больше времени для тестирования выполнения, особенно для проверкиwing результаты выполнения теста.

Часто задаваемые вопросы

Ошибка — это последствие/результат ошибки кодирования.

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

Эти два термина имеют очень тонкую грань различия. В отрасли оба являются недостатками, которые необходимо исправить, и поэтому некоторые из них используют их как взаимозаменяемые. Тестирование команды.

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

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

  • ID_дефекта – Уникальный идентификационный номер дефекта.
  • Описание дефекта – Подробное описание Дефекта, включая информацию о модуле, в котором был обнаружен Дефект.
  • Версия – Версия приложения, в которой обнаружен дефект.
  • Шаги - Подробные действия и скриншоты, с помощью которых разработчик может воспроизвести дефекты.
  • Дата поднятия – Дата выявления дефекта
  • Ссылка- где вы предоставляете ссылку на такие документы, как . требования, дизайн, archiтектура или, может быть, даже скриншоты ошибки, чтобы помочь понять дефект
  • Обнаружено – Имя/идентификатор тестировщика, выявившего дефект
  • Положение дел - Статус дефекта, подробнее об этом later
  • Исправлено – Имя/идентификатор разработчика, исправившего проблему
  • Дата закрытия – Дата закрытия дефекта
  • Строгость который описывает влияние дефекта на приложение
  • приоритет что связано со срочностью устранения дефектов. Приоритет серьезности может быть высоким/средним/низким в зависимости от срочности воздействия, при которой дефект должен быть исправлен соответственно.

Нажмите здесь если видео недоступно

Ресурсы:

Загрузите образец шаблона отчета о дефектах