Тестване, базирано на риска: подход, матрица, процес и примери

Тестване, базирано на риска

Тестване, базирано на риска (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 висока) от всеки риск се оценяват, като двата регистъра саtracts по-долу показват.

• Изчислява се тестовата експозиция.
• Тестерът анализира всеки риск и оценява дали рискът е тестваем или не.
• Целите на теста са дефинирани за проверимите рискове.
• Тестерът определя тестовата дейност, която трябва да се извърши по планиран начин, за да се постигне целта на теста (статични прегледи, инспекции, системни тестове, интеграционни тестове, тестове за приемане, 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цар.
• Ранното откриване на потенциални проблемни области позволява предприемането на ефективни превантивни мерки.
• Непрекъснатото наблюдение и оценка на риска през целия жизнен цикъл на проекта помага за идентифицирането и разрешаването на рисковете, както и за справянето с проблемите, които биха могли да застрашат постигането на общите цели на проекта.

Въпроси и Отговори