Остаточний посібник з тестування на основі ризиків: управління ризиками при тестуванні програмного забезпечення

ultimate guide risk based testing

Остаточне керівництво з тестування на основі ризиків, управління ризиками та його підходу з прикладами:

Що таке тестування на основі ризику?

Тестування, засноване на оцінці ризику, полягає у проведенні тестування або розробці та виконанні сценаріїв, таким чином, що найвищі ділові ризики, які матимуть негативний вплив на бізнес, визначені замовником, виявляться в їх продукті або особливості на початку життєвого циклу та пом'якшення шляхом здійснення заходів щодо пом'якшення наслідків.

=> Клацніть тут, щоб отримати повну серію підручників з плану тестування

Негативний вплив може включати вплив на витрати, незадоволеність клієнта, поганий досвід користування та навіть у міру втрати клієнтів.

Іншими словами, підхід RBT полягає у забезпеченні того, щоб тестування проводилося таким чином, що навіть якщо користувач знаходить помилку у виробництві, що не заважає йому / їй використовувати програмне забезпечення або не впливає на бізнес серйозним чином.

RBT проводить випробування на основі товарних ризиків. RBT має з’ясувати заздалегідь, оскільки існує ризик виходу з ладу певної функції чи функціональності у виробництві та його впливу на бізнес з точки зору витрат та інших збитків, використовуючи техніку пріоритезування для тестових випадків.

Отже, тестування на основі ризиків використовує принцип пріоритетність тестів функцій, модулів та функціональних можливостей продукту чи програмного забезпечення. Розміщення пріоритетів базується на ризику ймовірності виходу з ладу цієї функції чи функціональних можливостей у виробництві та його впливу на споживачів.

Що ви дізнаєтесь:

• Тестування на основі ризику та його відповідність Agile & DevOps
  • Підхід до тестування на основі ризику
    • Коли ми використовуємо підхід RBT?
    • Приклад підходу RBT
  • Шляхи проведення аналізу ризиків
  • Процедура аналізу ризиків
  • Методологія аналізу ризиків
    • Крок No1) Використання сітки 3X3
    • Крок №2) Ймовірність та вплив несправності
    • Крок No3) Тестування пріоритетної сітки
    • Крок No4) Деталі тестування
  • Як RBT релевантний Agile та DevOps?
  • Переваги підходу, що базується на оцінці ризику
• Управління ризиками під час планування випробувань
  • Процес управління ризиками
    • # 1) Визначення ризику
    • # 2) Оцінка ризику / Аналіз впливу на ризик
    • # 3) Зменшення ризику
  • Висновок
• Управління ризиками на етапі виконання тесту (з прикладом)
  • Управління ризиками - з акцентом на AUT
  • Як відбувається тестування підстав ризику?
  • Висновок
  • Рекомендована література

Тестування на основі ризику та його відповідність Agile & DevOps

Триста годин, витрачених на розробку програмного забезпечення, можна зробити марними всього за 30 секунд з одним виявленим дефектом у виробництві.

Це, в свою чергу, може зруйнувати ціль всього товару, не маючи іншого вибору, окрім як просто вилучити його з ринку. І в цьому полягає важливість та потреба „перевірки якості”.

Зі стрімким зростанням технологій програмне забезпечення розміщується в хмарі, що підтримує декілька ОС, декілька платформ, складну ІТ-інфраструктуру тощо, і кінцеві користувачі стають дедалі сумнівнішими щодо функцій, опцій, і вони ніколи не йдуть на компроміси для задоволення споживачів .

На сьогодні «Якість» стає вирішальним фактором доставки програмного забезпечення, де постійно вдосконалюються, щоб покращити якість, щоб зробити клієнтів щасливими.

Ми часто зауважуємо, що майже для всіх тестувальників загальною проблемою є величезний тиск, що їх вікно тестування стискається, і, як правило, збірка передається їм для тестування в останню хвилину. У них не вистачає часу та ресурсів для запуску всіх розроблених ними тестів, і охоплення автоматикою не завжди є 100%, і це має свої проблеми.

Термін доставки не можна пропустити, і в той же час якість також не може бути порушена. Яким би не був план Б, додавання додаткових тестових ресурсів шляхом вилучення з інших команд не працює, План С, припиніть робити всі інші заходи та перенаправляйте зусилля на це одне, насправді не допомагає. Однак, зрештою, додавання тестових ресурсів не працює.

Немає іншого варіанту, окрім як просто провести обмежені та важливі тести в межах доступного часу та ресурсів.

Отже, як ми вирішимо, який тест важливий на цьому етапі? Що б тестер не вважав важливим, для клієнтів може бути не дуже важливим. З чиєї точки зору визначається важливість функції чи функціональності? Хто вирішить, які важливі тести? І багато інших питань виникають.

