АТРИБУТЫ ОТЧЕТА О ДЕФЕКТЕ: ЧАСТЬ 2
⚠️ #Важность/#Критичность (severity)
показывает степень ущерба, который наносится проекту существованием дефекта. Выделяют следующие степени серьезности (критичности) бага:
‼️блокирующая (blocker) – дефект полностью блокирует выполнение функционала, нет никакого способа его обойти. Проблема, нарушающая функционирование ПО, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой становится невозможна
‼️критическая (critical) — дефект приводит к масштабным последствиям катастрофического характера: блокировка части функционала, потеря данных и т.д.
‼️высокая (major, high) — дефект приносит ощутимые неудобства многим пользователям: недоступность вставки из буфера обмена, неработоспособность общепринятых клавиатурных комбинаций, необходимость перезапуска приложения при выполнении типичных сценариев работы и т.д.
❗️средняя (medium) — дефект слабо влияет на типичные сценарии работы пользователей и/или существует обходной путь достижения цели, например: диалоговое окно не закрывается автоматически после нажатия кнопок «OK»/«Cancel», при распечатке нескольких документов подряд не сохраняется значение поля «Двусторонняя печать», перепутаны направления сортировок по некоему полю таблицы.
❗️низкая (minor, low, trivial) — существование дефекта редко обнаруживается незначительным процентом пользователей и почти не влияет на их работу, например: опечатка в глубоко вложенном пункте меню настроек, некое окно сразу при отображении расположено неудобно (нужно перетянуть его в удобное место), неточно отображается время до завершения операции копирования файлов. Иными словами, ошибка не затрагивает бизнес логику ПО.
⚠️ #Приоритет (priority)
отражает приоритет исправления бага, т.е. как быстро дефект должен быть устранён. В общем случае выделяют следующие градации срочности:
‼️ наивысшая (ASAP, as soon as possible, 1)
необходимо устранить дефект настолько быстро, насколько это возможно. В зависимости от контекста «настолько быстро, насколько возможно» может варьироваться от «в ближайшем билде» до единиц минут.
‼️высокая (high, 2)
дефект следует исправить вне очереди, т.к. его существование или уже объективно мешает работе, или начнёт создавать такие помехи в самом ближайшем будущем.
❗️обычная (normal, 3)
дефект следует исправить в порядке общей очерёдности. Такое значение срочности получает большинство дефектов.
❗️низкая (low, 4)
в обозримом будущем исправление данного дефекта не окажет существенного влияния на повышение качества продукта.
⚠️ #Статус бага (state)
отражает, в каком статусе сейчас находится баг. Он зависит от используемой процедуры и жизненного цикла бага. Во многих bug tracking system также есть история бага. в которой можно отследить любые изменения, которые с ним проводились.
⚠️ #Окружение (environment, system info - device, build version)
В данных полях указывается среда, в которой проводилось тестирование - девайсы, аппаратное окружение/номер сборки/стенда.
⚠️ #Комментарий (comments, additional info, discussion)
может содержать любые полезные для понимания и исправления дефекта данные. Иными словами, сюда можно писать всё то, что нельзя писать в остальные поля.
Есть и другие атрибуты, которые находятся в различных баг-трекерах, всё зависит от проекта.
#QAглазамиДжуна_полезное #тестоваядокументация #QAглазамиДжуна_понятия #багрепорт #отчетодефекте
⚠️ #Важность/#Критичность (severity)
показывает степень ущерба, который наносится проекту существованием дефекта. Выделяют следующие степени серьезности (критичности) бага:
‼️блокирующая (blocker) – дефект полностью блокирует выполнение функционала, нет никакого способа его обойти. Проблема, нарушающая функционирование ПО, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой становится невозможна
‼️критическая (critical) — дефект приводит к масштабным последствиям катастрофического характера: блокировка части функционала, потеря данных и т.д.
‼️высокая (major, high) — дефект приносит ощутимые неудобства многим пользователям: недоступность вставки из буфера обмена, неработоспособность общепринятых клавиатурных комбинаций, необходимость перезапуска приложения при выполнении типичных сценариев работы и т.д.
❗️средняя (medium) — дефект слабо влияет на типичные сценарии работы пользователей и/или существует обходной путь достижения цели, например: диалоговое окно не закрывается автоматически после нажатия кнопок «OK»/«Cancel», при распечатке нескольких документов подряд не сохраняется значение поля «Двусторонняя печать», перепутаны направления сортировок по некоему полю таблицы.
❗️низкая (minor, low, trivial) — существование дефекта редко обнаруживается незначительным процентом пользователей и почти не влияет на их работу, например: опечатка в глубоко вложенном пункте меню настроек, некое окно сразу при отображении расположено неудобно (нужно перетянуть его в удобное место), неточно отображается время до завершения операции копирования файлов. Иными словами, ошибка не затрагивает бизнес логику ПО.
⚠️ #Приоритет (priority)
отражает приоритет исправления бага, т.е. как быстро дефект должен быть устранён. В общем случае выделяют следующие градации срочности:
‼️ наивысшая (ASAP, as soon as possible, 1)
необходимо устранить дефект настолько быстро, насколько это возможно. В зависимости от контекста «настолько быстро, насколько возможно» может варьироваться от «в ближайшем билде» до единиц минут.
‼️высокая (high, 2)
дефект следует исправить вне очереди, т.к. его существование или уже объективно мешает работе, или начнёт создавать такие помехи в самом ближайшем будущем.
❗️обычная (normal, 3)
дефект следует исправить в порядке общей очерёдности. Такое значение срочности получает большинство дефектов.
❗️низкая (low, 4)
в обозримом будущем исправление данного дефекта не окажет существенного влияния на повышение качества продукта.
⚠️ #Статус бага (state)
отражает, в каком статусе сейчас находится баг. Он зависит от используемой процедуры и жизненного цикла бага. Во многих bug tracking system также есть история бага. в которой можно отследить любые изменения, которые с ним проводились.
⚠️ #Окружение (environment, system info - device, build version)
В данных полях указывается среда, в которой проводилось тестирование - девайсы, аппаратное окружение/номер сборки/стенда.
⚠️ #Комментарий (comments, additional info, discussion)
может содержать любые полезные для понимания и исправления дефекта данные. Иными словами, сюда можно писать всё то, что нельзя писать в остальные поля.
Есть и другие атрибуты, которые находятся в различных баг-трекерах, всё зависит от проекта.
#QAглазамиДжуна_полезное #тестоваядокументация #QAглазамиДжуна_понятия #багрепорт #отчетодефекте