Най-доброто ръководство за тестване на риск: Управление на риска при тестване на софтуер

ultimate guide risk based testing

Най-доброто ръководство за тестване на риска, управление на риска и неговия подход с примери:

Какво е тестване на базата на риска?

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

=> Щракнете тук за пълна серия уроци за план за тестване

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

С други думи, подходът RBT е да гарантира, че тестването се извършва по такъв начин, че дори да е потребител намира грешка в производството, което не му пречи да използва софтуера или не влияе сериозно на бизнеса.

RBT се провежда на базата на продуктови рискове. RBT трябва да разбере предварително, тъй като какъв е рискът от отказ на дадена характеристика или функционалност в производството и нейното въздействие върху бизнеса по отношение на разходите и други щети, като се използва техника за приоритизиране на тестовите случаи.

Следователно тестовете, базирани на риска, използват принципа на приоритизиране на тестовете на функциите, модулите и функционалностите на продукт или софтуер. Приоритизирането се основава на риска от вероятността от отказ на тази функция или функционалност в производството и нейното въздействие върху клиентите.

Какво ще научите:

• Тестване на базата на риска и неговото значение за Agile & DevOps
  • Подход за тестване, основан на риска
    • Кога използваме подхода RBT?
    • Пример за RBT подход
  • Начини за извършване на анализ на риска
  • Процедура за анализ на риска
  • Методология за анализ на риска
    • Стъпка # 1) Използване на 3X3 мрежа
    • Стъпка 2) Вероятност и въздействие на отказа
    • Стъпка # 3) Тестване на приоритетна мрежа
    • Стъпка # 4) Подробности за тестването
  • Как RBT е подходящ за Agile и DevOps?
  • Предимства на подхода, базиран на риска
• Управление на риска по време на планирането на теста
  • Процес на управление на риска
    • # 1) Идентифициране на риска
    • # 2) Оценка на риска / Анализ на въздействието на риска
    • # 3) Намаляване на риска
  • Заключение
• Управление на риска във фаза на изпълнение на теста (с пример)
  • Управление на риска - с фокус върху AUT
  • Как се провежда тестването на рискови бази?
  • Заключение
  • Препоръчително четене

Тестване на базата на риска и неговото значение за Agile & DevOps

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

Това от своя страна може да развали целта на целия продукт без друга възможност, а само да го изтегли от пазара. И това е значението и необходимостта от „Тестване на качеството“.

С бързия растеж на технологиите софтуерът се хоства в облака, поддържащ множество операционни системи, множество платформи, сложни ИТ инфраструктури и т.н., крайните потребители стават все по-придирчиви относно функциите, опциите и те никога не правят компромиси за удовлетворението на клиентите .

В днешно време „Качеството“ се превръща в решаващ фактор за доставката на софтуер, където се случват непрекъснати подобрения, за да се подобри качеството, за да бъдат клиентите доволни.

Често забелязваме, че е често срещан проблем за почти всички тестери да бъдат под огромен натиск, че техният прозорец за тестване е натиснат и обикновено компилацията им се предава за тестване в последния момент. Няма достатъчно време и ресурси, за да изпълнят всички тестове, които са проектирали, а покритието за автоматизация не винаги е 100% и има свои собствени предизвикателства.

Срокът за доставка не може да бъде пропуснат и същевременно качеството не може да бъде нарушено. Какъвто и да е план Б, добавянето на допълнителни тестови ресурси чрез изтегляне от останалите екипи не работи, план В, спрете да правите всички останали дейности и насочете усилията само към това, всъщност не помага. Въпреки това много добавяне на тестови ресурси в крайна сметка не работи.

Няма друга възможност, освен просто да провеждате ограничени и важни тестове в рамките на наличното време и ресурси.

И така, как да решим кой тест е важен на този етап? Каквото и даден тестер смята за важно, може да не е наистина важно за клиентите. От чия перспектива се решава значението на функцията или функционалността? Кой ще реши кои са важните тестове? И много други въпроси продължават да възникват.