Для того, щоб відповісти на всі ці запитання та ефективно впоратись із вищезазначеною ситуацією, було запропоновано підхід до тестування «Тестування на основі ризику» , коротко зателефонований 'RBT' , який з’явився, коли команда чітко спланувала та визначила сценарії випробувань на основі критеріїв „Ризик проекту”.

Незважаючи на те, що команда QA має чітке уявлення про важливі тести, RBT є перевіреним методом ідентифікації важливих та важливих тестів з точки зору замовника та бізнесу за допомогою 'Аналіз ризику' процедури .

Отже, зараз, на відміну від традиційного способу простого виявлення дефектів програмного забезпечення, підхід та цілі контролю якості змінювались із часом через зміну технології, посилення конкуренції на ринку за випуск якісного програмного забезпечення, впровадження 'Автоматизувати все', і в цілому введення практики Agile та DevOps щодо доставки програмного забезпечення протягом декількох годин.

Отже, нинішня тенденція «Принципу тестування» полягає не просто у «виявленні дефектів», а й у тому, щоб

# 1) Зосередьтеся на тій частині товару, де існує сильний вплив на бізнес через відмову або велику ймовірність відмови у виробництві.

# два) Зосередження уваги на виявлення дефектів якнайшвидше і дозволяючи команді виправити це якомога раніше, а отже, дозволяючи програмному забезпеченню / продукту чи функції «Не вдається швидко».

# 3) Найважливішим аспектом обслуговування команди з контролю якості зараз є зосередження уваги на клієнті, щоб принести користь клієнту, збільшивши увагу на „Наскрізний досвід клієнтів“.

Підхід до тестування на основі ризику

Завжди подібно до підготовки до іспиту, тому що не можна сказати, що тестування достатньо, і більше немає дефектів програмного забезпечення, навіть якщо вони розробляють і виконують велику кількість тестів.

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

Отже, важливо досягти рівноваги в оптимізації тестування, щоб отримати максимальну користь при розумних зусиллях тестування. І це важливіше, коли терміни тестування є дуже обмеженими і недостатньо ресурсів для проведення достатнього тестування.

Таким чином, у цьому випадку підхід RBT відіграє ключову роль в оптимізації зусиль із забезпечення якості та максимізації вигідного тестування з мінімальним комерційним ризиком.

Отже, якщо ми зосередимось на вищезазначеному аспекті, то робота з контролю якості буде значно полегшена. Їм не потрібно спалювати свої вихідні в офісі, постійно тестуючи програмне забезпечення і турбуючись про всі дефекти S4 (важкість 4) і P4 (пріоритет 4), які виходять під час тестування.

Ну, 4 вважається найменшим пріоритетом і тяжкістю дефектів при тестуванні. Вони можуть краще інвестувати свій час в інші корисні аспекти проекту.

Підсумовуючи основні фактори підходу «Тестування на основі ризику»:

• Увімкнути тестування «того, що хочуть клієнти» з точки зору бізнесу.
• Щоб відповідати графіку з очікуваною якістю.
• Оптимізувати зусилля з забезпечення якості.

Коли ми використовуємо підхід RBT?

Це використовується в наступних сценаріях:

• Підхід RBT можна використовувати, коли є обмеження чи обмеження щодо часу, вартості та ресурсів проекту, а також коли виникає потреба в оптимізації ресурсів.
• Підхід RBT застосовується, коли програма є більш складною та адаптує нові технології, а отже, включає багато проблем.
• Коли програма є науково-дослідним проектом, і вона має перший тип, і в проекті є ряд невідомих та ризиків.

Приклад підходу RBT

Кілька підходів до аналізу, заснованих на оцінці ризику, використовуються в ІТ-галузі для подолання ризиків, з якими стикається виробництво та його вплив.

Нижче наведено один із таких підходів:

Цей підхід RBT включає визначення «життєво важливих функцій або ключових особливостей» продукту та оцінку ризиків, яким кожна з цих функцій піддається виробництву, та впровадження відповідних заходів щодо зменшення ризику для зменшення або зменшення ризику.

Отже, підхід RBT включає тестування функціональних можливостей, які мають ймовірність збоїв та найбільший вплив на бізнес. Типи відмов можуть бути операційними або діловими, технічними, зовнішніми тощо.

Шляхи проведення аналізу ризиків

Не існує стандартного процесу чи шаблону, як такого, що дозволяє проводити аналіз ризиків при тестуванні програмного забезпечення для кожної функції продукту. Різні організації використовують власний підхід до методів аналізу ризиків.

Аналіз ризиків може проводитись за різними статтями проекту для виявлення ризиків та впровадження підходу RBT для аналізу. Ці предмети включають,

• Особливості
• Функціональні можливості
• Історії користувачів
• Вимоги
• Використовуйте кейси
• Тестові кейси

