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

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

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

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

Ризики можуть бути позитивними або негативними.

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

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

Коли впроваджувати тестування на основі ризику

Тестування на основі ризику може бути впроваджено в

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

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

Давайте тепер розглянемо етапи процесу управління ризиками.

Ідентифікація ризиків

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

Реєстр ризиків – це електронна таблиця, яка містить перелік виявлених ризиків, потенційних відповідей та першопричин. Вона використовується для моніторингу та track ризики (як загрози, так і можливості) протягом усього життєвого циклу проекту. Стратегії реагування на ризики можна використовувати для управління позитивними та негативними ризиками.

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

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

Аналіз ризиків (включає кількісний та якісний аналіз)

Після визначення списку потенційних ризиків наступним кроком є ​​їх аналіз та фільтрація ризиків за значущістю. Одним із методів якісного аналізу ризиків є Матриця ризиків (розглянута в наступному розділі). Цей метод використовується для визначення ймовірності та впливу ризику.

Планування реагування на ризики

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

Власник ризику відповідає за визначення варіантів зменшення ймовірності та впливу призначених ризиків.

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

Непередбачені ризики

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

Моніторинг і контроль ризиків

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

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

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

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

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

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

1. Проаналізуйте вимоги.
   • Документи (SRS, FRS, варіанти використання) перевіряються. Ця діяльність виконується для пошуку та усунення помилок і неоднозначностей.
   • Затвердження вимог – це один із методів зниження ризиків, що дозволяє уникнути внесення пізніх змін до проекту. Будь-яка зміна вимоги після того, як документ було узгоджено з базовим етапом, передбачає процес контролю змін та подальші затвердження.
2. Оцінка ризиків шляхом розрахунку ймовірності та впливу кожної вимоги на проект, враховуючи визначені критерії, такі як вартість, графік, ресурси, обсяг, технічні характеристики, безпека, надійність та складність.
   • Визначте ймовірність невдачі та зони високого ризику. Це можна зробити за допомогою матриці оцінки ризиків.
   • Використовуйте реєстр ризиків для переліку виявлених ризиків. Оновлюйте, контролюйте та tracперіодично оцінювати ризики через рівні проміжки часу.
   • На цьому етапі потрібно зробити профіль ризику, щоб зрозуміти рівень ризику та рівень толерантності до ризику.
3. Визначте пріоритетність вимог на основі рейтингу.
   • Визначено процес тестування на основі ризику.
   • Висококритичні та середні ризики можна враховувати для планування пом'якшення наслідків, впровадження та моніторингу прогресу. Низькі ризики можна тримати у списку спостереження.
   • Оцінка якості даних про ризики виконується для аналізу якості даних.
4. Сплануйте та визначте тести відповідно до рейтингу.
   • Застосовуйте відповідний підхід до тестування та методи розробки тестів, щоб спочатку перевіряти елементи з найвищим рівнем ризику. Елементи з високим рівнем ризику може перевірити спеціаліст із добрими знаннями та досвідом у предметній області.
   • Можна використовувати різні методи розробки тестів, наприклад, таблиця рішень методику на тестових матеріалах високого ризику, і лише розділення еквівалентності для тестових елементів з низьким рівнем ризику.
   • Тестові випадки також розроблені для охоплення кількох функцій та комплексних бізнес-сценаріїв.
   • Підготуйте тестові дані, умови тестування та тестовий стенд.
5. Revпереглянути тестову документацію — плани тестування, стратегія тестування, тестові випадки, звіти про тестування та будь-які інші документи, створені командою тестування.
   • Експертна перевірка є важливим кроком у виявленні дефектів і зниженні ризику.
6. Виконайте пробні запуски та перевірку якості результатів.
   • Тестові випадки виконуються відповідно до пріоритету елемента ризику.
   • Підтримувати tracвідповідність між елементами ризику, тестами, що їх охоплюють, результатами цих тестів та дефектами, виявленими під час тестування. Усі стратегії тестування, виконані належним чином, зменшать ризики якості.
   • Тестування на основі ризику можна використовувати на кожному рівні тестування — компонент, інтеграція, система та приймальні випробування.
   • На системному рівні нам потрібно зосередитися на тому, що є найважливішим у застосунку. Це можна визначити, розглянувши видимість функцій, частоту використання та можливі витрати на вихід з ладу.
   • Оцінка критеріїв виходу: усі сфери високого ризику повністю перевірені, залишилися лише незначні залишкові ризики.