За да се отговори на всички тези въпроси и да се справи ефективно с горната ситуация, беше извикан подход за тестване „Тестване на базата на риска“ , наречено накратко „RBT“ , възникна, когато екипът ясно е планирал и идентифицирал тестовите сценарии въз основа на критериите „Риск на проекта“.

Въпреки че екипът на QA има ясна картина на важните тестове, RBT е доказан метод за идентифициране на ключовите и важни тестове от гледна точка на клиента и бизнеса чрез 'Анализ на риска' процедура .

Така че, в сравнение с традиционния начин за просто идентифициране на дефектите в софтуера, QA подходът и целта се променят с времето поради промяната в технологията, увеличаването на конкуренцията на пазара за пускане на качествен софтуер, въвеждане на „Автоматизирайте всичко“ и като цяло въвеждането на Agile и DevOps практиката за доставяне на софтуера за период от няколко часа.

Следователно, настоящата тенденция на „Принцип на тестване“ е не просто „идентифициране на дефектите“, но също така,

# 1) Фокусирайте се върху областта на продукта, където има силно въздействие върху бизнеса поради провал или голяма вероятност за отказ в производството.

# две) Фокусирайки се върху идентифициране на дефектите рано и позволява на екип да го поправи възможно най-рано и по този начин позволява на софтуера / продукта или характеристиката да ‘Fail Fast’.

# 3) Най-важният аспект на услугата на екипа за осигуряване на качеството сега е да се съсредоточим върху клиента при привличането на стойност за клиента чрез увеличаване на фокуса върху „Преживяване от край до край на клиента“.

Подход за тестване, основан на риска

Винаги прилича на подготовка за изпит, че не може да се каже, че тестването е достатъчно и няма повече дефекти в софтуера, дори ако те проектират и изпълняват достатъчно на брой тестове.

Има момент, в който стабилността на софтуера няма да бъде двойно гарантирана чрез увеличаване на броя на тестовите случаи. Към този момент не само да се съсредоточим върху броя на тестовете, но и върху това какво всъщност клиентът очаква от изданието.

Следователно е от съществено значение да се постигне баланс при оптимизирането на тестването, за да се постигне максимална полза с разумното усилие на тестването. И това е по-важно, когато сроковете за тестване са много ограничени и няма достатъчно ресурси за провеждане на достатъчно тестване.

По този начин в този случай подходът RBT играе ключова роля за оптимизиране на усилията за осигуряване на качеството и максимизиране на ползата от тестването с минимален бизнес риск.

Така че, ако се съсредоточим върху горния аспект, работата на QA ще бъде значително облекчена. Не е нужно да изгарят почивните си дни в офиса, като непрекъснато тестват софтуера и се притесняват за всички дефекти на S4 (сериозност 4) и P4 (приоритет 4), които излизат от тестването.

Е, 4 се счита за най-нисък приоритет и тежест на дефектите при тестване. Те могат по-добре да инвестират времето си в други полезни аспекти на проекта.

За да обобщим основните двигатели на подхода „Тестване въз основа на риска“:

• За да се даде възможност за тестване „какво искат клиентите“ от бизнес гледна точка.
• За да спазите графика с очакваното качество.
• За оптимизиране на усилията за осигуряване на качеството.

Кога използваме подхода RBT?

Това се използва при следните сценарии:

• RBT подходът може да се използва винаги, когато има ограничение или ограничение във времето, разходите и ресурсите на даден проект и винаги, когато има нужда от оптимизиране на ресурсите.
• RBT подходът се използва, когато програмата е по-сложна и адаптира нови технологии и следователно включва много предизвикателства.
• Когато програмата е проект за научноизследователска и развойна дейност и е от първи тип и в проекта има редица неизвестни и рискове.

Пример за RBT подход

Няколко подхода, базирани на риска, се използват в ИТ индустрията за преодоляване на рисковете, пред които е изправено производството и неговото въздействие.

Даден по-долу е един такъв подход:

Този подход на RBT включва идентифициране на „жизненоважните функционалности или ключови характеристики“ на продукта и оценка на рисковете, на които всяка от тези функционалности е изложена в производството, и прилагане на подходящи мерки за намаляване на риска за намаляване или намаляване на риска.

Следователно подходът RBT включва тестване на функционалностите, които имат вероятност за отказ и най-голямо въздействие върху бизнеса. Видовете откази могат да бъдат оперативни или бизнес, технически, външни и т.н.

Начини за извършване на анализ на риска

Няма стандартен процес или шаблон, дефинирани като такива за извършване на анализ на риска при тестване на софтуера за всяка характеристика на даден продукт. Различни организации използват свой собствен подход към методите за анализ на риска.

Анализът на риска може да се извърши върху различни елементи на проекта, за да се идентифицират рисковете и да се приложи RBT подход за анализ. Тези елементи включват,

• Характеристика
• Функционалности
• Потребителски истории
• Изисквания
• Случаи на употреба
• Тестови случаи

В този случай нека се съсредоточим само върху тестови случаи, за да разберем прилагането на подхода, базиран на риска.

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

Анализът на риска включва участието на съответните заинтересовани страни от програмата както от „ Технически екип и бизнес екип “ , което включва собственик на продукта, продуктови мениджъри, бизнес анализатори, архитекти, тестери и представители на клиенти.

Ще бъдат организирани сесии за мозъчен штурм, включващи тези заинтересовани страни, за да се проведе дискусията, за да се идентифицира важността на всяка характеристика на продукта и да се приоритизират въз основа на риска от отказ и въздействието му върху крайните потребители в производството.

Различни „проектни документи“ като Документи за изисквания, Документи за техническа спецификация, Документи за архитектура и дизайн, Документ за бизнес процес, Документ за случай на употреба и др., Ще станат входни данни за мозъчната атака.

Знанията на заинтересованите страни за продукта и съществуващия продукт на пазара също ще бъдат фактор за дискусията.

Малко други източници на данни също могат да включват,

• За събиране на данни за най-използваната функционалност.
• Данни от консултация с експерт по домейн.
• Данни от предишната версия на продукта или подобен продукт на пазара.

По време на мозъчна атака сесия, се идентифицират рисковете, свързани с всяка от тези характеристики. Видовете рискове могат да бъдат операция, техническа или свързана с бизнеса. Тестовете и сценариите, свързани с тях, се претеглят и стойностите на риска се оценяват въз основа на вероятността от възникване на риска и въздействието на риска.

„Вероятността за възникване на риск“ може да се дължи на:

• Лошо разбиране на характеристиката от екипа за разработка на продукти.
• Неправилна архитектура и дизайн.
• Недостатъчно време за проектиране.
• Некомпетентност на екипа.
• Недостатъчни ресурси - хора, инструменти и технологии.

„Въздействието на риска“ е ефектът от неуспех за потребителите и бизнеса, ако се случи. Въздействието може да бъде,

• Въздействие на разходите, водещо до загуба.
• Бизнес въздействие, водещо до загуба на бизнес или загуба на пазарен дял, съдебни производства, загуба на лиценз.
• Качествено въздействие, водещо до излизане на некачествен или некомпетентен продукт.
• Лош потребителски опит, водещ до недоволство и загуба на клиент.

Фокусната зона за оценка на риска от дадена характеристика или продукт може да бъде,

• Област на бизнес критичност на функционалността.
• Най-използвани функции и важна функционалност.
• Области, предразположени към дефекти
• Функционалност, оказваща въздействие върху безопасността и сигурността.
• Област на комплексния дизайн и архитектура.
• Промени, направени от предишни версии.

Методология за анализ на риска

Нека сега разберем подробно „Методологията за тестване въз основа на риска“.

Подходът за тестване, основан на риска, използва РИСК като критерии на всички тестови фази от тестовия цикъл, т.е. планиране на теста , дизайн на теста, изпълнение на теста, изпълнение на теста и отчитане на тестове. В идеалния случай човек може да проектира многобройни възможни комбинации от тестови сценарии.