У цьому випадку, зосередимось лише на тестових випадках, щоб зрозуміти реалізацію підходу, що базується на оцінці ризику.

Процедура аналізу ризиків

Аналіз ризиків включає залучення відповідних зацікавлених сторін програми як Технічна команда та команда бізнесу , до складу якого входять власник продукту, менеджери з продуктів, бізнес-аналітики, архітектори, тестувальники та представники замовника.

Для проведення дискусії з метою виявлення важливості кожної особливості товару та визначення їх пріоритетів на основі ризику несправності та його впливу на кінцевих споживачів у виробництві будуть організовані мозкові штурми.

Різні „проектні документи”, такі як Документи вимог, Документи технічних специфікацій, Документи архітектури та дизайну, Документи бізнес-процесів, Документи справи використання тощо, стануть вкладом для сеансу мозкового штурму.

Знання зацікавлених сторін про товар та існуючий товар на ринку також буде вхідним фактором для обговорення.

Деякі інші джерела вхідних даних також можуть включати,

• Збирати дані щодо найбільш використовуваних функціональних можливостей.
• Дані консультації експерта з доменів.
• Дані попередньої версії товару або подібного продукту на ринку.

Під час мозковий штурм сесії визначено ризики, що стосуються кожної з цих особливостей. Видами ризиків може бути операція, технічна або пов'язана з бізнесом. Тести та сценарії, пов'язані з ними, зважуються, і значення ризику оцінюються на основі ймовірності виникнення ризику та впливу ризику.

„Імовірність виникнення ризику” може бути пов’язана з:

• Погане розуміння цієї функції командою розробників продукту.
• Неправильна архітектура та дизайн.
• Недостатньо часу для проектування.
• Некомпетентність колективу.
• Недостатні ресурси - люди, інструменти та технології.

„Вплив ризику” - це ефект відмови для користувачів та бізнесу, якщо він виник. Вплив може бути,

• Вплив витрат, що призводить до збитків.
• Вплив на бізнес, що призводить до втрати бізнесу або втрати частки ринку, судочинство, втрата ліцензії.
• Вплив на якість, що призводить до випуску неякісного або некомпетентного продукту.
• Поганий досвід користувачів, що призводить до незадоволеності та втрати клієнта.

Зоною фокусування оцінки ризику функції чи продукту може бути,

• Сфера ділової критичності функціоналу.
• Найчастіше використовувані функції та важливі функції.
• Ділянки, схильні до дефектів
• Функціональність, що впливає на безпеку та безпеку.
• Сфера комплексного проектування та архітектури.
• Зміни, внесені до попередніх версій.

Методологія аналізу ризиків

Давайте детально розберемося в «Методології тестування на основі ризику».

Підхід до тестування, заснований на оцінці ризику, використовує РИЗИК як критерій на всіх етапах тестування циклу тестування, тобто планування тесту , дизайн тесту, реалізація тесту, виконання тесту та звітність про тести. В ідеалі можна розробити безліч можливих комбінацій сценаріїв тестування.

Отже, підхід RBT включає ранжування тестів на основі серйозності ризиків для виявлення найбільш дефектної або ризикованої області відмов, що спричиняє великий вплив на бізнес.

Основною метою аналізу ризиків є розрізнення між «Висока цінність» такі елементи, як характеристики продукту, функціональні можливості, вимоги, історії користувачів , і тестові кейси, і „ Низьке значення таких, а отже, пізніше, щоб більше зосередитись на тестових справах з високим значенням, менше фокусуючись на тестових випадках з низьким значенням. Це початковий етап аналізу ризику перед початком тестування на основі ризику.

Основне завдання класифікації або групування тестових випадків за великим значенням і низьким значенням та присвоєння пріоритетного значення кожному з цих тестових випадків включає наступні кроки:

Крок No1) Використання сітки 3X3

Аналіз ризиків виконується за допомогою сітки 3X3, де група функціональних можливостей, нефункціональність та пов'язані з ними тестові випадки оцінюються групою зацікавлених сторін на предметЙмовірністьпро збій »та« Вплив провалу ».

До ймовірності виходу з ладу кожної функціональності у виробництві, як правило, звертається група „Технічних експертів”, і їх класифікують як „Ймовірно, відбудеться збій, цілком імовірно і малоймовірно” вздовж вертикальної осі сітки.

як написати тестовий кейс у аркуші

Подібним чином 'вплив наслідків відмови' цих особливостей та функціональних можливостей у виробництві відчуває кінцевий споживач, якщо не перевірено, оцінюється групою ' Спеціалісти з бізнесу »та класифікуються за категоріями« Незначні, видимі та переривання »вздовж горизонтальної осі сітки.

Крок №2) Ймовірність та вплив несправності

