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

Содержание:

Anonim

Что такое ошибка?

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

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

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

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

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

В этом руководстве вы узнаете:

  • Отчет об ошибке
  • Процесс управления дефектами
    • Открытие
    • Категоризация
    • Разрешение
    • Проверка
    • Закрытие
    • Составление отчетов
  • Важные показатели дефектов

Отчет об ошибке при тестировании программного обеспечения

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

Сообщая об ошибке разработчику, ваш отчет об ошибке должен содержать следующую информацию

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

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

Ресурсы

Скачать образец шаблона отчета о дефектах

В качестве менеджера по тестированию рассмотрите следующее

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

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

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

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

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

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

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

Открытие

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

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

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

Что вы будете делать в таком случае, как тест-менеджер?
A) Согласитесь с командой тестирования, что это дефект
Б) Менеджер по тестированию играет роль судьи, чтобы решить, является ли проблема дефектом или нет.
В) Согласитесь с командой разработчиков, что это не дефект. Исправить Неправильно.

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

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

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

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

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

  • Критический
  • Высоко
  • Середина
  • Низкий
1) Сайт работает слишком медленно

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

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

4) Веб-сайт не может вспомнить сеанс входа в систему.

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

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

Нет. Описание Приоритет Объяснение
1 Сайт работает слишком медленно Высоко Ошибка производительности может причинить пользователю огромные неудобства.
2 Функция входа на сайт не работает должным образом Критический Авторизация - одна из основных функций банковского сайта, если эта функция не работает, это серьезные ошибки.
3 Графический интерфейс веб-сайта некорректно отображается на мобильных устройствах. Середина Дефект влияет на пользователя, который использует смартфон для просмотра веб-сайта.
4 Веб-сайт не может вспомнить сеанс входа пользователя Высоко Это серьезная проблема, поскольку пользователь сможет войти в систему, но не сможет выполнять дальнейшие транзакции.
5 Некоторые ссылки не работают Низкий Это простое решение для разработчиков, и пользователь по-прежнему может получить доступ к сайту без этих ссылок.

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

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

Чтобы исправить дефект, выполните следующие действия.

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

Проверка

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

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

Закрытие

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

Отчет о дефектах

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

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

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

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

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

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

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

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

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

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

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

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