Что такое severity в тестировании

Тестирование

Раздел: Тестирование > Тестовые Артефакты > Баг Репорт > Серьезность и Приоритет Дефекта

Серьезность и Приоритет Дефекта

Разные системы баг трекинга предлагают нам разные пути описания серьезности и приоритета баг репорта, неизменным остается лишь смысл, вкладываемый в эти поля. Все знают такой баг-трекер, как Atlassian JIRA. В нем, начиная с какой-то версии вместо одновременного использования полей Severity и Priority, оставили только Priority, которое собрало в себе свойства обоих полей: Originally, JIRA did have both a Priority and a Severity field. The Severity field was removed for a number of reasons. Таким образом, те кто привык работать с JIRA не всегда понимают разницу между этими понятиями, так как не имели опыта их совместного использования. Исходя из личного опыта, я настаиваю на разделении этих понятий, а точнее на использовании обоих полей Severity и Priority, так как смысл, вкладываемый в них, различный:

Градация Серьезности дефекта (Severity)

S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.

S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.

S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.

S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.

S5 Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная посредствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Градация Приоритета дефекта (Priority)

P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.

P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.

P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Порядок исправления ошибок по их приоритетам:

Требования к количеству открытых багов

Хотим предложить вам следующий подход к определению требований к количеству открытых багов:

Источник

Отчеты о дефектах. Приоритет и Серьезность.

Для начала рассмотрим каждый атрибут в отдельности.

Серьезность

Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения. Проставляется специалистом по тестированию.

Серьезность имеет несколько параметров в зависимости от типа дефекта. Ее степень зависит от того, как она влияет на бизнес-логику (реализацию правил программы).

Из описания видно, что с помощью Серьезности мы указываем как найденная ошибка влияет на тестируемое приложение. Если из-за ошибки приложение полностью не работает, то Серьезность высокая. Если найденный дефект мало влияет на функционал и больше относится к визуальной части (например, опечатка в слове), то Серьезность низкая.

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

1.Приложение «падает» при попытке найти свободное такси.
Чтобы правильно поставить Серьезность, необходимо определить влияние ошибки на дальнейшую работу функционала. Из названия видно, что после появления ошибки приложение перестает работать. Значит, влияние высокое.

Сразу же отбрасываем Тривиальную и Незначительную Серьезность, так как из их описания понятно, что ошибка не должна сильно влиять на приложение.

У нас остается только три варианта: Значительная, Критическая и Блокирующая серьезности.

Подходит ли нам Значительная Серьезность? Очевидно, что нет. Во-первых, ошибка достаточно критична. Во-вторых, другим способом найти такси мы не можем, т.е. нет возможности работы с тестируемой функцией, используя другие входные точки. Более того, функционал работает не некорректно, а не работает вообще.

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

2. Невозможно указать адрес назначения с помощью “Указать на карте”.
Снова начинаем рассуждать. Тривиальная и Незначительная не подходят, потому что ошибка в какой-то мере нарушают бизнес логику работы приложения. Блокирующую можно не брать, т.к. функционал в целом работает и его можно использовать через другую точку входа, а именно ввести адрес вручную. Остается только два варианта: Критическая и Значительная. Мы уже сказали, что проблема не приводит к полной неработоспособности части функционала. Тем не менее это значительная ошибка, т.к. функционал частично не работает, следовательно остается только вариант Значительная. Его мы и укажем.

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

Приоритет

Приоритет отличается от Серьезности тем, что указывает когда необходимо исправить ошибку.

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

С помощью приоритета менеджер проекта говорит, когда стоит исправить найденную проблему.

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

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

Приоритет определяется исходя из масштабности проблем для пользователей и продукта. Для понимая можно использовать матрицу:

Матрица определения приоритета

Теперь, когда мы разобрались что означает каждый атрибут, давайте посмотрим в чем их различие:

Различия Серьезности и Приоритета

Если остались вопросы по определению параметров Серьезность и Приоритет, то задавайте их в комментариях к статье.

Источник

Фундаментальная теория тестирования

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

Перейдем к основным понятиям

Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.

Для чего проводится тестирование ПО?

Принципы тестирования

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

К задачам контроля качества относятся:

К задачам обеспечения качества относятся:

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

Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.

Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:

Этапы тестирования:

Программный продукт проходит следующие стадии:

Требования

Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

Жизненный цикл бага

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

Градация Приоритета дефекта (Priority):

Тестовые среды

Основные фазы тестирования

Основные виды тестирования ПО

Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.

Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:

Методы тестирования

Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Согласно ISTQB, тестирование белого ящика — это:

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

Согласно ISTQB, тестирование черного ящика — это:

Тестовая документация

Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.

Тест план должен отвечать на следующие вопросы:

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

Источник

Что такое severity в тестировании

Что пишут в блогах

2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA

Привет! В блоге появляется мало новостей, потому что все переехало в telegram.

Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)

Онлайн-тренинги

Что пишут в блогах (EN)

Software Testing

Разделы портала

Про инструменты