Усі тестові кейси розміщені в квадрантах сітки 3 X 3 на основі виявлених значень ймовірності відмови та впливу відмови, які зображені крапками на малюнку нижче.

Очевидно, що висока ймовірність поломки та сильний вплив поломки (переривання) згруповані у верхньому правому куті сітки, що має велике значення, і, отже, визначено, що тести 'Висока вартість' та 'Низька вартість' групуються в нижній лівий кут, що є найменшим або зовсім не важливим для клієнта, де ці функції або тестові приклади можуть бути зосереджені незначно.

Крок No3) Тестування пріоритетної сітки

Виходячи з вищезазначеного розташування тестових кейсів у сітці, тести мають пріоритети та маркуються з пріоритетами 1,2,3,4 та 5 і ставляться до кожного з них. Найважливіші тести розміщені в 1^вулсітки, яким призначено пріоритет 1, а також менш важливі - класифікуються як 2, 3, 4 та 5.

Нарешті, усі тестові кейси сортуються на основі їх пріоритетних номерів і відбираються для виконання у порядку пріоритету. Першочергові приймаються для виконання першими, а низькопріоритетні - або виконуються пізніше, або скасуються.

Крок No4) Деталі тестування

Наступним кроком є ​​прийняття рішення щодо рівня деталізації тестування для визначеного обсягу тестування. Глибину обсягу тестування можна визначити, виходячи з наведеного вище рейтингу відповідно до таблиці нижче.

Тести з високим пріоритетом із рейтингом 1 проходять тестування «Більш ретельно», і відповідно експерти залучаються для перевірки цих особливостей високої критичності та пов’язаних з ними тестових випадків. Подібним чином тестові випадки з пріоритетом 2, 3 і 4. Рішення про скасування особливостей пріоритету 5 та тести можуть бути прийняті на основі доступного часу та ресурсів.

Отже, підхід до рівня деталізації тестування щодо встановлення пріоритетів для функцій та його тестових кейсів не тільки допомагає тестерам визначити „високоякісні тести”, але також керує ними щодо прийняття рішення щодо „рівня деталізації тестування” на основі цих рейтингів пріоритетів та допомагає їм проводити краще тестування та зменшує вартість тестування шляхом процесу оптимізації.

Як RBT релевантний Agile та DevOps?

Тепер, зрозумівши підхід тестування на основі ризику проведення тестування на основі встановлення пріоритетності тестів залежно від «Ризику відмови» певної функції та його «Впливу на клієнта» в прямому ефірі, очевидно, можна було б поставити питання про актуальність підходу, що базується на оцінці ризику, в практиках Agile та DevOps.

«Автоматизувати все», «Тестувати все», «Неперервно тестувати», «Тестувати багаторазово» - ключові поняття цих практик.

Кожного разу, коли відбувається зміна коду або відбувається випуск, всі розроблені тести запускаються через автоматизований Безперервна інтеграція (CI) / Безперервна доставка (CD) трубопроводу швидко і багаторазово, незалежно від пріоритетності.

Тоді яке відношення між RBT та DevOps? Де RBT вписується і стає актуальним в Agile та DevOps ???

# 1) Так, як я вже говорив раніше, це не те, що кожна галузь та кожен продукт мають 100% покриття автоматизації для своїх тестових робіт. Отже, якщо команда взагалі повинна зробити вибір пріоритетів для виконання тесту з вибору ручних тестових кейсів і хотіла б пощадити енергію та зусилля тестових ресурсів для інших видів діяльності, тоді RBT є найкращим вибором.

Підхід, заснований на оцінці ризику, також є кращим вибором для проведення автоматизованих тестів з високопріоритетними та тестування як можна раніше.

# два) Команда контролю якості може ефективніше застосувати підхід RBT під час аналізу вимог при аналізі вимог та наданні попереднього звіту про ймовірні ризики продуктів та характеристик, щоб команда програми могла вжити попередніх заходів для його пом'якшення.

# 3) Підхід RBT може бути ефективно використаний при розробці тестових випадків та сценаріїв, заснованих на високому ризику, щоб можна було більше зосередитись на особливостях та функціональних можливостях високого ризику.

# 4) Визначення сфер «високого ризику» дозволяє команді контролю якості зосередити свої зусилля на тестуванні на цих областях, щоб перевірити «більш ретельно» за допомогою «висококваліфікованих тестувальників».

# 5) Як ми всі добре знаємо, 'Fail Fast' - це концепція 'Agile' та 'DevOps', для яких підхід RBT допомагає виявити зони 'високого ризику' в програмному забезпеченні, виявити дефекти на ранніх стадіях і дозволити їм швидко і невдало спочатку і нехай команда це виправить.

# 6) Кінцевою метою Agile / DevOps є «орієнтація на клієнта», а отже, підхід RBT дозволяє службі контролю якості зосередитись на досвіді клієнтів, а не просто на виявленні дефектів.

