В этой статье мы разберем, что такое серьезность и приоритет дефектов в тестировании, а также посмотрим на примерах, кто и как устанавливает их уровни.
БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
Содержание:
Отслеживание дефектов
Одним из важных аспектов жизненного цикла дефектов является их отслеживание. При тестировании программного обеспечения команды тестировщиков одновременно заводят несколько багов, и, чем сложнее тестируемая система, тем их больше. В таком случае управление этими дефектами и их анализ с целью устранения может оказаться сложной задачей.
В соответствии с процессами жизненного цикла дефектов тестировщик в описании нового бага, помимо шагов воспроизведения обнаруженной проблемы, должен предоставить некоторую категориальную информацию, которая поможет классифицировать дефект. Это, в свою очередь, будет способствовать эффективному отслеживанию/сопровождению, а также созданию основы для ускорения устранения бага.
Основу эффективного отслеживания и устранения дефектов составляют два главных параметра:
- Приоритет дефекта
- Серьезность дефекта
Эти понятия часто путают и используют как взаимозаменяемые не только команды тестирования, но и команды разработки. Вот почему важно понимать, что между ними действительно есть различия.
Давайте вкратце разберемся в теоретических определениях этих двух параметров.
Что такое серьезность и приоритет дефекта?
Приоритет (Priority), согласно определению в словаре, используется при сравнении двух объектов или условий, при этом одному из них придается большая важность, чем другому. Поэтому в контексте тестирования ПО приоритет дефекта указывает на срочность, с которой его необходимо устранить.
Серьезность (Severity) используется для описания тяжести нежелательного явления. Поэтому, когда речь идет о багах, их серьезность указывает на то, какое влияние они оказывают на работу системы.
Кто их определяет?
QA инженер классифицирует дефекты по степени серьезности в зависимости от сложности и критичности дефектов.
Приоритет дефектов определяют все заинтересованные стороны, включая менеджеров проекта, бизнес-аналитиков, владельца продукта.
На рисунке ниже показаны роли, которые определяют приоритет и серьезность дефектов.
Как определить их уровни?
Как мы уже говорили, параметр серьезности оценивается тестировщиком, в то время как параметр приоритета в основном оценивается менеджером продукта. Несмотря на это, серьезность дефекта, безусловно, является одним из факторов влияющих на определение приоритета. Поэтому важно, чтобы тестировщик установил корректный уровень серьезности, чтобы избежать путаницы с командой разработчиков.
Разница между серьезностью и приоритетом
Приоритет связан с планированием, а серьезность — со стандартами.
Существует целый ряд коммерческих программных средств для отслеживания и управления дефектами. Эти средства, при детальном участии инженеров по тестированию ПО, предоставляют команде полную информацию, позволяющую разработчикам понять ошибку, получить представление о ее серьезности, воспроизвести ее и исправить.
Скорость исправлений основывается на приоритетах проекта и серьезности дефекта.
Степень серьезности проблемы определяется в соответствии с оценкой рисков заказчика и фиксируется в выбранном им средстве отслеживания.
Ошибки в программном обеспечении могут “серьезно” повлиять на график, что, в свою очередь, может привести к переоценке и пересмотру “приоритетов”.
Что такое приоритет?
Приоритет определяет важность и срочность устранения дефекта. При заведении бага тестировщик, как правило, назначает определенный уровень приоритета, поскольку рассматривает продукт с точки зрения конечного пользователя.
В общем случае приоритет дефектов можно классифицировать следующим образом:
Приоритет 1. Критический (P1)
Этот дефект должен быть исправлен как можно скорее, в течение 24 часов. Обычно это происходит в тех случаях, когда блокируется вся функциональность и из-за этого невозможно провести тестирование, или если имеются значительные утечки памяти. Иными словами, программа/функция в текущем состоянии является непригодной для использования.
Все дефекты с критической степенью серьезности (S1) относятся к этой категории.
Приоритет 2. Высокий (P2)
Дефект с приоритетом 2 идет следующим в очереди на устранение после критических дефектов. Обычно такой приоритет выставляется, когда функция не может быть использована так, как должна, из-за дефекта программы, или когда необходимо написать новый код, а иногда даже из-за того, что через код необходимо решить какую-либо проблему окружения. Это проблема, без решения которой выпуск нового релиза невозможен.
В категорию P2 попадают все дефекты с уровнем серьезности Major.
Приоритет 3. Средний (P3)
Дефект с таким приоритетом должен быть рассмотрен в качестве кандидата на исправление и касаться проблем с функциональностью, работа которой не соответствует ожиданиям. Иногда даже косметические ошибки, такие как ожидание правильного сообщения об ошибке во время сбоя, могут быть отнесены к дефектам с приоритетом 3.
Все дефекты с серьезностью Minor входят в эту категорию.
Приоритет 4. Низкий (P4)
Дефект с низким приоритетом указывает на то, что проблема определенно существует, но ее не обязательно исправлять в текущем билде. Как правило, сюда можно отнести некоторые опечатки или косметические ошибки.
Иногда баги с низким приоритетом заводятся также для того, чтобы предложить некоторые улучшения в существующем дизайне или попросить реализовать небольшую функцию для улучшения пользовательского опыта.
Как уже говорилось, приоритет определяет, насколько быстро необходимо устранить дефект. Если дефектов несколько, то приоритет определяет, какой дефект должен быть исправлен и проверен немедленно, а какой может быть отложен.
Что такое серьезность?
Серьезность — это параметр, обозначающий влияние дефекта на систему — насколько критичен дефект и каково его влияние на работу всей системы.
Например, рассмотрим следующие сценарии:
- Пользователь пытается совершить покупки в Интернете, а приложение не загружается или появляется сообщение о недоступности сервера.
- Пользователь добавляет товар в корзину, при этом количество добавленных товаров оказывается неверным/добавляется не тот товар.
- Пользователь производит оплату, и после оплаты заказ остается в корзине как зарезервированный, а не подтвержденный.
- Система принимает заказ, но через полчаса отменяет его по каким-либо причинам.
- Система добавляет товар в корзину только при двойном щелчке по кнопке, а не при одинарном.
- Название кнопки вместо русского языка “Добавить в корзину” указано на английском как “Add To Cart”.
Каким будет пользовательский опыт, если произойдет любой из описанных выше сценариев? Подумайте, каким уровням серьезности будет соответствовать каждый их них?
В зависимости от используемой баг-трекинговой системы уровни серьезности могут называться по-разному, но в общем случае их можно классифицировать следующим образом:
1. Критический (S1)
Критическим является дефект, который полностью затрудняет или блокирует тестирование продукта/функции. Примером может служить тестирование пользовательского интерфейса (UI), когда после завершения мастера (wizard), UI зависает на одной панели или не переходит далее для выполнения функции. Или, в некоторых случаях, когда сама разработанная функция отсутствует в сборке.
Если по какой-либо причине происходит сбой в работе приложения или оно становится непригодным для дальнейшего использования, то такой дефект можно отнести к категории критических.
Например, в почтовом сервисе Yahoo или Gmail после ввода правильного имени пользователя и пароля вместо входа в систему происходит сбой или выдается сообщение об ошибке, такой дефект классифицируется как критический, поскольку он делает все приложение непригодным для использования.
Сценарий № 1 из списка, рассмотренного выше, можно отнести к критическим дефектам, поскольку онлайн-приложение становится полностью непригодным для использования.
2. Major (S2)
Любая реализованная крупная функциональность, которая не соответствует требованиям/юзкейсам и ведет себя не так, как ожидалось, может быть отнесена к категории Major.
Major дефект возникает тогда, когда функциональность работает совершенно не так, как ожидалось, или делает не то, что должна делать. В качестве примера можно привести следующий случай: допустим, на коммутаторе необходимо развернуть VLAN, и вы используете шаблон пользовательского интерфейса, который запускает эту функцию. Если этот шаблон для настройки VLAN не срабатывает на коммутаторе, это классифицируется как серьезный недостаток функциональности.
Например, в поставщиках услуг электронной почты, таких как Yahoo или Gmail, не разрешается добавлять более одного получателя, этот дефект классифицируется как серьезный, поскольку согласно ожиданиям, поведение раздела адресатов в почте должно позволять пользователю добавлять несколько получателей электронных писем.
Сценарии № 2 и 3, рассмотренные выше, можно отнести к Major дефектам, поскольку ожидается, что заказ плавно перейдет на следующую фазу жизненного цикла заказа, но в действительности его поведение меняется.
Любой дефект, который может привести к неправильному сохранению данных, проблемам с данными или неправильному поведению приложения, можно в целом отнести к категории Major.
3. Minor (S3)
Любая реализованная функция, которая не соответствует требованиям/юзкейсам и ведет себя не так, как ожидалось, но она не оказывает серьезного влияния на работу приложения, может быть отнесена к категории Minor.
Minor дефект возникает, когда продукт или приложение не соответствует определенным критериям или проявляет неестественное поведение, однако на функциональность в целом это не влияет. Например, в случае с развертыванием шаблона VLAN Minor дефект проявляется в том, что шаблон успешно развертывается на коммутаторе, однако пользователю не отправляется никаких сообщений.
Например, в почтовом сервисе Yahoo или Gmail есть опция “Условия и положения”, и в этой опции есть несколько ссылок, касающихся условий и положений сайта. Если одна из этих ссылок не работает, это называется Minor дефектом, поскольку он влияет только на незначительную функциональность приложения и не оказывает большого влияния на удобство использования приложения.
Сценарий, описанный выше в пункте 5, можно отнести к категории незначительных дефектов, поскольку в этом случае не происходит потери данных или сбоя в порядке работы системы, но возникают небольшие неудобства при работе с приложением.
В целом такие дефекты приводят к минимальной потере функциональности или нарушению пользовательского опыта.
4. Низкий (S4)
Любые косметические дефекты, включая орфографические ошибки, проблемы с выравниванием или начертанием шрифта, могут быть отнесены к категории низкой серьезности.
Ошибка с низкой степенью серьезности возникает в том случае, если она практически не влияет на функциональность, но все же является допустимым дефектом, который должен быть исправлен. В качестве примера можно привести орфографические ошибки в сообщениях об ошибках, выводимых пользователям, или дефекты, улучшающие внешний вид и функциональность.
Например, в провайдерах электронной почты, таких как Yahoo или Gmail, вы могли заметить “Страницу лицензии”, если на ней есть орфографические ошибки или несоответствия, этот дефект классифицируется как низкий.
Сценарий, описанный выше в пункте 6, можно отнести к категории низкого дефекта, поскольку кнопка “Добавить в корзину” отображается на неправильном языке. Такой дефект не окажет влияния ни на поведение системы, ни на представление или потерю данных, ни даже на опыт пользователя, а будет иметь косметический характер.
На рисунке ниже представлена широкая классификация дефектов по степени серьезности и приоритету:
Примеры
Поскольку серьезность дефекта в большей степени относится к функциональности, ее устанавливает инженер-тестировщик. Иногда разработчики также принимают участие в определении степени серьезности дефекта, но в основном это зависит от тестировщика, который оценивает, насколько сильно та или иная функция может повлиять на работу системы.
С другой стороны, когда речь идет об определении приоритета дефекта, хотя первоначально его устанавливает тот, кто завел баг, на самом деле его определяет менеджер по продукту, поскольку он имеет более общее представление о продукте и о том, как быстро необходимо устранить конкретный дефект.
Теперь рассмотрим два примера из реальной жизни, доказывающие, почему приоритет дефекта должен выставлять именно продакт-менеджер, а не тестировщик:
Пример 1. Пользователь обнаруживает ошибку в названии самого продукта или проблему с документацией пользовательского интерфейса. По логике в таком случае тестировщик должен завести дефект с низким приоритетом, но когда речь идет о внешнем виде продукта/пользовательском опыте, это может привести к серьезным последствиям для бизнеса, так как клиенты будут выбирать продукты конкурентов с идеальным интерфейсом.
Пример 2. Могут существовать определенные условия, при которых возникает конкретный дефект, который в среде заказчика может встречаться крайне редко или вообще не встречаться. Даже если с точки зрения функциональности этот дефект может показаться тестировщику высокоприоритетным, учитывая редкость его появления и высокую стоимость устранения, он будет классифицирован как низкоприоритетный.
Сочетания различных уровней приоритета и серьезности
Приоритет и серьезность имеют несколько классификаций, которые помогают определить, как следует обрабатывать дефект. Во многих организациях используются различные баг-трекинговые системы, поэтому уровни могут отличаться.
Давайте рассмотрим возможные сочетания уровне приоритета и серьезности, которые могут одновременно описывать один и тот же дефект:
- Высокий приоритет, высокая серьезность
- Высокий приоритет, низкая серьезность
- Высокая серьезность, низкий приоритет
- Низкая серьезность, низкий приоритет
1. Высокий приоритет и высокая серьезность
В эту категорию автоматически попадает любой критический/major сбой в бизнес-процессе.
Это дефекты, из-за которых тестирование не может быть продолжено. Например, при нажатии на определенную кнопку не загружается сама функция. Или выполнение определенной функции приводит к последовательному падению сервера и потере данных. Красные линии на схеме выше обозначают именно такие дефекты.
Например, система аварийно завершает работу после совершения платежа в онлайн-магазине. Другим примером может служить функция выдачи валюты в банкомате, когда после ввода правильного имени пользователя и пароля автомат не выдает деньги, но при этом списывает их с вашего счета.
2. Высокий приоритет и низкая серьезность
В эту категорию попадают дефекты с низкой серьезностью, которые могут непосредственно повлиять на пользовательский опыт. Они должны быть исправлены, но при этом не влияют на работу приложения с точки зрения функциональности.
Например, логотип компании на главной странице сайта неправильный: представьте, что после очередного обновления приложение будет называться не Chrome, а Krome.
С точки зрения функциональности этот дефект ни на что не влияет, поэтому мы можем оценить его серьезность ка низкую, но он влияет на пользовательский опыт и восприятие бизнеса в целом. Такие дефекты необходимо исправлять с высоким приоритетом, даже если они оказывают очень незначительное влияние на работу приложения.
3. Высокая серьезность и низкий приоритет
В эту категорию попадают любые дефекты, которые функционально не соответствуют требованиям или оказывают функциональное влияние на систему, но отодвигаются заинтересованными сторонами на второй план, когда речь идет о критичности для бизнеса.
Это дефекты, которые должны быть устранены, но не сразу. Это означает, что функциональность затронута в значительной степени, но наблюдается только при использовании некоторых нестандартных входных параметров.
Например, определенная функциональность может быть использована только на более поздней версии прошивки, поэтому для проверки этого – тестировщик фактически понижает версию своей системы, выполняет тест и наблюдает серьезную проблему функциональности. В этом случае дефекты будут отнесены к категории, обозначенной розовыми линиями на схеме выше, так как ожидается, что конечные пользователи будут иметь более высокую версию прошивки.
Например, в социальной сети, выпущена бета-версия новой функции, а активных пользователей, использующих эту функцию, на сегодняшний день не так много. Любой дефект, обнаруженный в этой функции, может быть классифицирован как низкоприоритетный, поскольку эта функция отходит на второй план по классификации бизнеса,.
Это дефект высокой степени серьезности, но его можно отнести к низкоприоритетным, поскольку он может быть исправлен в следующем релизе в виде запроса на изменение. Заинтересованные стороны также относят эту функцию к редко используемым и не влияющим на другие функции, оказывающие непосредственное воздействие на пользовательский опыт.
4. Низкая серьезность и низкий приоритет
Любые орфографические ошибки /коррекция шрифта /несоответствия в абзацах на 3-й или 4-й страницах приложения (а не на главной или титульной странице/в заголовке/названии бренда и т.п.).
Эти дефекты соответствуют зеленым линиям на схеме, они не оказывают влияния на функциональность, но несут небольшое несоответствие стандартам. Как правило, сюда относят косметические ошибки или, скажем, размеры ячейки в таблице на UI.
Например, если в политике конфиденциальности сайта допущена орфографическая ошибка, то этот дефект классифицируется как низкоприоритетный с низкой серьезностью.
Рекомендации
Ниже приведены некоторые рекомендации, которым должен следовать каждый тестировщик:
- Во-первых, нужно хорошо усвоить понятия приоритета и серьезности. Не путайте одно с другим и не используйте их как взаимозаменяемые. В соответствии с этим следуйте рекомендациям по уровню серьезности, опубликованным вашей организацией/командой, чтобы все члены команды оперировали одними и теми же терминами.
- Всегда выбирайте уровень серьезности в зависимости от типа проблемы, поскольку от этого зависит ее приоритет.
- Тестировщику необходимо понимать, как работает та или иная функциональность, а еще глубже – знать, как тот или иной сценарий повлияет на пользовательский опыт. Для этого необходимо постоянно взаимодействовать с командой разработчиков, бизнес-аналитиками, архитекторами, руководителем отдела тестирования, руководителем отдела разработки. В ходе обсуждения необходимо также учитывать, сколько времени потребуется на устранение дефекта с учетом его сложности и времени на его проверку.
- Наконец, владелец продукта всегда обладает правом наложить вето на выпуск релиза, в котором должен быть исправлен дефект. Поэтому тестировщикам и разработчикам нужно уметь аргументировать свою точку зрения, чтобы суметь убедить владельца продукта в важности того или иного действия.
Заключение
При заведении бага тестировщик обязан присвоить ему правильную степень серьезности. Неправильное определение степени серьезности и, соответственно, приоритета может иметь очень серьезные последствия для всего процесса STLC и продукта в целом. На собеседованиях при приеме на работу задается несколько вопросов о приоритете и серьезности, чтобы убедиться, что вы как тестировщик четко понимаете, чем отличаются и что представляют из себя эти понятия.
Надеемся, что эта статья помогла разобраться с понятиями приоритета и серьезности дефектов в тестировании. Поделитесь своими мыслями и вопросами в комментариях ниже.
Перевод статьи «Defect Severity And Priority In Testing With Examples And Difference».