Автор: Андрей Петров

У каждого дефекта (несоответствие между реальным и ожидаемым поведением системы) есть атрибуты: «Серьезность» и «Приоритет» с указанием цифрового или буквенного значения. Однако, разница между этими двумя понятиями бывает не до конца ясна. Так, серьезность относится к технической стороне вопроса, а приоритет – к менеджерской. Чтобы внести ясность, предлагаю посмотреть на формальные определения, которые на данный момент приняты в стандартах тестирования и используются повсеместно.

На сегодняшний день, приоритет принято разделять на три уровня, а серьезность – на пять:

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

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

Но зачем нужно это деление, разве нельзя обойтись только одним атрибутом, например, серьезностью? Предположим, в некой системе не работает модуль отчетности. Это –дефект с уровнем серьезности «Блокирующий». Однако этот модуль потребуется только в конце отчетного периода (перед Новым Годом). Если сейчас лето, то данная функциональность не будет использоваться еще несколько месяцев. Как следствие, руководитель проекта или лицо, принимающее решение, может проставить низкий приоритет исправления.

Обратная ситуация: на лицевой странице сайта (или интерфейса приложения) неправильно отображается какая-то важная надпись/логотип (например, название Компании). Данный дефект способен сильно ударить по доверию пользователей к продукции, которую им предлагают: потенциальные клиенты могут подумать, что качество услуг весьма сомнительно, раз даже в названии компании присутствует дефект – и отказаться от использования продукта. С точки зрения подхода к качеству, даже нефункциональные дефекты с уровнем серьезности «Тривиальный» способны отрицательно повлиять на репутацию Компании. Поэтому такому дефекту может быть проставлен высокий приоритет исправления.

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

Источник

Что такое severity в тестировании

Что пишут в блогах

2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA

Привет! В блоге появляется мало новостей, потому что все переехало в telegram.

Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)

Онлайн-тренинги

Что пишут в блогах (EN)

Software Testing

Разделы портала

Про инструменты

Автор: Ольга Алифанова

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

Критическая – системный сбой, потеря данных, проблемы с безопасностью.

Значительная – зависание, блокирование использования, кодирования, тестирования

Умеренная – функциональные проблемы

Низкая – косметические проблемы

Вариант формулировок от Elementool:

Критическая: вызывает отказ всей системы, подсистемы или программы внутри системы.

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

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

Низкая – эстетическая проблема, улучшение, или результат несовпадения со стандартами.

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

Болтон предлагает такую категоризацию серьезности:

Критическая. Баг нанесет такой урон, что на нас подадут в суд, против менеджмента возбудят уголовное дело, мы попадем на первые полосы газет (и не получим от этого никакой радости), и про нас будут говорить в Comedy Club. Компания потратит миллионы на юристов, PR и техподдержку, чтобы не потонуть. Многие уволятся добровольно, даже не присмотрев перед этим новую работу. Многих сократят. Как вариант – баг блокирует тестирование, и мы можем упустить проблемы вышеописанного размаха.

Значительная. Баг повлечет за собой потери, урон, или глубокое разочарование и неудобства для клиентов. Они оборвут телефоны службы поддержки, сведут с ума команду онлайн-саппорта, будут возвращать продукт и требовать деньги назад, и стройными рядами уйдут к конкурентам, громко жалуясь на нас в Твиттере. В газетном разделе «Бизнес» мы будем на первой полосе, и авторы комикса Dilbert используют наш продукт для новых стрипов.

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

Умеренная. Баг вызовет некоторое недовольство клиентов, они утратят веру в наш продукт. Может, они и не будут звонить или писать, но наверняка не купят следующую версию. Вряд ли они пожалуются в Твиттере, но с радостью сделают репост, если пожалуется кто-нибудь другой. Как вариант – с багом столкнется дочь директора, и он придет по душу разработчиков разбираться. Люди не уволятся, но будут демотивированы, и количество отсутствий «по болезни» возрастет. Техподдержка получит допнагрузку, а тестировщики – с самыми лучшими намерениями – потратят время на изучение бага и составление репорта, а более серьезные баги будут упущены (см. выше). Несколько месяцев спустя какой-нибудь менеджер среднего звена недоумевающе спросит «Почему вы этот баг не обнаружили-то?»

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

Тестировщик и блогер TestSheep предлагает другой подход к определению серьезности:

«Меня осенило идеей, что серьезность нужно классифицировать иначе – как «ОМФГ», «Черт. «, «Шта?», и «Фиг с ним».

Серьезность уровня 1: ОМФГ

Все очень плохо. И в бардачке осталась моя страховка.

Серьезность уровня 2: Черт.

Большая часть продукта на месте, но он никуда не едет.

Серьезность уровня 3: Шта?

Нет, этим можно рулить. Но мы ожидали немножко другого.

Серьезность уровня 4: Фиг с ним.

Ну да, раздражает, надо бы починить, но это никак не мешает мне ездить.»

Как определяете серьезность бага вы? Поделитесь на нашем форуме!

Источник