Что такое ошибка?
Ошибка - это следствие / результат ошибки кодирования.
Дефект в тестировании программного обеспечения
Дефект тестирования программного обеспечения является изменение или отклонение приложения от требований конечного пользователя или оригинальных бизнес - требований. Дефект программного обеспечения - это ошибка в кодировании, которая приводит к неверным или неожиданным результатам работы программы, которая не соответствует фактическим требованиям. С такими дефектами тестировщики могут столкнуться при выполнении тестовых примеров.
Эти два термина имеют очень тонкую грань различий. В отрасли оба являются неисправностями, которые необходимо исправить, и поэтому они взаимозаменяемы между собой некоторыми группами тестирования.
Когда тестировщики выполняют тестовые примеры, они могут столкнуться с такими результатами тестирования, которые противоречат ожидаемым результатам. Такое изменение результатов тестирования называется программным дефектом. В разных организациях эти дефекты или вариации называются разными именами, такими как проблемы, проблемы, ошибки или инциденты.
В этом руководстве вы узнаете:
- Отчет об ошибке
- Процесс управления дефектами
- Открытие
- Категоризация
- Разрешение
- Проверка
- Закрытие
- Составление отчетов
- Важные показатели дефектов
Отчет об ошибке при тестировании программного обеспечения
Сообщение об ошибке в тестировании программного обеспечения представляет собой подробный документ об ошибках , обнаруженных в программном приложении. Отчет об ошибке содержит каждую деталь об ошибке, такую как описание, дата, когда ошибка была обнаружена, имя тестировщика, который ее нашел, имя разработчика, который ее исправил, и т. Д. Отчет об ошибке помогает выявлять похожие ошибки в будущем, чтобы их можно было избежать.
Сообщая об ошибке разработчику, ваш отчет об ошибке должен содержать следующую информацию
- 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%. Значит, качество выполнения теста низкое. Вы должны найти контрмеры для уменьшения этих соотношений, например:
- Улучшите тестовые навыки участника.
- Уделите больше времени выполнению тестирования, особенно просмотру результатов выполнения теста.