7. Повідомте про результати тестів на основі ризику та проаналізуйте показники.
   • Переоцініть існуючі події ризику та нові події ризику на основі ключових показників ризику.
   • Оновіть реєстр ризиків.
   • Плани дій у надзвичайних ситуаціях працюють як резервний або надзвичайний план для випадків високого ризику.
   • Для усунення дефектів використовуються аналіз дефектів та їх профілактика.
   • Повторне тестування та Регресійне тестування перевірити виправлення дефектів на основі попередньо розрахованого аналізу ризиків, а зони з високим рівнем ризику повинні бути охоплені найбільш інтенсивно.
   • Автоматизоване тестування на основі ризиків, якщо це можливо.
   • Розрахунок залишкового ризику.
8. Моніторинг та контроль ризиків.
   • Критерії виходу або критерії завершення можуть бути визначені окремо для різних рівнів ризику. Усі ключові ризики були враховані за допомогою відповідних дій або планів дій у надзвичайних ситуаціях, а рівень ризику знаходиться на рівні, узгодженому як прийнятний для проекту, або нижче нього.
   • Переоцінка профілювання ризиків та відгуки клієнтів.

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

1. Тест технічної системи — Це називається тестуванням середовища та тестуванням інтеграції. Тестування середовища включає тестування в середовищах розробки, тестування та виробництва.
2. Тест функціональної системи — Тестування всіх функцій, можливостей, програм та модулів. Мета цього тестування — оцінити, чи відповідає система заданим вимогам.
3. Тест нефункціональної системи — Тестування нефункціональних вимог: продуктивність, навантажувальні тести, стрес-тести, тести конфігурації, тести безпеки, резервне копіювання та відновлення процедури та документація (системна, експлуатаційна та монтажна документація).

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

Системне тестування включає як функціональні, так і нефункціональні тести.

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

Як проводити тестування на основі ризику: повний процес

У цьому розділі розглядається процес тестування на основі ризику, який проходить у п'ять етапів.

1. Ідентифікація ризиків
2. Аналіз ризиків
3. Реакція на ризик
4. Тест Scoping
5. Визначення процесу тестування

П'ять фаз взаємопов'язані одна з одною, як показано нижче.

1. У цьому процесі ризики виявляються та класифікуються, готується проект реєстру ризиків та проводиться сортування ризиків для виявлення значних ризиків.
2. Реагування на ризики включає формулювання цілей тестування на основі ризиків та вибір відповідних методів, щоб тестова діяльність або метод тестування відповідали цим цілям тестування.
3. Для розрахунку оцінки ефективності тестування враховуються задокументовані залежності, вимоги, вартість та час, необхідний для тестування програмного забезпечення.
4. Результати тестуping – це діяльність з огляду, яка вимагає участі всіх зацікавлених сторін та технічного персоналу. Важливо дотримуватися узгодженого обсягу ризиків. Ці ризики необхідно враховувати шляхом тестування, і всі учасники повинні погодитися з покладеними на них обов'язками та бюджетом, виділеним на цю діяльність.
5. Після того, як обсяг тестування буде остаточно визначено, цілі тестування, припущення та залежності для кожного етапу тестування повинні бути складені у стандартному форматі.

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

Розглянемо функціональні вимоги F1, F2 та F3, а також нефункціональні вимоги N1 та N2.

F1 — Функціональна вимога, R1 — Ризик, пов'язаний з F1

• Мета тестування 1 — Продемонструвати за допомогою тесту, що очікувані функції та можливості системи працюють правильно, а також що ризик R1 можна вирішити за допомогою функціонального тестування.
• Тестування — тестування сторінок браузера проводиться для виконання важливих завдань користувача та перевірки того, що R1 (ризик, пов’язаний з F1) можна вирішити в різних сценаріях.

F2 — Функціональна вимога, R2 — Ризик, пов'язаний з F2

• Мета тестування 2 — Продемонструвати за допомогою тесту, що очікувані функції та можливості системи працюють правильно, а також що ризик R2 можна вирішити за допомогою функціонального тестування.
• Тестування — тестування сторінок браузера проводиться для виконання важливих завдань користувача та перевірки того, чи можна вирішити проблему R2 у різних сценаріях.