Переваги підходу, що базується на оцінці ризику

Ми вже зрозуміли мету та використання підходу RBT для аналізу вимог, розробки та виконання сценаріїв тестування. Є кілька переваг RBT.

Ми можемо консолідувати та перерахувати переваги тестування на основі ризику як:

• Допомагає в більш ефективному та оптимізованому використанні тестових ресурсів.
• Допомагає полегшити роботу з контролю якості, тестування, розробку та розробку випробувань та підготовку до випробувань шляхом визначення пріоритетів.
• Допомагає в кращому управлінні ресурсами контролю якості, розподіляючи ключові ресурси у зони високої уваги.
• Це допомагає ефективно використовувати ресурси та відволікає їхній час та енергію на кращі речі в проекті.
• Допомагає команді з контролю якості у плануванні випробувальних заходів на основі оцінки ризику та виявлення мінливих та небезпечних районів.
• Це допомагає команді оптимізувати тести, які слід проводити, залежно від важливості, а отже, зменшити обсяг низькоцінного тестування за погодженням із зацікавленими сторонами.
• Загалом це допомагає зменшити витрати завдяки оптимізованому та зменшеному тестуванню.
• Підхід RBT дозволяє команді QA спочатку протестувати зони підвищеного ризику, а також дозволяє продукту швидко виходити з ладу та швидко виправляти ситуацію.
• Підхід RBT допомагає внести ясність у Покриття тесту і «Тестовий обсяг» для всієї групи зацікавлених сторін.
• Команда може зосередити свою увагу на зонах підвищеного ризику та тримати менше уваги на зонах низького ризику.
• RBT дозволяє Команді заздалегідь прийняти рішення про впровадження найефективнішого способу пом'якшення ризиків, пов'язаних з товарами.
• RBT допомагає уникнути ефекту від неналежного здійснення пом'якшувальних заходів.
• Тестування, засноване на оцінці ризику, дозволяє команді вжити відповідних заходів або для пом’якшення ситуації, або для планування дій на випадок непередбачених ситуацій, або визначити будь-яке обхідне рішення, щоб подолати несправність або зменшити його вплив, якщо ризик виникає в режимі Live.
• RBT допомагає мінімізувати залишковий ризик при викиді.
• Це допомагає досягти 'поліпшеної якості' через менш дорогі дефекти у виробництві.
• Врешті-решт допомагає в «Покращеній взаємодії з клієнтами» та «Задоволеному клієнту».

Далі ми дізнаємось, як керувати ризиками на етапах планування та виконання тестів життєвого циклу тестування програмного забезпечення.

Управління ризиками під час планування випробувань

Як керувати ризиками на етапі планування випробувань:

Життя сповнене ризиків, як і програмний проект. Все може піти не так у будь-який час. Ми завжди готові виправити ситуацію, але як бути з тим, щоб переконатися, що нічого не пішло не так, і що коли це станеться, ми точно знаємо, що робити? Введіть управління ризиками - це частина проекту тестування програмного забезпечення, який готує нас до запобігання, розуміння, пошуку та подолання ризиків.

Ризик - це просто проблема, яка, ймовірно, може виникнути, і коли вона все ж виникне, вона спричинить збитки.

Втрата може бути якою завгодно - грошима, часом, зусиллями або компромісом у якості. Втрата ніколи не буває хорошою. Незалежно від того, скільки обертання ми дамо йому, це не позитивно - і ніколи не буде. Тому Управління ризиками є невід’ємною частиною програмних проектів, щоб переконатися, що ми обробляємо ризики та запобігаємо / зменшуємо збитки.

Тестування на основі ризику : Оскільки ми співтовариство з контролю якості, давайте залишатись конкретними щодо ризиків та процесів, пов’язаних із цим, виключно у нашому світі контролю якості. Ризики оцінюються та управляються приблизно за два етапи нашого Життєвий цикл тестування програмного забезпечення . STLC можна розділити на 3 етапи - планування випробувань, проектування випробувань та виконання випробувань.

Процес управління ризиками відбувається двічі, під час:

1. Планування тестів
2. Дизайн тестового кейсу (кінець) або інколи на етапі виконання тесту

Це є обов’язковим у випадку 1, але у випадку 2 це скоріше ситуація „на основі потреби”.

Серія статей із двох частин:

Незважаючи на те, що основний процес є однаковим, види ризиків в обох цих сферах абсолютно різні. Для справедливості стосовно них ми збираємося по-різному обробляти їх як серію із двох частин.

Цей розділ буде про “Управління ризиками під час планування випробувань'.

Процес управління ризиками

Загальний процес управління ризиками включає 3 важливі етапи:

1. Визначення ризику
2. Аналіз впливу ризику
3. Зменшення ризику