Следователно подходът RBT включва класиране на тестовете въз основа на тежестта на рисковете, за да се открие най-дефектната или рискова зона на повреда, което води до силно въздействие върху бизнеса.

Основната цел на анализа на риска е да направи разлика между 'Висока стойност' елементи като характеристики на продукта, функционалности, изисквания, потребителски истории , и тестови случаи, и „ С ниска стойност “ тези и следователно по-късно да се съсредоточите повече върху тестовите случаи „с висока стойност“, като по-малко се фокусирате върху тестовите случаи с „ниска стойност“. Това е началната стъпка от анализа на риска, преди да започне тестването на базата на риска.

Основната задача за категоризиране или групиране на тестови случаи в High Value & Low Value и присвояване на приоритетна стойност на всеки от тези тестови случаи включва следните стъпки:

Стъпка # 1) Използване на 3X3 мрежа

Анализът на риска се извършва с помощта на мрежа 3X3, където всяка функционалност, нефункционалност и свързаните с тях тестови случаи се оценяват от екип от заинтересовани страни за „Вероятностна провала “и„ Въздействие на провала “.

Вероятността за повреда на всяка функционалност в производството обикновено се осъществява от група „Технически експерти“ и се категоризират като „Вероятно да се провали, доста вероятно и малко вероятно“ по вертикалната ос на мрежата.

с какво да отварям xml файлове

По подобен начин „въздействието на неуспеха“ на тези характеристики и функционалности в производството се изпитва от крайния клиент, ако не бъде тестван, се оценява от група от ' Бизнес специалисти “и са категоризирани в категории„ Малки, видими и прекъсващи “по хоризонталната ос на мрежата.

Стъпка 2) Вероятност и въздействие на отказа

Всички тестови случаи са позиционирани в квадрантите на мрежата 3 X 3 въз основа на идентифицираните стойности на вероятност за отказ и въздействие на отказ, които са показани като точки на снимката по-долу.

Очевидно високата вероятност за отказ и голямото въздействие на отказ (прекъсване) са групирани в горния десен ъгъл на мрежата, което е от голямо значение и следователно е установено, че тестовете „Висока стойност“ и „Ниска стойност“ са групирани в долния ляв ъгъл, който е от най-малко или никакво значение за клиента, където тези функции или тестови случаи могат да се обърнат по-малко внимание.

Стъпка # 3) Тестване на приоритетна мрежа

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

И накрая, всички тестови случаи се сортират въз основа на техните приоритетни номера и се вземат за изпълнение в приоритетния ред. Тези с висок приоритет се вземат за изпълнение първо, а тези с нисък приоритет се изпълняват по-късно или се де-обхват.

Стъпка # 4) Подробности за тестването

Следващата стъпка е да се вземе решение за нивото на детайлност на тестване за определения обхват на тестване. Дълбочината на обхвата на тестването може да бъде определена въз основа на горното класиране според таблицата по-долу.

Тестовете с висок приоритет с класиране 1 са тествани „По-задълбочено“ и съответно се разполагат експерти, които да тестват тези характеристики с висока критичност и свързаните с тях тестови случаи. По същия начин тестови случаи с приоритет 2, 3 и 4. Може да се вземе решение за премахване на обхвата на функции 5 и тестове на приоритет 5 въз основа на наличното време и ресурси.

Следователно, подходът на ниво на детайлност на тестване за определяне на приоритетите на характеристиките и тестовите случаи не само помага на тестерите да идентифицират „тестовете с висока стойност“, но и ги насочва да вземат решение относно своето „ниво на детайлност на тестване“ въз основа на тези приоритетни класирания и помага им да извършат по-добро тестване и намалява разходите за тестване чрез процеса на оптимизация.

Как RBT е подходящ за Agile и DevOps?

