defect severity priority testing with examples
У цьому підручнику ви дізнаєтеся, що таке серйозність та пріоритет дефектів у тестуванні, як встановити пріоритет дефектів та рівні тяжкості на прикладах, щоб чітко зрозуміти концепцію.
Ми також детально розглянемо, як класифікувати дефекти за різними сегментами та їх актуальність у життєвому циклі дефектів. Ми також висвітлимо вирішальну роль класифікації на живому наборі прикладів.
Дефекти подачі є дуже невід'ємною частиною частина життєвого циклу тестування програмного забезпечення . Існує кілька найкращих практик для ефективне звітування про дефекти через Інтернет або в організаціях.
Що ви дізнаєтесь:
- Огляд відстеження дефектів
Огляд відстеження дефектів
Один із важливих аспектів життєвого циклу дефектів на загальному рівні включає відстеження дефектів. Це важливо, оскільки тестові групи відкривають кілька дефектів під час тестування програмного забезпечення, яке примножується лише у тому випадку, якщо конкретна перевіряемая система є складною. У такому випадку управління цими дефектами та аналіз цих дефектів для закриття диска може бути непростим завданням.
Відповідно до процесів обслуговування дефектів, коли будь-який тестер подає дефект, окрім методу / опису, щоб відтворити побачену проблему, він також повинен надати деяку категоричну інформацію, яка могла б допомогти неточній класифікації дефекту. Це, в свою чергу, допомогло б в ефективному процесі відстеження / обслуговування дефектів, а також створило б основу для швидшого часу обробки дефектів.
Двома основними параметрами, що складають основу для ефективного відстеження та усунення дефектів, є:
- Пріоритет дефекту при тестуванні
- Серйозність дефектів при тестуванні
Це часто заплутане поняття і майже взаємозамінно використовується не лише тестовими групами, але й командами розробників. Між ними є тонка межа, і важливо розуміти, що між ними насправді існують відмінності.
Давайте коротко розберемося з теоретичними визначеннями цих двох параметрів у наступному розділі.
Що таке серйозність та пріоритет дефектів?
Пріоритет за визначенням англійської мови використовується для порівняння двох речей або умов, коли одній слід надати більше значення, ніж іншій, і перед нею слід вирішити / вирішити, перш ніж переходити до наступної. Тому в контексті дефектів пріоритет дефекту вказуватиме на терміновість, з якою його потрібно буде виправити.
Серйозність за англійським визначенням використовується для опису тяжкості небажаного явища. Отже, коли справа стосується помилок, тяжкість помилки вказувала б на вплив, який вона робить на систему з точки зору її впливу.
Хто їх визначає?
QA класифікує дефект відповідно до тяжкості на основі складності та критичності дефектів.
Будь-які зацікавлені сторони в бізнесі, включаючи менеджерів проектів, бізнес-аналітиків, власників продуктів, визначають пріоритет дефектів.
На малюнку нижче зображена роль, яка володіє та класифікує критичність та тяжкість дефектів.
Як вибрати ці рівні?
Як ми вже обговорювали, параметр серйозності оцінюється тестувальником, тоді як параметр пріоритету в основному оцінюється менеджером продукту або, в основному, командою збору. Навіть незважаючи на це, тяжкість дефекту, безумовно, є одним із чинників, що керують та впливають на визначення пріоритету дефекту. Тому в якості тестувальника важливо правильно вибрати важкість, щоб уникнути плутанини з командами розробників.
Різниця між важкістю та пріоритетом
Пріоритет асоціюється з плануванням, а 'суворість' - зі стандартами.
«Пріоритет» означає, що щось надається або заслуговує на попередню увагу; пріоритет, встановлений в порядку важливості (або терміновості).
«Серйозність» - це стан або якість суворості; суворий передбачає дотримання суворих стандартів або високих принципів і часто припускає жорсткість; тяжкий стан відзначається або вимагає суворого дотримання суворих стандартів або високих принципів, Наприклад, суворий кодекс поведінки.
Слова відстеження помилок пріоритет і важкість дійсно трапляються.
Доступні різноманітні комерційні програмні засоби для відстеження / управління проблемами. Ці інструменти, завдяки детальному введенню інженерів тестування програмного забезпечення, дають команді повну інформацію, щоб розробники могли зрозуміти помилку, отримати уявлення про її „важкість”, відтворити та виправити.
Виправлення базуються на проекті «Пріоритети» та «Серйозність» помилок.
«Серйозність» проблеми визначається відповідно до оцінки ризику замовника та реєструється у вибраному ними засобі відстеження.
Програмне забезпечення баггі може «серйозно» впливати на графіки, що, в свою чергу, може призвести до переоцінки та перегляду «пріоритетів».
Що таке пріоритет?
Як випливає з назви, пріоритет полягає у визначенні пріоритетів дефекту на основі бізнес-потреб та тяжкості дефекту. Пріоритет означає важливість або терміновість виправлення дефекту.
Відкриваючи дефект, тестувальник, як правило, призначає пріоритет спочатку, коли він розглядає продукт з точки зору кінцевого користувача. Відповідно до них існують різні рівні:
Загалом, пріоритетність дефектів можна класифікувати наступним чином:
Пріоритет No1) Негайний / Критичний (P1)
Це має бути виправлено негайно протягом 24 годин. Як правило, це відбувається у випадках, коли вся функціональність заблокована, і в результаті цього не може тривати тестування. Або в деяких інших випадках, якщо є значні витоки пам'яті, тоді загалом дефект класифікується як пріоритетний -1, що означає, що програма / функція непридатна для використання в поточному стані.
Будь-який дефект, який потребує негайної уваги, що впливає на процес випробування, буде класифікований під безпосередньою категорією
Всі Критична важкість дефекти підпадають під цю категорію (якщо компанія / зацікавлені сторони не визначили пріоритет)
Пріоритет No2) Високий (P2)
Як тільки критичні дефекти будуть виправлені, дефект, що має цей пріоритет, є наступним кандидатом, який повинен бути виправлений для будь-якої тестової діяльності, щоб відповідати критеріям 'виходу'. Зазвичай, коли функція непридатна для використання, як передбачається, через дефект програми, або що новий код повинен бути написаний, або іноді навіть тому, що через код потрібно вирішити якусь екологічну проблему, дефект може претендувати на пріоритет 2 .
Це дефект або проблема, яку слід вирішити до випуску. Ці дефекти повинні бути усунені після вирішення критичних питань.
Всі Майор тяжкість дефекти належать до цієї категорії.
Пріоритет No3) Середній (P3)
Дефект із цим пріоритетом повинен бути суперечливим для усунення, оскільки він також може вирішувати проблеми з функціональністю, які не відповідають очікуванням. Іноді навіть косметичні помилки, такі як очікування правильного повідомлення про помилку під час несправності, можуть кваліфікуватися як пріоритетний дефект 3.
Цей дефект слід усунути після виправлення всіх серйозних помилок.
Як тільки критичні помилки та помилки з високим пріоритетом будуть зроблені, ми можемо перейти до помилок із середнім пріоритетом.
Всі Неповнолітні тяжкість дефекти належать до цієї категорії.
Пріоритет No4) Низький (P4)
Дефект з низьким пріоритетом вказує на те, що проблема точно є, але її не потрібно виправляти, щоб відповідати критеріям 'вихід'. Однак це потрібно виправити до того, як буде зроблено GA. Зазвичай тут можна класифікувати деякі помилки друку або навіть косметичні помилки, про які вже йшлося раніше.
Іноді дефекти з низьким пріоритетом також відкриваються, щоб запропонувати деякі вдосконалення в існуючій конструкції або запит на впровадження невеликої функції для покращення взаємодії з користувачем.
Цей дефект може бути усунутий у майбутньому, і він не потребує негайної уваги Низька тяжкість дефекти належать до цієї категорії.
Як вже обговорювалося, пріоритет визначає, наскільки швидко повинен бути час обробки дефекту. Якщо є декілька дефектів, пріоритет вирішує, який дефект потрібно виправити та негайно перевірити, а не який дефект можна виправити трохи пізніше.
Що таке суворість?
Серйозність визначає ступінь, до якої конкретний дефект може вплинути на програму або систему.
Серйозність є параметром, що позначає наслідки дефекту для системи - наскільки критичний дефект і який вплив дефекту на функціональність всієї системи? Ступінь тяжкості - це параметр, встановлений тестувальником, коли він відкриває дефект і в основному контролює тестувальника. Знову ж таки, різні організації мають різні засоби для усунення дефектів, але на загальному рівні це такі рівні тяжкості:
Наприклад, Розглянемо такі сценарії
- Якщо користувач намагається зробити покупки в Інтернеті, і програма не завантажується, або з’являється повідомлення про недоступність сервера.
- Користувач виконує додавання товару до кошика, кількість доданих кількостей неправильна / додається неправильний товар.
- Користувач робить платіж, і після оплати замовлення залишається в кошику як зарезервоване, а не підтверджене.
- Система приймає замовлення, але, нарешті, скасовує замовлення через півгодини через будь-які проблеми.
- Система приймає “Додати в кошик” лише за подвійним клацанням, а не за одним кліком.
- Кнопка Додати в кошик пишеться як Додати в кошик.
Яким був би досвід користувачів, якби стався якийсь із наведених вище сценаріїв?
Загалом дефекти можна класифікувати наступним чином:
# 1) Критичний (S1)
Дефект, який повністю заважає або блокує тестування продукту / характеристики, є критичним дефектом. Прикладом може бути випадок тестування користувацького інтерфейсу, коли після проходження майстра користувальницький інтерфейс просто зависає на одній панелі або не йде далі, щоб запустити функцію. Або в деяких інших випадках, коли розроблена особливість відсутня у збірці.
З будь-якої причини, якщо додаток аварійно завершує роботу або воно стає непридатним / не може продовжувати подальшу роботу, дефект може бути класифікований як критичний ступінь серйозності.
Будь-які катастрофічні збої в системі можуть призвести до того, що користувач не може використовувати програми, і їх можна класифікувати за критичною важкістю
як отримати фальшивий електронний лист -
Наприклад, У постачальника послуг електронної пошти, такого як Yahoo або Gmail, після введення правильного імені користувача та пароля, замість входу в систему, система аварійно завершує роботу або видає повідомлення про помилку, цей дефект класифікується як критичний, оскільки цей дефект робить весь додаток непридатним для використання.
Обговорений вище сценарій щодо пункту 1 можна класифікувати як критичний дефект, оскільки онлайнова програма стає абсолютно непридатною для використання.
# 2) Основні (S2)
Будь-яка основна функція, яка не відповідає її вимогам / випадкам використання та поводиться інакше, ніж очікувалося, може бути віднесена до категорії серйозності.
Основний дефект виникає, коли функціонал функціонує дуже далеко від очікувань або не робить того, що повинен робити. Прикладом може бути: скажімо, що VLAN потрібно розгорнути на комутаторі, і ви використовуєте шаблон інтерфейсу, який запускає цю функцію. Коли цей шаблон для налаштування VLAN не працює на комутаторі, він класифікується як серйозний недолік функціональності.
Наприклад, У постачальника послуг електронної пошти, такого як Yahoo або Gmail, коли вам не дозволяється додавати більше одного одержувача в розділі CC, цей дефект класифікується як Основний дефект, оскільки основна функціональність програми не працює належним чином.
Як очікується поведінка розділу CC у пошті, це повинно дозволити користувачеві додати декількох користувачів. Отже, коли основна функціональність програми не працює належним чином або коли вона поводиться інакше, ніж очікувалося, це великий дефект.
Обговорені вище сценарії для пунктів 2 та 3 можуть бути класифіковані як основні дефекти, оскільки, як очікується, порядок буде плавно переходити до наступної фази життєвого циклу замовлення, але насправді це залежить від поведінки.
Будь-який дефект, який може призвести до неправильної збереженості даних, проблем із даними або неправильної поведінки додатків, може бути широко класифікований за основним ступенем серйозності.
# 3) Незначний / Помірний (S3)
Будь-яка реалізована функція, яка не відповідає її вимогам / випадкам використання та поводиться інакше, ніж очікувалося, але вплив певною мірою незначний або не робить значного впливу на програму, може бути віднесена до категорії незначної важкості.
Помірний дефект виникає, коли виріб чи додаток не відповідає певним критеріям або все ще виявляє певну неприродну поведінку, однак функціональність в цілому не впливає. Наприклад, при розгортанні шаблону VLAN вище, при успішному розгортанні шаблону на комутаторі може виникнути помірний або звичайний дефект, однак немає ознак надсилання користувачеві.
Наприклад, У постачальника послуг електронної пошти, такого як Yahoo або Gmail, є опція під назвою «Правила та умови», і в цій опції буде декілька посилань щодо умов та стану веб-сайту. Коли одне з декількох посилань не працює нормально, його називають незначною серйозністю, оскільки він впливає лише на незначну функціональність програми, і це не робить великого впливу на зручність використання програми.
Сценарій з пункту 5, обговорений вище, можна класифікувати як незначний дефект, оскільки в порядку потоку системи немає втрати даних або збою, але невеликі незручності, коли справа стосується користувацького досвіду.
Такі типи дефектів призводять до мінімальної втрати функціональності та зручності користування.
# 4) Низький (S4)
Будь-які косметичні дефекти, включаючи орфографічні помилки, проблеми з вирівнюванням або корпус шрифту, можна віднести до категорії низької серйозності.
Незначна помилка низької серйозності виникає, коли майже не впливає на функціональність, але це все ще допустимий дефект, який слід виправити. Приклади цього можуть включати орфографічні помилки в повідомленнях про помилки, надруковані користувачам, або дефекти для покращення зовнішнього вигляду функції.
Наприклад, У постачальника послуг електронної пошти, такого як Yahoo або Gmail, Ви б помітили «Сторінку ліцензії», якщо на сторінці є помилки в орфограмі або зміщення, цей дефект класифікується як Низький.
Сценарій з пункту 6, обговорений вище, можна класифікувати як з низьким дефектом, оскільки кнопка 'Додати' відображається в неправильному корпусі. Цей дефект не матиме жодного впливу на поведінку системи, презентацію даних, втрату даних, потік даних або навіть на взаємодію з користувачем, але буде дуже косметичним.
Підсумовуючи, на наступному малюнку зображена широка класифікація дефектів, заснована на серйозності та пріоритетності:
Приклади
Як уже зазначалося, оскільки різні організації використовують різні види інструментів для відстеження дефектів та пов'язаних з ними процесів, це стає загальною системою відстеження між різними рівнями управління та технічним персоналом.
Оскільки серйозність дефектів більше відповідає функціоналу, інженер-випробувач встановлює ступінь серйозності дефекту. Іноді розробники беруть участь у впливі на ступінь тяжкості дефекту, але здебільшого це залежить від тестера, оскільки він оцінює, наскільки певна функція може вплинути на загальне функціонування.
З іншого боку, коли мова заходить про встановлення пріоритету дефекту, хоча спочатку автор дефекту встановлює пріоритет, він фактично визначається менеджером продукту, оскільки він має загальне уявлення про товар і як швидко потрібно усунути певний дефект . Тестер не є ідеальною людиною для встановлення пріоритету дефекту.
Як би це не здавалося шокуючим, є два окремі приклади, чому:
Приклад №1) Врахуйте, що існує ситуація, коли користувач виявляє помилку в іменуванні самого продукту або якусь проблему з документацією щодо інтерфейсу користувача. Зазвичай тестер відкриває незначний / косметичний дефект і може бути дуже простим для усунення, але коли справа стосується вигляду та відчуття товару / досвіду користувача, це може спричинити серйозний вплив.
Приклад №2) Можуть існувати певні умови, за яких виникає певний дефект, який може бути надзвичайно рідкісним або взагалі не мати можливості потрапити в середовище клієнта. Незважаючи на те, що з точки зору функціональності це може здатися дефекту високого пріоритету для тестера, враховуючи його рідкість та високу вартість виправлення - це буде класифіковано як дефект низького пріоритету.
Отже, по суті, пріоритет дефекту, як правило, встановлюється менеджером продукту на зустрічі 'сортування дефектів'.
Різні рівні
Серед пріоритетів та важкості серед них є деякі класифікації, які допомагають визначити спосіб усунення дефекту. Багато різних організацій різні інструменти реєстрації дефектів , тому рівні можуть відрізнятися.
Давайте подивимось на різні рівні як пріоритету, так і серйозності.
- Високий пріоритет, високий рівень серйозності
- Високий пріоритет, низький рівень серйозності
- Високий рівень серйозності, низький пріоритет
- Низький рівень серйозності, низький пріоритет
На наступному малюнку зображена класифікація категорій в одному фрагменті.
# 1) Високий рівень серйозності та високий пріоритет
Будь-яка критична / велика невдача у справах автоматично переходить до цієї категорії.
Будь-які дефекти, через які тестування не може продовжуватися будь-якою ціною або спричиняє серйозні збої системи, потрапляють до цієї категорії. Наприклад, натискання певної кнопки не завантажує саму функцію. Або виконання певної функції послідовно збиває сервер і спричиняє втрату даних. Червоні лінії на малюнку вище вказують на такі види дефектів.
Наприклад,
Система аварійно завершує роботу після того, як ви здійснили платіж або коли ви не можете додати товари в кошик, цей дефект позначений як дефект високої серйозності та високого пріоритету.
Інший приклад буде функцією продажу валюти в банкоматах, коли після введення правильного імені користувача та пароля машина не видає гроші, а вираховує перераховані з вашого рахунку.
# 2) Високий пріоритет та низький рівень серйозності
Будь-які незначні вади серйозності, які можуть безпосередньо вплинути на взаємодію з користувачем, автоматично потрапляють до цієї категорії.
До цієї категорії належать дефекти, які необхідно виправити, але не впливають на заявку.
Наприклад, Очікується, що функція відображатиме певну помилку для користувача щодо його коду повернення. У цьому випадку функціонально код видасть помилку, але повідомлення повинно бути більш відповідним згенерованому коду повернення. Сині лінії на малюнку вказують на такі види дефектів.
Наприклад,
Логотип компанії на першій сторінці неправильний, він вважається таким Високий пріоритет та низький рівень серйозності дефект .
Приклад 1) На веб-сайті Інтернет-магазини, коли логотип FrontPage пишеться неправильно, наприклад, замість Flipkart він пишеться як Flipkart.
Приклад 2) У логотипі банку замість ICICI це пишеться як ICCCI.
Що стосується функціональних можливостей, це ні на що не впливає, тому ми можемо позначити його як низький рівень серйозності, але це впливає на досвід користувачів. Цей дефект потрібно виправити з високим пріоритетом, хоча вони мають дуже менший вплив на сторону програми.
# 3) Високий рівень серйозності та низький пріоритет
Будь-який дефект, який функціонально не відповідає вимогам або має якісь функціональні наслідки для системи, але відкинутий на задній план зацікавленими сторонами, коли справа стосується критичності бізнесу, автоматично переходить до цієї категорії.
Дефекти, які потрібно виправити, але не відразу. Це може статися під час спеціального тестування. Це означає, що функціональність зазнає значного впливу, але спостерігається лише тоді, коли використовуються певні незвичайні вхідні параметри.
Наприклад, певна функціональність може бути використана лише на пізнішій версії прошивки, тож для того, щоб це перевірити - тестувальник фактично оновлює свою систему і виконує тест і спостерігає серйозну проблему функціональності, яка є дійсною. У такому випадку дефекти класифікуються у цій категорії, позначившись рожевими лініями, оскільки, як правило, кінцеві користувачі повинні мати вищу версію прошивки.
Наприклад,
Якщо на сайті соціальних мереж випущена бета-версія нової функції, на сьогоднішній день нею користується не так багато активних користувачів. Будь-який дефект, виявлений у цій функції, може бути віднесений до категорії низького пріоритету, оскільки ця функція відходить на другий план через класифікацію бізнесу як неважливу.
Хоча ця функція має функціональний дефект, оскільки вона не впливає безпосередньо на кінцевих споживачів, зацікавлена сторона в бізнесі може класифікувати дефект під низьким пріоритетом, хоча він має серйозний функціональний вплив на програму.
Це помилка високого ступеня серйозності, але вона може бути пріоритетною до низького пріоритету, оскільки вона може бути виправлена в наступному випуску як запит на зміну. Ділові сторони також надають цій функції пріоритет як рідко використовуваній функції і не впливають на будь-які інші функції, що мають прямий вплив на досвід користувачів. Цей вид дефекту можна класифікувати під Високий рівень серйозності, але низький пріоритет категорії.
# 4) Низький рівень серйозності та низький пріоритет
Будь-які орфографічні помилки / шрифт / зміщення в абзаці 3рдабо 4госторінки програми, а не на головній або першій сторінці / назві.
Ці дефекти класифікуються зеленими лініями, як показано на малюнку, і виникають, коли функціональний вплив не впливає, але все ще незначно відповідає стандартам. Зазвичай тут класифікуються косметичні помилки або, скажімо, розміри комірки в таблиці на UI.
Наприклад,
Якщо в політиці конфіденційності веб-сайту є орфографічна помилка, цей дефект встановлюється як Низький рівень серйозності та низький пріоритет.
Настанови
Нижче наведені певні рекомендації, яких повинен намагатися дотримуватися кожен тестувальник:
- По-перше, добре розуміти поняття пріоритету та тяжкості. Не плутайте одне з іншим і використовуйте їх як взаємозамінні. Відповідно до цього, дотримуйтесь рекомендацій щодо суворості, опублікованих вашою організацією / командою, щоб усі були на одній сторінці.
- Завжди вибирайте рівень серйозності, виходячи з типу проблеми, оскільки це вплине на її пріоритет. Деякі приклади:
- Для критичної проблеми, такої як вся система не працює, і нічого не можна зробити - ця важкість не повинна використовуватися для усунення дефектів програми.
- Для проблеми, яка є головною, наприклад, у випадках, коли функція працює не так, як очікувалося - ця важкість може бути використана для вирішення нових функцій або вдосконалення поточної роботи.
Пам’ятайте, що вибір правильного рівня серйозності, в свою чергу, дасть дефект, це належний пріоритет.
- Як тестер - зрозуміти, як певна функціональність, а не детальніше вивчати - зрозуміти, як конкретний сценарій або тестовий випадок вплине на кінцевого користувача. Це передбачає багато співпраці та взаємодії з командою розробників, бізнес-аналітиками, архітекторами, керівником тестування, керівником розробників. У дискусіях вам також потрібно врахувати, скільки часу знадобиться для виправлення дефекту, виходячи з його складності та часу, щоб перевірити цей дефект.
- Нарешті , Власник продукту завжди має право вето на випуск дефекту повинен бути виправлений. Однак, оскільки сеанси сортування дефектів містять різних членів, щоб представити свою точку зору на дефект на кожному конкретному випадку, і в той час, коли розробники та тестувальники синхронізуються, це, безумовно, допомагає впливати на рішення.
Висновок
Під час розкриття дефектів тестер відповідає за те, щоб присвоїти дефектам належну важкість. Неправильна серйозність і, отже, картографування пріоритетів може мати дуже суттєві наслідки для загального процесу STLC та продукту в цілому. На кількох співбесідах - є декілька запитань щодо пріоритету та суворості, щоб гарантувати, що ви, як випробувач, маєте ці ідеї бездоганно зрозумілими.
Крім того, ми бачили в реальному часі приклади того, як класифікувати дефект за різними сегментами серйозності / пріоритетності. На даний момент я хотів би, щоб у вас було достатньо роз’яснень щодо класифікації дефектів як у сегментах серйозності / пріоритету.
Сподіваюся, ця стаття є повним посібником для розуміння пріоритету та ступеня тяжкості дефекту. Повідомте нам про свої думки / запитання в коментарях нижче.
Рекомендована література
- Що таке техніка тестування на основі дефектів?
- Що таке життєвий цикл дефектів / помилок при тестуванні програмного забезпечення? Підручник з життєвого циклу дефектів
- Процес управління дефектами: як ефективно управляти дефектом
- Як відтворити невідтворюваний дефект і зробити тестування вартим того
- 7 принципів тестування програмного забезпечення: Кластеризація дефектів і принцип Парето
- Методи та методи запобігання дефектам
- Точна різниця між верифікацією та валідацією на прикладах
- 3 стратегії боротьби з дефектом блокатора