Аналіз режимів відмов та ефектів (FMEA) - Як проаналізувати ризики для кращої якості програмного забезпечення та задоволених клієнтів!

failure mode effects analysis how analyze risks

Аналіз режиму несправності та ефектів (FMEA) є методом управління ризиками.

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

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

• Аналіз режиму несправності та ефектів
• Що таке аналіз ризику?
• Приклад аналізу ефекту режиму відмови
• FMEA та ступінь випробувань
• Висновок
• Рекомендована література

Аналіз режиму несправності та ефектів

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

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

Передумови

АНАЛІЗ РИЗИКІВ є найважливішим аспектом Тестовий менеджмент . Тоді виникає питання - Що таке аналіз ризику? І чому це важливо? Щоб зрозуміти це, життєво важливо зрозуміти - що таке РИЗИК?

Див. Також => Види ризиків у програмних проектах.

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

Ризик має 2 атрибути:

• Імовірність
• Вплив

Ймовірність означає шанс виникнення певного ризику, а вплив означає ступінь ефекту ризику.

Що таке аналіз ризику?

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

• Що перевірити в першу чергу?
• Що більше тестувати?
• Що не тестувати (Цього разу)?

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

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

F нездужання М ода І Є ефекти ДО наліз (FMEA): це офіційний метод проведення аналізу ризиків. У наступних розділах я буду обговорювати докладніше FMEA і спробуйте це докласти на прикладі.

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

Опис

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

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

• Серйозність невдачі (S)
• Пріоритет невдачі (P)
• Ймовірність відмови (L)

Кожен із цих атрибутів ми розміщуємо в шкалі, показаній нижче:

Шкала важкості:

Шкала пріоритету:

Шкала ймовірності:

Всі ці три атрибути (серйозність, пріоритет і ймовірність) вимірюються окремо в масштабі, а потім множаться, щоб отримати Номер пріоритету ризику (RPN).

тобто Номер пріоритету ризику ( RPN) = S * P * L

Виходячи з цього значення RPN, ми визначаємо ступінь тестування. Меншим є RPN, вищим є ризик.

Спробуємо це зрозуміти на прикладі:

як запустити файл jar у Windows 10

Приклад аналізу ефекту режиму відмови

(Це гіпотетичний приклад лише для цілей розуміння. Фактична реалізація та особливості можуть відрізнятися)

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

• Функція 1: Зняти
• Функція 2: Депозит
• Функція 3: Позика на житло
• Функція 4: Фіксовані депозити.

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

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

• Складна бізнес-логіка у разі розрахунку процентної ставки за житловим кредитом.
• Система не працює на 200 одночасних користувачів.
• Система не справляється з документами, розмір яких перевищує 6 МБ.

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

Серйозність:

Пріоритет:

Імовірність:

Тепер давайте об’єднаємо всі ці атрибути:

Тепер давайте обчислимо номер пріоритету ризику (RPN = серйозність * пріоритет * ймовірність)

Тепер головне: Нижче значення RPN - вищий ризик.

Отже, для цього конкретного прикладу, Функція 1 (Складна бізнес-логіка у разі обчислення процентної ставки за іпотечним кредитом) має найвищий ризик, а функція 2 (Система не працює при 200 одночасних користувачів) має найнижчий ризик.

Як використовувати це для отримання тестових випадків?

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

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

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

Особливість 3 є Особливість ПОМІРНИХ РИЗИКІВ , тому базуйте свої тестові кейси, щоб охопити всі основні та залежні функції. Напишіть кілька тестів BVA, щоб також перевірити кілька негативних сценаріїв. Обсяг тестових випадків повинен знаходитись між факторами високого та низького ризику. Якщо потрібно, включіть також кілька нефункціональних тестів.

FMEA та ступінь випробувань

На основі значення RPN ми визначаємо ступінь або ступінь тестування, яке потрібно зробити.

Зазвичай, якщо:

• RPN становить від 1 до 10, ми проводимо розширене тестування (покриття та вимкнення функції / модуля)
• RPN становить від 11 до 30, ми проводимо збалансоване тестування (охоплюючи всі основні функціональні можливості функції / модуля)
• RPN між 31-70, ми проводимо тестування можливостей (охоплюючи основні функціональні можливості функції / модуля)
• RPN більше 70 - Немає тестування або, якщо це дозволяє час, лише повідомлення про аномалії.

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

Ресурси: Завантажити Програмне забезпечення FMEA і Шаблон FMEA .

Висновок

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

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

Про автора: Це гостьова стаття Шилпи Чаттерджі Рой. Вона працює у галузі тестування програмного забезпечення протягом останніх 8,5 років у різних сферах.

Якщо ви використовували цю техніку, будь ласка, сміливо коментуйте свій досвід нижче.

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

• Види ризиків у програмних проектах
• Що таке атрибути якості?
• Перевірте свої можливості аналізу та сили мислення - Вправи для тестування програмного забезпечення (Частина 2)
• Взаєморозуміння при тестуванні: ключ до забезпечення якісного програмного забезпечення
• Що таке забезпечення якості програмного забезпечення (SQA): Посібник для початківців
• Постійний процес інтеграції: як поліпшити якість програмного забезпечення та зменшити ризик
• Різниця між забезпеченням якості та контролем якості (QA проти QC)
• 8 найкращих програм для управління журналами | Огляд інструменту аналізу журналів 2021