failure mode effects analysis how analyze risks
Анализ на режима на отказ и ефекти (FMEA) е техника за управление на риска.
Ако се изпълни правилно, това може да бъде чудесно допълнение към най-доброто Процеси за осигуряване на качеството да бъдат следвани. В тази статия нашата цел е да ви запознаем с тази техника за анализ на риска, която в крайна сметка е много полезна за подобряване на качеството на софтуера.
Какво ще научите:
- Анализ на режима на отказ и ефекти
- Какво е анализ на риска?
- Пример за анализ на ефекта в режим на отказ
- FMEA и степен на изпитване
- Заключение
- Препоръчително четене
Анализ на режима на отказ и ефекти
FMEA се използва предимно от висшето ръководство или заинтересованите страни. На практика тестерите получават малко представа за тази техника. Но сега тенденцията се променя и чувствам, че ако тестерите разбират правилно тази концепция, те могат движат техния мисловен процес писане на тестови казуси до едно ниво нагоре чрез използване на тази техника за:
- Разберете целите на заинтересованата страна при тестване на приложението.
- Разберете бизнеса.
- Извлечете сценарии за тестове на високо ниво въз основа на бизнес и управленски интерес.
- Извлечете ефективни тестови случаи, които осигуряват по-добро покритие на рисковите зони.
- Приоритизирайте тестовите случаи.
- Решете какво да тествате и какво да отложим на всяка фаза.
Заден план
АНАЛИЗЪТ НА РИСКОВЕ е ключов аспект на Тестово управление . Тогава възниква въпросът - Какво е анализ на риска? И защо е важно? За да разберем това, е жизненоважно да разберем - какво е РИСК?
Вижте също => Видове рискове при софтуерни проекти.
РИСКЪТ като неговото буквално значение е възможност за отрицателен или нежелан резултат или събитие. Рисковете, ако не се обработват или управляват правилно, могат да доведат до лошо качество, недоволни клиенти и понякога загуба на бизнес.
Рискът има 2 атрибута:
- Вероятност
- Въздействие
Вероятността означава шансът да възникне определен риск, а въздействието означава степента на ефекта на риска.
tar команда в unix с примери
Какво е анализ на риска?
Анализът на риска е механизъм, чрез който идентифицираните потенциални рискове се анализират и проучват задълбочено, за да се открият вероятността и въздействието. Препоръчително е да измерите двата атрибута и въз основа на резултата, който идентифицираме:
- Какво първо да тествате?
- Какво да тествате повече?
- Какво да не се тества (този път)?
Има много методи за извършване на Анализ на риска и те са общо класифицирани в два типа:
- Неформални техники : Те се основават на опит, преценка и интуиция.
- Официални техники : Идентифициране и претегляне на атрибутите на риска.
F неразположение М ода И Е ffects ДА СЕ nalysis (FMEA): Това е официален метод за извършване на анализ на риска. В следващите раздели ще обсъждам повече за FMEA и се опитайте да го доработите с примера.
FMEA е формална техника за извършване на анализ на риска. Това е систематичен и количествен инструмент под формата на Spread Sheet, който помага на членовете да анализират какво може да се обърка. За да направим FMEA, са необходими подходящите хора на масата. Изисква представител от всички сфери на индустрията, включително клиентите.
Описание
FMEA започва и продължава със сесии за мозъчна атака. Участниците трябва да идентифицират всички компоненти, модули, зависимости, ограничения, които могат да се провалят в производствена среда и в крайна сметка да доведат до лошо качество, надеждност и да доведат до загуба на бизнес.
По време на FMEA ние не само идентифицираме степента на загубата, но също така се опитваме да установим причината за тези неуспехи. За измерване на FMEA се изискват 3 атрибута:
- Тежест на неуспеха (S)
- Приоритет на неуспеха (P)
- Вероятност на неуспеха (L)
Поставяме всеки от тези атрибути в скала, показана по-долу:
Скала на тежестта:
Описание | Клас | Мащаб |
Загуба на данни, хардуер или проблеми с безопасността | Спешно | 1 |
Загуба на функционалност без заобикаляне | Високо | две |
Загуба на функционалност с решение | Среден | 3 |
Частична загуба на функционалност | Ниска | 4 |
Козметични или тривиални | Нито един | 5 |
Приоритетна скала:
Описание | Клас | Мащаб |
Пълна загуба на системна стойност | Спешно | 1 |
Неприемлива загуба на системна стойност | Високо | две |
Възможно намаляване на системната стойност | Среден | 3 |
Приемливо намаляване на системната стойност | Ниска | 4 |
Незначително намаляване на системната стойност | Нито един | 5 |
Скала на вероятност:
Описание | Клас | Мащаб |
Определено да задейства всички потребители | Спешно | 1 |
Вероятно ще повлияе на някои потребители | Много високо | две |
Възможно въздействие върху някои потребители | Високо | 3 |
Ограничено въздействие за няколко потребители | Ниска | 4 |
Невъобразимо при реална употреба | Нито един | 5 |
Всички тези три атрибута (сериозност, приоритет и вероятност) се измерват индивидуално в мащаб и след това се умножават, за да се получи Номер на приоритет на риска (RPN).
i.e. Номер на приоритет на риска ( RPN) = S * P * L
Въз основа на тази стойност на RPN определяме степента на тестване. По-малък е RPN, по-висок е рискът.
Нека се опитаме да го разберем с пример:
Пример за анализ на ефекта в режим на отказ
(Това е хипотетичен пример само с цел разбиране. Действителното изпълнение и характеристики могат да варират)
Нека разгледаме прост пример за банково приложение, което има 4 функции.
- Функция 1: Оттегляне
- Функция 2: Депозит
- Функция 3: Заем за дома
- Функция 4: Фиксирани депозити.
Формира се екип за анализ на риска, който се състои от управителя на банката, UAT Тест мениджър (представляващ краен потребител), технически архитект, тестов архитект, мрежов администратор, DBA и мениджър на проекти.
След поредица от мозъчни атаки екипът излезе с следните рискове:
- Сложна бизнес логика в случай на изчисляване на лихвения процент по жилищния заем.
- Системата не работи при 200 едновременни потребители.
- Системата не успява да обработва документи, които са повече от 6 MB.
Сега нека се опитаме да изчислим сериозността, приоритета и вероятността от тези идентифицирани рискове.
Тежест:
Особеност | Клас | Мащаб |
Сложна бизнес логика в случай на изчисляване на лихвения процент по жилищния заем | Много високо | две |
Системата се провали при 200 едновременни потребители | Високо | 3 |
Системата не успява да обработи документи, които са повече от 6 MB | Много високо | две |
Приоритет:
Особеност | Клас | Мащаб |
Сложна бизнес логика в случай на изчисляване на лихвения процент по жилищния заем | Много високо | две |
Системата се провали при 200 едновременни потребители | Високо | 3 |
Системата не успява да обработи документи, които са повече от 6 MB | Високо | 3 |
Вероятност:
Особеност | Клас | Мащаб |
Сложна бизнес логика в случай на изчисляване на лихвения процент по жилищния заем | Високо | 3 |
Системата се провали при 200 едновременни потребители | Високо | 3 |
Системата не успява да обработва документи, които са повече от 6 MB | Ниска | 4 |
Сега нека съберем всички тези атрибути заедно:
страхотни неща, които можете да правите с c ++
Особеност | Тежест | Приоритет | Вероятност |
Сложна бизнес логика в случай на изчисляване на лихвения процент по жилищния заем | две | две | 3 |
Системата не работи при 200 едновременни потребители | 3 | 3 | 3 |
Системата не успява да обработи документи, които са повече от 6 MB | две | 3 | 4 |
Сега нека изчислим номера на приоритета на риска (RPN = Тежест * Приоритет * Вероятност)
Особеност | Тежест | Приоритет | Вероятност | RPN |
Сложна бизнес логика в случай на изчисляване на лихвения процент по жилищния заем | две | две | 3 | 12 |
Системата се провали при 200 едновременни потребители | 3 | 3 | 3 | 27 |
Системата не успява да обработва документи, които са повече от 6 MB | две | 3 | 4 | 24 |
Сега ключът е: По-ниско е 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 изисква време и опит. Желаните резултати могат да бъдат постигнати само чрез равно участие на всички отговорни членове на екипа. Въпреки че тази техника е формална, тя изисква поредица от мозъчни атаки и е също толкова важно да се документират всички идентифицирани рискове.
най-добрият софтуер за управление на задачи за Windows
Тъй като повечето приложения са изключителни, скалата за измерване на параметрите на FMEA (т.е. приоритет, сериозност и вероятност) също зависи от приложението. Ако се направи по подходящ начин, има много предимства пред техниката FMEA. Може да се използва за идентифициране на потенциални рискове и въз основа на този екип може да планира ефективна стратегия за смекчаване.
За автора: Това е статия за гости от Шилпа Чатърджи Рой. Тя работи в областта на тестването на софтуер през последните 8,5 години в различни области.
Ако сте използвали тази техника, не се колебайте да коментирате своя опит по-долу.
Препоръчително четене
- Видове рискове при софтуерни проекти
- Какви са атрибутите за качество?
- Тествайте своите възможности за анализ и сила на мислене - Упражнения за тестване на софтуер (част 2)
- Взаимно разбиране при тестване: Ключ за предоставяне на качествен софтуер
- Какво е осигуряване на качеството на софтуера (SQA): Ръководство за начинаещи
- Непрекъснат процес на интеграция: Как да подобрим качеството на софтуера и да намалим риска
- Разлика между осигуряване на качество и контрол на качеството (QA срещу QC)
- Топ 8 НАЙ-ДОБРИ софтуер за управление на регистри | Преглед на инструмента за анализ на регистрационните файлове 2021