Сега, след като разберем подхода за тестване въз основа на риска при провеждането на тестването въз основа на приоритизирането на тестовете в зависимост от „риска от отказ“ на дадена функция и нейното „въздействие върху клиента“ в реално време, очевидно човек би поставил въпроса за уместността на подхода, базиран на риска, в Agile и DevOps практиките.

„Автоматизирай всичко“, „Тествай всичко“, „Тествай непрекъснато“, „Тествай многократно“ са ключовите концепции на тези практики.

Всеки път, когато има промяна в кода или има издание, всички проектирани тестове се изпълняват чрез автоматизираното Непрекъсната интеграция (CI) / Непрекъсната доставка (CD) бързо и многократно, независимо от тяхното определяне на приоритетите.

Тогава каква е връзката между RBT и DevOps? Къде би се вместил RBT и би станал подходящ за Agile и DevOps ???

# 1) Да, както казах по-рано, не е, че всяка индустрия и всеки продукт имат 100% покритие за автоматизация за своите тестови изпълнения. Така че, ако изобщо екипът трябва да направи избор на приоритет за изпълнение на теста от избора на ръчни тестови случаи и би искал да спести енергията и усилията на тестовите ресурси за други дейности, тогава RBT е най-добрият избор.

Подходът, основан на риска, също е по-добър залог за провеждане на автоматизирани тестове с висок приоритет и тестване най-рано.

# две) QA екипът може да възприеме RBT подхода по-ефективно по време на Анализ на изискванията при анализ на изискванията и предоставяне на предварителен доклад за вероятните рискове от продуктите и характеристиките, така че екипът на програмата да предприеме подходящи действия за смекчаване.

# 3) RBT подходът може ефективно да се използва при проектирането на тестови случаи и сценарии, базирани на висок риск, така че да може да се обърне повече внимание на високорисковите характеристики и функционалности.

# 4) Идентифицирането на областите с „висок риск“ позволява на екипа за QA да съсредоточи усилията си за тестване върху тези области, за да тества „по-задълбочено“ с помощта на „Висококвалифицирани тестери“.

# 5) „Fail Fast“, както всички знаем, е концепцията за „Agile“ и „DevOps“, за които подходът RBT помага да се идентифицират „високорисковите“ области в софтуера, да се идентифицират дефектите рано и да им се позволи да се провалят бързо и да се провалят първо и оставете екипа да го поправи.

# 6) Крайната цел на Agile / DevOps е „фокус върху клиента“ и следователно подходът RBT позволява на QA да се съсредоточи върху изживяването на клиентите, а не само върху откриването на дефекти.

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

Вече разбрахме целта и използването на подхода RBT за анализ на изискванията, проектиране и изпълнение на сценариите за тестване. Има няколко предимства на RBT.

Можем да консолидираме и изброим предимствата на тестването на базата на риска като:

• Помага за по-ефективно и оптимизирано използване на тестовите ресурси.
• Помага за облекчаване на работата по осигуряване на качеството, тестване, проектиране и разработка на тестове и подготовка на тестовете чрез определяне на приоритетите.
• Помага за по-добро управление на ресурсите за осигуряване на качеството, като разпределя ключовите ресурси към области с висок фокус.
• Помага за ефективното използване на ресурсите и отклонява времето и енергията им за по-добри неща в проекта.
• Помага на екипа за осигуряване на качеството при планирането на усилията за тестване въз основа на оценката на риска и идентифицирането на летливи и високорискови зони.
• Това помага на екипа да оптимизира тестовете, които ще се провеждат в зависимост от важността и следователно да премахне обхвата на тестовете с ниска стойност в съгласие със заинтересованите страни.
• Като цяло помага за намаляване на разходите чрез оптимизирани и намалени тестови дейности.
• Подходът RBT позволява на екипа за QA да тества първо рисковите зони и позволява на продукта да се „откаже бързо“ и да се поправи бързо.
• RBT подходът помага за внасянето на яснота в „ Тестово покритие “ и „Обхват на теста“ за цялата група от заинтересовани страни.
• Екипът може да увеличи фокуса си върху зоните с висок риск и да запази по-малко внимание върху зоната с нисък риск.
• RBT позволява на екипа да вземе решение предварително за прилагането на най-ефективния начин за смекчаване на продуктовите рискове.
• RBT помага за избягване на ефекта от неподходящото прилагане на смекчаващи мерки.
• Тестването въз основа на риска позволява на екипа да предприеме подходящи действия или за смекчаване, или за планиране на непредвидени обстоятелства или за позициониране на някакво решение за преодоляване на неуспеха или намаляване на въздействието му, ако рискът възникне в Live.
• RBT помага за минимизиране на остатъчния риск при освобождаването.
• Помага за постигането на „Подобрено качество“ чрез по-евтини дефекти в производството.
• В крайна сметка помага за „Подобрено изживяване на клиентите“ и „Доволен клиент“.