Приклади тестування ризиків та пом'якшення наслідків:

# 1) Визначення ризику

Як сказано, першим кроком до вирішення проблеми є її виявлення. Цей етап передбачає складання списку всього, що потенційно може виникнути і порушити нормальний потік подій.

Основним результатом цього кроку є перелік ризиків.

Цей крок тестування, заснований на оцінці ризику, зазвичай проводить керівник / менеджер / представник контролю якості. Однак лише керівник не зможе скласти цілий список - весь внесок команди з контролю якості робить величезний вплив. Можна сказати, що це колективна діяльність, яку веде керівник з контролю якості.

кращий DVD Ripper для Windows 7

Крім того, ризики, які виявляються на етапі планування випробувань, є більш 'управлінськими' в орієнтації, тобто ми розглянемо все, що може вплинути на графік проекту, зусилля, бюджет, зміни інфраструктури тощо. Основна увага тут приділяється не AUT, а шлях, який триватиме фаза контролю якості.

Ризики під час планування тестів: приклади тестування на основі ризиків

Далі наведено зразок переліку ризиків, які можуть бути перераховані на етапі планування випробувань. Зверніть увагу, що функція AUT та її функціональність тут не є основною.

1. Графік випробувань жорсткий. Якщо початок тестування затримується через завдання проектування, тест не може бути продовжений після запланованої дати початку UAT.
2. Недостатньо ресурсів, ресурси входять занадто пізно (процес займає близько 15 днів).
3. Дефекти виявляються на пізній стадії циклу або на пізній циклі; дефекти, виявлені пізно, швидше за все, пов'язані з незрозумілими технічними характеристиками та вимагають багато часу для їх усунення.
4. Сфера застосування не визначена повністю визначена
5. Стихійні лиха
6. Недоступність Independent Тестове середовище та доступність
7. Затримка тестування через нові проблеми

На цьому етапі ви можете бути настільки ретельним, наскільки хотіли б, залежно від доступного часу.

Коли всі ризики перераховані, ми переходимо до оцінки ризиків / аналізу впливу ризику.

# 2) Оцінка ризику / Аналіз впливу на ризик

Ваш аналіз ризиків - щось подібне? :)

Аналіз ризиків при тестуванні програмного забезпечення : На цьому етапі всі ризики визначаються кількісно та визначаються за пріоритетами. Імовірність кожного ризику (ймовірність його виникнення) та вплив (сума збитків, яку він міг би спричинити, коли цей ризик матеріалізується) визначаються систематично.

Високий - середній-низький , значення присвоюються як імовірності, так і впливу кожного ризику. Спочатку подбають про ризики з „високою” ймовірністю та „високим” впливом, а потім дотримуються порядку.

Таблиця аналізу впливу на ризик:

Після цих кроків таблиця аналізу впливу ризиків для перелічених вище ризиків виглядатиме приблизно так (усі значення є гіпотетичними та лише для цілей розуміння):

# 3) Зменшення ризику

Завершальним кроком у цьому процесі тестування на основі ризику (RBT) є пошук рішень для планування того, як вирішити кожну з цих ситуацій. Ці плани можуть відрізнятися від компанії до компанії, від проекту до проекту і навіть від людини до людини.

Методи зменшення ризику:

Ось приклад того, у що перетворюється таблиця ризиків, коли ця фаза завершена:

Кілька моментів, на які слід звернути увагу:

1. Чим швидше розпочнеться управління ризиками на етапі планування контролю якості, тим краще.
2. З усіх 3 кроків, Визначення ризику є найважливішим . Якщо що-небудь не внесено до списку та розглянуто для подальших кроків, ризик не обробляється.
3. Спробуйте знайти ідеальні часові рамки для цієї діяльності. Пам’ятайте, що занадто багато планування залишає занадто мало часу для виконання.
4. Крім того, після процесу управління ризиками, якщо виникає нова ситуація, план управління ризиками може бути змінений або оновлений з урахуванням найбільш поточного стану.
5. Історичні дані може бути дуже корисним для успіху цього процесу.

Висновок

Це підводить нас до кінця управління ризиками на етапі планування тесту. Незважаючи на те, що основні кроки та принципи схожі, процес управління ризиками є більш сконцентрованим на AUT, коли це відбувається на етапі проектування / виконання тесту.

У нашому наступному розділі ми розглянемо - Управління ризиками на етапі тестування.

Управління ризиками на етапі виконання тесту (з прикладом)

Під час нашої подорожі до розуміння процесу управління ризиками ми говорили про те, як він відбувається виключно в Етап планування тестування на основі ризику . Ми також зрозуміли загальний процес, який включає - ідентифікацію ризиків, оцінку ризику та план зменшення ризиків.