F3 — Функціональна вимога, R3 — Ризик, пов'язаний з F3

• Мета тестування 3 — Продемонструвати за допомогою тесту, що очікувані функції та можливості системи працюють правильно, а також що ризик R3 можна вирішити за допомогою функціонального тестування.
• Тестування — тестування сторінок браузера проводиться для виконання важливих завдань користувача та перевірки того, чи можна вирішити проблему R3 у різних сценаріях.

N1 — Нефункціональна вимога, NR1 — Ризик, пов'язаний з N1

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

N2 — Нефункціональна вимога, NR2 — Ризик, пов'язаний з N2

• Мета тестування N2 — продемонструвати за допомогою тесту, що операційні характеристики системи працюють правильно, і що ризик NR2 можна вирішити за допомогою нефункціонального тестування.
• Тест — Тестування безпеки — це метод, що використовується для перевірки безпеки або вразливості програми до атак, наявності витоку інформації та можливості усунення NR2 за допомогою тестування безпеки.

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

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

• Підготуйте реєстр ризиків. У ньому записуються ризики, отримані на основі загального переліку ризиків, існуючого контрольного списку та результатів мозкового штурму.
• Включіть ризики, пов'язані з функціональними та нефункціональними вимогами системи (зручність використання, безпека, продуктивність).
• Кожному ризику присвоюється унікальний ідентифікатор.

У стовпцях 1 та 2 цього реєстру містяться ідентифікатор та опис ризику. Решта стовпців описані нижче.

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

• Обчислюється тестова експозиція.
• Тестер аналізує кожен ризик та оцінює, чи можна його перевірити.
• Цілі тестування визначені для тестованих ризиків.
• Тестувальник визначає тестову діяльність, яку слід виконувати запланованим чином для досягнення мети тестування (статичні огляди, інспекції, системні тести, інтеграційні тести, приймальні тести, перевірка HTML, тестування локалізації тощо).
• Ці тестові дії можна класифікувати на етапи (тестування компонентів або одиничне тестування, інтеграційне тестування, системне тестування, приймальне тестування).
• Іноді ризик може бути врахований на кількох етапах тестування.
• Визначте залежності та припущення (наявність навичок, інструментів, тестових середовищ та ресурсів).
• Ефективність тестування обчислюється. Ефективність тестування пов'язана з рівнем впевненості тестувальника в тому, що ризик буде остаточно усунено за допомогою тестування. Оцінка ефективності тестування – це число від одного до п'яти (5 = висока впевненість, 1 = низька впевненість).
• Оцініть зусилля, необхідний час та вартість підготовки та проведення цих тестів.

Наступні два колишніtracts показують решту стовпців реєстру та оцінку ефективності тесту.

• Розраховується число пріоритету тесту. Воно є добутком балів ймовірності, наслідків та ефективності тесту.
• 125 (максимум) — дуже серйозний ризик, який можна виявити за допомогою тестування.
• 1 (мінімум) — дуже низький ризик, який не буде виявлено за допомогою тестування.
• Залежно від номера пріоритету тесту, важливість тесту можна класифікувати як Висока (червоний), Середня (жовтий) та Низька (зелений). Першими тестуються елементи з найвищим рівнем ризику.
• Розподіліть тестові завдання за етапами тестування. Призначте групу, яка виконуватиме тестування для кожної мети на різних етапах тестування (модульне тестування, інтеграційне тестування, системне тестування, приймальне тестування).

Розподіл між етапами тестування показано нижче.

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

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

Загальні цілі тестування — ці загальні цілі застосовні до багатьох проектів та застосувань.

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

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

• Тестування компонентів
• Інтеграційне тестування
• Тестування системи
• Тестування прийняття

Розглянемо етап тестування системи.

1. G4 та G5 демонструють, що система відповідає функціональним вимогам (F1, F2, F3) та нефункціональним вимогам (N1, N2).
2. Продемонструйте за допомогою тестів, що очікувані функції та можливості системи працюють правильно, а також що ризики, пов'язані з F1, F2 та F3, можна вирішити за допомогою функціонального тестування.
3. Продемонструйте за допомогою тестів, що експлуатаційні характеристики системи працюють правильно, а ризики, пов'язані з N1 та N2, можна вирішити за допомогою нефункціонального тестування.
4. Залежно від номера пріоритету тесту, важливість тесту можна класифікувати як Високу (червоний), Середню (жовтий) та Низьку (зелений).