След това ще научим как да управляваме рисковете във фазите Планиране на тестове и Изпълнение на тестове на жизнения цикъл на тестване на софтуера.

Управление на риска по време на планирането на теста

Как да управляваме рисковете по време на фазата на планиране на теста:

Животът е пълен с рискове, софтуерният проект също. Всичко може да се обърка по всяко време. Винаги сме на път да оправим нещата, но какво да кажем да се уверим, че нищо не се обърка и че когато го знаем, какво точно да правим? Въведете управление на риска - това е част от проект за тестване на софтуер, който ни подготвя за предотвратяване, разбиране, намиране и преодоляване на рисковете.

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

Загубата може да бъде каквато и да е - пари, време, усилия или компромис в качеството. Загубата никога не е добра. Без значение колко въртене му даваме, то не е положително и никога няма да бъде. Следователно Управление на риска е неразделна част от софтуерни проекти, за да сме сигурни, че се справяме с рисковете и предотвратяваме / намаляваме загубите.

Тестване на базата на риска : Тъй като ние сме QA общност, нека останем специфични за рисковете и свързания с тях процес изключително в нашия QA свят. Рисковете се оценяват и управляват приблизително в две фази от нашата Жизнен цикъл на софтуерния тест . STLC може да бъде категоризиран на 3 фази - Планиране на тестове, Проектиране на тестове и Изпълнение на тестове.

Процесът на управление на риска се извършва два пъти, по време на:

1. Планиране на тестове
2. Проектиране на тестови случаи (край) или понякога във фаза Тестово изпълнение

Той е задължителен в случай 1, но в случай 2 е по-скоро ситуация на „необходимост“.

Серия статии от две части:

Въпреки че основният процес е същият, видове рискове и двете области са напълно различни. За да им отдадем справедливост поотделно, ще ги обработим по различен начин като поредица от две части.

Този раздел ще бъде за „Управление на риска по време на планирането на теста”.

Процес на управление на риска

Общият процес за управление на риска включва 3 важни етапа:

1. Идентифициране на риска
2. Анализ на въздействието на риска
3. Намаляване на риска

Примери за тестване на рискове и смекчаване на последиците:

# 1) Идентифициране на риска

Както се казва, първата стъпка към решаването на даден проблем е идентифицирането му. Този етап включва съставяне на списък на всичко, което може потенциално да се появи и да наруши нормалния поток от събития.

Основният резултат от тази стъпка е списък на рисковете.

Тази стъпка за тестване, базирана на риска, обикновено се ръководи от ръководителя / мениджъра / представителя на QA. Само водещият обаче няма да може да излезе с целия списък - приносът на целия екип за QA оказва огромно въздействие. Можем да кажем, че това е колективна дейност, ръководена от QA.

Също така, рисковете, които са идентифицирани по време на фазата на планиране на теста, са по-„управленски“ по отношение на ориентацията - това означава, че ще разгледаме всичко, което може да повлияе на графика, усилията, бюджета, промените в инфраструктурата на QA проекта и т.н. Фокусът тук е не AUT, а начина, по който ще продължи QA фазата.