Як керувати ризиком на етапі проектування тесту або виконання тесту:

Існує ще одна форма Управління ризиками (також іноді називають, Тестування на основі ризику ), що відбувається під час проектування тесту або етапу виконання тесту залежно від ситуації. Тепер, про яку ситуацію ми говоримо? Спробуємо спочатку це зрозуміти.

Ми всі знаємо, що наша робота з тестування реагує. Жодних вимог (або сфери дії не визначено), ми не можемо виконати аналіз техніко-економічного обґрунтування та написати сценарії тестування чи план тестування.

Подібним чином, коли код не готовий, нам нічого перевіряти, незалежно від того, яку величину підготовчих робіт ми могли б бути готовими в рамках тестових кейсів, даних тестів тощо. Крім того, тестування - це єдиний крок, що залишився до виходу продукту жити.

Управління ризиками - з акцентом на AUT

Давайте зрозуміємо це краще на прикладі:

Якщо тестування повинно було розпочатися вказаної дати, 1 січня^вулі повинен був тривати до 14 січня^го- коли тестування закінчується, дата запуску продукту зазвичай встановлюється негайно. Скажімо - 15 січня^годля простоти. Зараз у ідеальному світі справи йдуть точно так, як планували. Але ми всі знаємо реальність.

У цьому випадку припустимо, що з якихось причин тестування розпочалось лише 7 січня^го, що означає, що ми втратили половину часу тестування. Але нам потрібно 14 днів, щоб ретельно протестувати продукт. Ми могли б перенести дату запуску далі на 7 днів - однак; зазвичай це не варіант. Оскільки товар обіцяють вийти на ринок у визначену дату, і будь-які затримки не є корисними для бізнесу.

Отож, як правило, ми тестувальним групам доводиться компенсувати затримки, якось компенсувати, працювати з наявним часом і переконатися, що продукт перевірений добре. Важка робота, чи не так?

Тут знову застосовується процес управління ризиками.

• Зараз, якщо затримки передбачаються раніше часу ще до початку тестування - процес відбувається на етапі проектування тесту.
• Якщо затримки трапляються під час Етап виконання тесту що розпочався нормально - процес дотримується на етапі виконання тесту.
• Етапи та метод однакові, незалежно від того, на якій стадії це відбувається.

Який процес?

Управління ризиками здійснюється для того, щоб визначити, на яких областях АВТ (тестова програма) потрібно зосередитись. Зазвичай це функціональні області (модулі або компоненти), які є критично важливими для успіху кінцевого продукту і є найбільш схильними до відмов.

Читайте також=> Аналіз режиму несправності та ефектів (FMEA) - це методика управління ризиками

Хто це виконує?

Оскільки це стосується AUT, знання про це не лише у QA, але й у всіх інших команд - розробників, BA, клієнтів, команд управління проектами і т. Д. Тому це колективне зусилля, зумовлене командою тестування.

Як відбувається тестування підстав ризику?

Крок 1) Визначення ризику

Визначте всі функціональні області AUT. Це просто включатиме складання списку.

Крок No2) Оцінка ризику

На цьому етапі всі ризики визначаються кількісно та визначаються за пріоритетами. Кількісна оцінка - це просто присвоєння числа кожному ризику у списку, яке дасть вказівку на пріоритет, з яким він повинен бути вирішений.

Визначаються ймовірність кожного ризику (ймовірність його виникнення) та вплив (сума збитків, яку він може спричинити, коли цей ризик матеріалізується).

Типовий метод - присвоєння рейтингів. Наприклад, Імовірність може приймати значення від 1 до 5. 1, що є ймовірністю виникнення, є низьким (навряд чи це трапиться взагалі), а 5 високим (це, безумовно, відбудеться).

Подібним чином Impact також може бути присвоєно рейтинг 1-5. 1 - низький вплив (навіть якщо цей ризик справдиться, втрата мінімальна), а 5 - великий вплив (величезні втрати, коли це трапляється).

Крок No3)

Складіть формат таблиці та надішліть її всім представникам команд - розробникам, спеціалістам, клієнтам, прем'єр-міністрам, контролю якості та будь-кому іншому.

Крок No4)

Доручіть кожній команді заповнити значення на основі їх рейтингу щодо ймовірності та впливу.

Оскільки значення ймовірності та впливу є числовими, це полегшить обчислення значення “Фактора ризику”.

Фактор ризику = Імовірність X Вплив. Чим вище фактор ризику, тим серйознішою є проблема.

Приклад:

Зверніть увагу, що на даний момент це просто результат рейтингу однієї команди. Для проекту, в якому задіяно 5 різних команд, команда контролю якості отримала б 5 різних таблиць.

Крок No5)