Пріоритезація та матриця оцінки ризиків

Матриця оцінки ризиків – це матриця ймовірності та впливу. Вона надає команді проекту швидке уявлення про ризики та пріоритетність, з якою кожен із цих ризиків необхідно враховувати.

Risk rating = Probability x Severity

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

Це можна класифікувати як Часте (A), Ймовірне (B), Епізодичне (C), Віддалене (D), Малоймовірне (E) та Виключене (F).

• частий — Очікується, що це трапляється кілька разів у більшості випадків (91–100%).
• Ймовірно — Ймовірно, трапляється кілька разів у більшості випадків (61–90%).
• Випадкові — Можливо, колись це станеться (41 – 60%).
• віддалений — Малоймовірно, хоча іноді може статися (11–40%).
• Неймовірний — Може траплятися за рідкісних та виняткових обставин (0–10%).
• Ви Були — Неможливо відбутися (0%).

Серйозність – це ступінь впливу пошкоджень або втрат, спричинених невизначеною подією. Вона оцінюється за шкалою від 1 до 4 і може бути класифікована як Катастрофічна = 1, Критична = 2, Гранична = 3 та Незначна = 4.

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

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

• Серйозний
• Високий
• Medium
• низький

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

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

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

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

Загальний контрольний список для тестування на основі ризику

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

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

Звітування про результати тестування на основі ризиків і показники

1. Підготовка звіту про випробування. Звітування про стан тестування полягає в ефективному донесенні результатів тестування до зацікавлених сторін проекту, наданні чіткого розуміння та демонстрації порівняння результатів тестування з цілями тестування.
   • Кількість запланованих тестових випадків порівняно з виконаними.
   • Кількість пройдених або не пройдених тестових випадків.
   • Кількість виявлених дефектів, їх статус та серйозність.
   • Кількість критичних дефектів все ще не виявлена.
   • Простої в роботі середовища, якщо такі є.
   • Приголомшливі моменти, якщо такі є.
   • Звіт про зведення випробувань та покриття тесту повідомити.
2. Підготовка метрик. Метрика — це комбінація двох або більше показників, що використовуються для порівняння процесів, проектів та продуктів програмного забезпечення.
   • Зусилля та варіації графіка.
   • Продуктивність підготовки тестових випадків.
   • Покриття тестового дизайну.
   • Продуктивність виконання тестових випадків.
   • Ефективність виявлення ризиків, %.
   • Ефективність зменшення ризиків у відсотках.
   • Ефективність тесту (%)
   • Покриття виконання тестів.
   • Продуктивність виконання тестів.
   • Витік дефектів %.
   • Ефективність виявлення дефектів та щільність дефектів.
   • Індекс стабільності вимог.
   • Вартість якості.

Потім ці заходи аналізуються з урахуванням ризиків:

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

Оцінка внутрішнього ризику проти оцінки залишкового ризику

Виявлення та аналіз ризиків також повинні включати притаманні ризики, залишкові ризики, вторинні ризики та повторювані ризики.

• Вроджений ризик: Ризики, які були виявлені або вже були присутні в системі до впровадження заходів контролю та реагування. Властиві ризики також відомі як валові ризики.
• Залишковий ризик: Ризики, що залишаються після впровадження заходів контролю та реагування. Залишкові ризики відомі як чисті ризики.
• Вторинний ризик: Новий ризик, спричинений впровадженням плану реагування на ризики.
• Повторний ризик: Ймовірність того, що початкові ризики виникнуть знову.

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

Профілі ризиків і відгуки клієнтів

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

1. Необхідний ризик це рівень ризику, який клієнт повинен взяти на себе, щоб отримати задовільний дохід.
2. Потенційність ризику – це рівень фінансового ризику, який клієнт може собі дозволити.
3. Толерантність до ризику – це рівень ризику, який клієнт хотів би взяти на себе.

Відгуки клієнтів: збирати відгуки та відгуки клієнтів для покращення бізнесу, продукту, послуг та досвіду.

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

Переваги тестування на основі ризику наведено нижче.

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

Поширені запитання