Рискове по време на планирането на теста: Примери за тестване на базата на риска

Следва примерен списък на рисковете, които могат да бъдат изброени по време на фазата на планиране на теста. Моля, обърнете внимание, че 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 дни - обаче; това обикновено не е опция. Тъй като продуктът е обещан да се появи на пазара на определена дата и всякакви забавяния не са полезни за бизнеса.

Затова обикновено екипите за тестване трябва да поемат закъсненията, да компенсират по някакъв начин, да работят с наличното време и да се уверят, че продуктът е тестван добре. Трудна работа, нали?

Тук отново се използва процесът на управление на риска.

• Сега, ако забавянията се очакват преди време преди дори да започне тестването - процесът се извършва във фазата на проектиране на теста.
• Ако закъснения се случват по време на Тест Изпълнение фаза който стартира нормално - процесът се следва по време на фазата на изпълнение на теста.
• Стъпките и методът са еднакви, независимо на какъв етап се случва.

Какъв е процесът?

Управлението на риска се извършва, за да се определи кои области на AUT (Application Test Test) се нуждаят от максимален фокус. Това обикновено са функционалните области (модули или компоненти), които са от решаващо значение за успеха на крайния продукт и са най-податливи на откази.

Прочетете също=> Анализът на режима на отказ и ефекти (FMEA) е техника за управление на риска

Кой го изпълнява?

Тъй като става въпрос за AUT, знанията за него са не само с QA, но и с всички останали екипи - Dev, BA, Client, екипи за управление на проекти и др. Следователно това е колективно усилие, управлявано от екипа за тестване.

Как се провежда тестването на рискови бази?

Етап 1) Идентифициране на риска

Идентифицирайте всички функционални области на AUT. Това просто ще включва съставяне на списък.

Стъпка 2) Оценка на риска

Всички рискове са количествено определени и приоритизирани в тази стъпка. Количественото определяне е просто, присвояване на число на всеки риск в списъка, което ще посочи приоритета, с който трябва да се обърне внимание.

Решават се вероятността за всеки риск (шансът за възникване) и въздействието (размера на загубата, която би причинил, когато този риск се материализира).

Типичният метод е присвояване на рейтинги. Например, Вероятността може да приеме стойности от 1 до 5. 1 като вероятността за възникване е ниска (изобщо не е вероятно да се случи) и 5 ​​е висока (със сигурност ще се случи).

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

Стъпка # 3)

Направете формат на таблица и разпространете до всички представители на екипа - Dev, BA, Client, PM, QA и всеки друг, който има отношение.

Стъпка # 4)

Инструктирайте всеки екип да попълни стойностите въз основа на рейтинга си за вероятност и въздействие.

Тъй като стойностите на вероятността и въздействието са числови, това ще улесни изчисляването на стойността на „фактор на риска“.

Рисков фактор = Вероятност X Въздействие. Колкото по-висок е рисковият фактор, толкова по-сериозен е проблемът.

Пример:

Моля, имайте предвид, че на този етап това е просто резултатът от рейтинга на един отбор. За проект, в който участват 5 различни екипа, екипът за QA ще получи 5 различни таблици.

Стъпка # 5)

Вземете средна стойност на стойностите на рисковия фактор. Например, ако има 5 екипа, за всеки модул добавете всички стойности на рисковия фактор и го разделете на 5. Това са крайните стойности, с които ще се справим. Да речем, това са осреднените рискови фактори:

Колкото повече е рисковият фактор, толкова повече трябва да бъде тестван този модул.

И така, модули 5 и 2 са най-важни за успеха на бизнеса. Споделете резултатите с всички отбори.

Стъпка # 6)

План за намаляване на риска : Сега това е стъпката, която се променя от проект на проект. Установихме, че модулите 5 и 2 са тези, върху които трябва да се концентрира най-много.

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

