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