Візьміть середнє значення коефіцієнта ризику. Наприклад, якщо є 5 команд, для кожного модуля додайте всі значення фактора ризику і розділіть їх на 5. Це остаточні значення, з якими ми будемо мати справу. Скажімо, це усереднені фактори ризику:

Чим більше фактор ризику, тим більше цей модуль повинен бути перевірений.

Отже, модулі 5 та 2 є найбільш важливими для успіху бізнесу. Поділіться результатами з усіма командами.

Крок No6)

План зменшення ризику : Зараз це крок, який змінюється від проекту до проекту. Ми виявили, що модулі 5 та 2 - це ті, на яких слід зосередитись у більшості.

Прикладиплану може бути:

1. Модулі 5 і 2 будуть ретельно перевірені, переконавшись, що всі тестові випадки, пов’язані з ними, перевірені. Інші модулі будуть протестовані на дослідницькій основі.
2. Спочатку модулі 5 та 2 будуть протестовані, а потім, залежно від доступного часу, піклуватимуться про інші.

Після складання плану всі команди досягають домовленості та дотримуються її для тестування продукту з урахуванням фактору ризику.

Це воно!

Кілька важливих моментів, на які слід звернути увагу:

• Оскільки це колективна діяльність, яка вимагає думка кожного ; шанси на точність та ефективність вищі.
• Це є не формальний метод і не повинен бути частиною кожного проекту контролю якості.
• Іноді, навіть якщо команда вирішує не малювати таблиці і не призначати значення - а простий сеанс мозкового штурму разом з усіма присутніми можуть дати команді з контролю якості хороші вказівки щодо подальших дій.
• внесок команди розробників дуже важливо, оскільки саме вони створюють продукт, тому вони будуть знати, що може працювати, а що може потребувати додаткової перевірки. Обов’язково слідкуйте за цим.
• Незважаючи на те, що в процесі є кілька кроків, для їх виконання не потрібно значної кількості часу . Особливо, якщо всі команди можуть сидіти разом і працювати одночасно.
• Запам’ятайте цей процес та його результат лише альтернатива . Отримати стільки часу, скільки заплановано на тестування, є найкращим способом виконання контролю якості.

Висновок

Підхід до тестування на основі ризику чітко вказує на те, що фокус тестувальника полягає не лише у постійному вивченні дефектів, незалежно від тяжкості та пріоритету. Тепер все змінилося, і тестери повинні працювати розумно, і вони повинні розуміти чітке „Потреба Замовника та Потреба Користувача“.

Вони повинні ретельно вивчити товар і зрозуміти, яка функція найчастіше використовується у виробництві, що є найважливішим шляхом отримання доходу та як захистити та захистити споживачів від виробничих проблем та бізнес-загроз.

Отже, підхід RBT чітко навчає 3 тестувальників, що тестування всього або екстенсивне тестування не означає, що тестування завершено або відсутні дефекти у продукті. Ефективне тестування у встановлений термін та забезпечення того, щоб критичні та основні наслідки для бізнесу були зведені нанівець, а це досить важливо для тестувальника.

Таким чином, тестування на основі ризику є найефективнішим інструментом для команди контролю якості для керівництва зацікавленими сторонами проекту на основі проектних ризиків. Підхід RBT допомагає команді контролю якості в постійному виявленні ризику та його вирішенні, що може загрожувати досягненню загальних цілей та завдань проекту, а також допомагає досягти кінцевої мети групи контролю якості.

P.S. Слова QA та Testing були взаємозамінними у всьому документі.

Про автора: Ця стаття написана кількома членами команди STH - Гаятрі Субраманіам та Сваті С.

Gayathri - це МСП із тестуванням програмного забезпечення, що має понад 2 десятиліття досвіду в області тестування програмного забезпечення, і впродовж кількох проектів широко застосувала підхід „Тестування на основі ризику” в рамках тестової індустріалізації та зрозуміла переваги оптимізації тестових ресурсів та тестування якості.

Тестування на основі ризику було для вас складним завданням? Чи є у вас якісь цікаві факти, які можна додати до нашого підручника? Не соромтеся висловлювати свої думки в розділі коментарів нижче !!

=> Завітайте сюди, щоб отримати повну серію навчальних програм з плану випробувань

Рекомендована література

• Постійний процес інтеграції: як поліпшити якість програмного забезпечення та зменшити ризик
• Аналіз режимів відмов та ефектів (FMEA) - Як проаналізувати ризики для кращої якості програмного забезпечення та задоволених клієнтів!
• Остаточний посібник з тестування на основі ризиків: управління ризиками при тестуванні програмного забезпечення
• 10 найкращих засобів та методів оцінки та управління ризиками
• Види ризиків у програмних проектах
• Деякі цікаві питання для тестування програмного забезпечення
• Вибір тестування програмного забезпечення як вашу кар’єру
• Відгуки та відгуки про курси тестування програмного забезпечення