1. Модули 5 и 2 ще бъдат тествани щателно, като се уверите, че всички тестови случаи, свързани с тях, са тествани. Останалите модули ще бъдат тествани на проучвателна основа.
2. Модули 5 и 2 ще бъдат първо тествани и след това в зависимост от наличното време ще се погрижат за останалите.

След като е съставен план, всички екипи постигат споразумение и го следват, за да тестват продукта, като отчитат рисковия фактор.

Това е!

Няколко важни точки, които трябва да се отбележат:

• Тъй като това е колективна дейност, която отнема мнението на всеки ; шансовете той да бъде точен и ефективен са по-големи.
• Това е не формален метод и не е задължително да е част от всеки QA проект.
• Понякога, дори ако екипът реши да не рисува таблици и да присвоява стойности - а проста сесия за мозъчна атака с всеки присъстващ може да даде на екипа за QA добри напътствия как да процедира.
• The принос на екипа за разработка е много важно, защото те са тези, които създават продукта, така че те ще знаят какво може да работи и какво може да се нуждае от допълнителна проверка. Не забравяйте да бъдете нащрек за това.
• Въпреки че в процеса има няколко стъпки, не им отнема значително време за изпълнението им . Особено, ако всички екипи могат да седят заедно и да работят едновременно.
• Не забравяйте този процес и резултатът от него е само алтернатива . Получаването на толкова време, колкото е планирано за тестване, е най-добрият начин за извършване на QA дейност.

Заключение

Подходът за тестване, основан на риска, ясно показва, че фокусът на тестера не е просто да продължи да изследва дефектите, независимо от тежестта и приоритета. Сега нещата се промениха и тестерите трябва да работят интелигентно и трябва да разберат ясната „Нужда на клиента и желанията на потребителя“.

Те трябва да проучат внимателно продукта и да разберат коя е най-често използваната функция в производството, кой е най-критичният път за генериране на приходи и как да защитят и предпазят клиентите от производствените проблеми и бизнес заплахите.

Следователно подходът RBT ясно обучава 3 тестера, че само тестването на всичко или екстензивното тестване не означава, че тестването е завършено или няма дефекти в продукта. Ефективно тестване в определено време и гарантиране, че критичните и големи бизнес въздействия са обезсилени и това е доста важно за тестера.

По този начин тестовете, базирани на риска, са най-ефективният инструмент за екипа за осигуряване на качеството за насочване на заинтересованите страни по проекта въз основа на рисковете от проекта. Подходът RBT помага на екипа за осигуряване на качеството при непрекъснатото идентифициране на риска и неговото разрешаване, които биха могли да застрашат постигането на общите цели и задачи на проекта, и помага за постигането на крайната цел на QA Group.

P.S. Думите QA и Testing са били взаимозаменяеми в целия документ.

За автора: Тази статия е написана от множество членове на екипа на STH - Gayathri Subrahmanyam и Swati S.

Gayathri е МСП за софтуерни тестове с над 2 десетилетия опит в тестването на софтуер и е възприел широко подхода „Тестване на базата на риска“ като част от тестовата индустриализация в няколко ангажимента и е осъзнал ползата от тестовата оптимизация на ресурсите и тестването на качеството.

Тестването, основано на риск, предизвикателно ли беше за вас? Имате ли интересни факти, които да добавите към нашия урок? Чувствайте се свободни да изразявате мислите си в раздела за коментари по-долу !!

=> Посетете тук за пълна серия уроци за план за тестване

Препоръчително четене

• Непрекъснат процес на интеграция: Как да подобрим качеството на софтуера и да намалим риска
• Анализ на режима на отказ и ефекти (FMEA) - Как да анализираме рисковете за по-добро качество на софтуера и доволни клиенти!
• Най-доброто ръководство за тестване на риск: Управление на риска при тестване на софтуер
• Топ 10 инструменти и техники за оценка и управление на риска
• Видове рискове при софтуерни проекти
• Някои интересни въпроси за интервю за тестване на софтуер
• Изборът на софтуерно тестване като кариера
• Обратна връзка и рецензии на курсове за софтуерно тестване