STLC - Классификация дефектов
Дефекты классифицируются с точки зрения команды QA как Priority и с точки зрения развития как Severity(сложность кода для исправления). Это две основные классификации, которые играют важную роль в определении сроков и объема работы, необходимой для исправления дефектов.
Что такое приоритет?
Приоритет определяется как порядок, в котором должны быть устранены дефекты. Статус приоритета обычно устанавливается командой QA, при этом сообщая о дефекте команде разработчиков, указывая временные рамки для исправления дефекта. Статус «Приоритет» устанавливается исходя из требований конечных пользователей.
Например, если логотип компании неправильно размещен на веб-странице компании, то приоритет высокий, но низкий уровень серьезности.
Приоритетный листинг
Приоритет можно разделить на следующие категории:
Low - Этот дефект можно исправить после устранения критических.
Medium - Дефект необходимо устранить в последующих сборках.
High - Дефект должен быть устранен немедленно, поскольку дефект в значительной степени влияет на приложение, и соответствующие модули нельзя использовать, пока он не будет исправлен.
Urgent - Дефект должен быть устранен немедленно, поскольку дефект серьезно влияет на приложение или продукт, и продукт нельзя использовать, пока он не будет исправлен.
Что такое серьезность?
Серьезность определяется как серьезность дефекта в приложении и сложность кода для его исправления с точки зрения разработки. Itотносится к аспекту разработки продукта. Степень серьезности может быть определена на основе того, насколько серьезен / серьезен дефект для системы. Статус серьезности может дать представление об отклонении в функциональности из-за дефекта.
Example - Для веб-сайта, выполняющего рейсы, дефект при генерации номера билета при бронировании имеет высокую степень серьезности и также имеет высокий приоритет.
Список серьезности
Степень серьезности можно разделить на следующие категории:
Critical /Severity 1- Дефект влияет на наиболее важные функции приложения, и команда QA не может продолжить проверку тестируемого приложения, не исправив его. Например, приложение / продукт часто дает сбой.
Major / Severity 2- Дефект влияет на функциональный модуль; Команда QA не может протестировать этот конкретный модуль, но продолжает проверку других модулей. Например, не работает бронирование авиабилетов.
Medium / Severity 3- Дефект связан с одним экраном или с одной функцией, но система все еще работает. Дефект здесь не блокирует работу. Например, Ticket # - это представление, которое не следует за правильными буквенно-цифровыми символами, такими как первые пять символов и последние пять как числовые.
Low / Severity 4- Не влияет на функциональность. Это может быть косметический дефект, несогласованность пользовательского интерфейса для поля или предложение улучшить взаимодействие с конечным пользователем со стороны пользовательского интерфейса. Например, цвет фона кнопки «Отправить» не совпадает с цветом фона кнопки «Сохранить».