Ghidul final pentru testarea bazată pe risc: gestionarea riscurilor în testarea software-ului

ultimate guide risk based testing

Ghidul final pentru testarea bazată pe risc, gestionarea riscurilor și abordarea acestuia cu exemple:

Ce este testarea bazată pe risc?

Testarea bazată pe risc este de a efectua testări sau de a proiecta și executa scenarii, astfel încât riscurile comerciale de top care vor avea un impact negativ asupra afacerii, astfel cum au fost identificate de client, să fie descoperite în produsul sau caracteristicile lor la începutul ciclului de viață și să fie atenuate prin implementarea măsurilor de atenuare.

=> Faceți clic aici pentru seria completă de programe de testare

Impactul negativ poate include impactul costurilor, clientul nemulțumit, experiența proastă a utilizatorului și chiar în măsura pierderii clienților.

Cu alte cuvinte, abordarea RBT este de a se asigura că, testarea se face în așa fel încât chiar dacă un utilizator găsește o eroare în producție, acest lucru nu îl împiedică să utilizeze software-ul sau nu are impact asupra afacerii într-un mod serios.

RBT efectuează teste pe baza riscurilor produsului. RBT este de a afla cu mult timp în avans, care este riscul eșecului unei anumite caracteristici sau funcționalități în producție și impactul acesteia asupra companiei în termeni de cost și alte daune, utilizând o tehnică de prioritizare pentru cazurile de testare.

Prin urmare, testarea bazată pe risc utilizează principiul prioritizarea testelor a caracteristicilor, modulelor și funcționalităților unui produs sau software. Prioritizarea se bazează pe riscul probabilității de eșec al acelei caracteristici sau funcționalități în producție și impactul acesteia asupra clienților.

Ce veți învăța:

• Testarea bazată pe risc și relevanța sa pentru Agile și DevOps
  • Abordare de testare bazată pe risc
    • Când folosim abordarea RBT?
    • Exemplu de abordare RBT
  • Modalități de a efectua analiza riscurilor
  • Procedura de analiză a riscurilor
  • Metodologia analizei riscurilor
    • Pasul 1) Utilizarea unei grile 3X3
    • Pasul 2) Probabilitatea și impactul eșecului
    • Pasul 3) Testarea grilei prioritare
    • Pasul 4) Detalii de testare
  • Cum este RBT relevant pentru Agile și DevOps?
  • Beneficiile abordării testării bazate pe risc
• Managementul riscului în timpul planificării testelor
  • Procesul de gestionare a riscurilor
    • # 1) Identificarea riscului
    • # 2) Evaluarea riscului / Analiza impactului riscului
    • # 3) Atenuarea riscurilor
  • Concluzie
• Managementul riscului în faza de execuție a testului (cu exemplu)
  • Managementul riscurilor - cu accent pe AUT
  • Cum are loc testarea bazelor de risc?
  • Concluzie
  • Lectură recomandată

Testarea bazată pe risc și relevanța sa pentru Agile și DevOps

Trei sute de ore petrecute pentru dezvoltarea software-ului pot fi inutile în doar 30 de secunde, cu un singur defect identificat în producție.

La rândul său, acest lucru poate distruge scopul întregului produs fără altă opțiune decât să îl retragă de pe piață. Și aceasta este semnificația și nevoia pentru „testarea calității”.

Odată cu creșterea rapidă a tehnologiei, software-ul este găzduit pe cloud care acceptă mai multe sisteme de operare, platforme multiple, infrastructuri IT complexe etc., utilizatorii finali devin din ce în ce mai preocupați de caracteristici, opțiuni și nu fac niciodată compromisuri pentru satisfacția clienților. .

În zilele noastre, „Calitatea” devine un factor crucial în livrarea de software, unde se produc îmbunătățiri continue pentru a îmbunătăți calitatea, pentru a menține clienții fericiți.

Observăm adesea că este o problemă obișnuită ca aproape toți testerii să fie sub o presiune extraordinară că fereastra lor de testare este stoarsă și, de obicei, construcția este predată lor pentru testare în ultimul moment. Nu există suficient timp și resurse pentru ca aceștia să execute toate testele pe care le-au proiectat, iar acoperirea automatizării nu este întotdeauna 100% și are propriile provocări.

Cronologia de livrare nu poate fi ratată și, în același timp, nu poate fi compromisă și calitatea. Oricare ar fi planul B, de a adăuga resurse de testare suplimentare prin scoaterea de la celelalte echipe, nu funcționează, Planul C, nu mai face toate celelalte activități și redirecționează efortul numai în acest sens, nu este cu adevărat de ajutor. Oricât de multă adăugare de resurse de testare, în cele din urmă, nu funcționează.

Nu există altă opțiune, ci doar efectuarea unor teste limitate și importante în timpul și resursele disponibile.

Deci, cum decidem ce test este important în această etapă? Tot ceea ce un tester consideră important poate să nu fie cu adevărat important pentru clienți. Din perspectiva cui se decide importanța caracteristicii sau a unei funcționalități? Cine va decide care sunt testele importante? Și multe alte întrebări apar în continuare.

Pentru a răspunde la toate aceste întrebări și pentru a gestiona în mod eficient situația de mai sus, s-a apelat la o abordare de testare „Testare bazată pe risc” , sunat în scurt timp „RBT” , a apărut, unde echipa a planificat și identificat în mod clar scenariile de testare pe baza criteriilor „Risc de proiect”.

Deși echipa QA are o imagine clară a testelor importante, RBT este o metodă dovedită de identificare a testelor cruciale și importante din perspectiva clientului și a afacerii printr-o 'Analiza de risc' procedură .

Deci, acum față de modul tradițional de simplă identificare a defectelor software-ului, abordarea și obiectivul QA s-au schimbat odată cu schimbarea tehnologiei, creșterea concurenței pe piață pentru lansarea unui software de calitate, introducerea „Automatizează totul” și, în totalitate, introducerea practicii Agile și DevOps de livrare a software-ului pe o perioadă de câteva ore.

Prin urmare, tendința actuală a „Principiului de testare” nu este doar „identificarea defectelor”, ci și, de asemenea,

# 1) Concentrați-vă pe zona produsului în care există un impact mare asupra afacerii din cauza eșecului sau a probabilității mari de eșec în producție.

#Două) Concentrându-se asupra identificarea defectelor devreme și permițând unei echipe să o remedieze cât mai curând posibil și, prin urmare, să permită software-ului / produsului sau caracteristicii „Fail Fast”.

# 3) Cel mai important aspect al Serviciului echipei QA este acum să se concentreze asupra clientului în a aduce valoare clientului prin creșterea concentrării pe „Experiență de la capăt la cap”

Abordare de testare bazată pe risc

Este întotdeauna ca pregătirea pentru o examinare, că nu se poate spune că testarea este suficientă și că nu mai există defecte în software, chiar dacă acestea proiectează și execută un număr amplu de teste.

Există un moment în care stabilitatea software-ului nu va fi dublă asigurată prin creșterea numărului de cazuri de testare. În acest moment, nu este doar să ne concentrăm asupra numărului de teste, ci asupra a ceea ce se așteaptă de fapt clientul de la lansare.

Prin urmare, este esențial să se obțină un echilibru în optimizarea testării pentru a obține beneficiul maxim cu efortul rezonabil de testare. Și acest lucru este mai important atunci când termenele de testare sunt foarte strânse și nu sunt disponibile resurse suficiente pentru a efectua teste suficiente.

Astfel, în acest caz, abordarea RBT joacă un rol cheie în optimizarea efortului de asigurare a calității și maximizarea beneficiului testării cu un risc minim de afaceri.

Deci, dacă ne concentrăm asupra aspectului de mai sus, atunci munca unui QA va fi mult ușurată. Nu trebuie să-și ardă sfârșiturile de săptămână la birou, testând continuu software-ul și îngrijorându-se de fiecare defect S4 (Severitate 4) și P4 (Prioritate 4) care iese din testare.

Ei bine, 4 este considerat ca fiind cea mai mică prioritate și severitatea defectelor la testare. Ei își pot investi mai bine timpul în alte aspecte utile ale proiectului.

Pentru a rezuma principalele motoare ale abordării „testarea bazată pe risc”:

• Pentru a permite testarea „a ceea ce doresc clienții” din perspectiva afacerii.
• Pentru a îndeplini programul de timp cu calitatea așteptată.
• Pentru a optimiza efortul QA.

Când folosim abordarea RBT?

Aceasta este utilizată în scenariile de mai jos:

• Abordarea RBT poate fi utilizată ori de câte ori există o limitare sau constrângere în ceea ce privește timpul, costul și resursele unui proiect și ori de câte ori este nevoie de optimizarea resurselor.
• Abordarea RBT este utilizată atunci când programul este mai complex și adaptează tehnologia nouă și implică, prin urmare, o mulțime de provocări.
• Atunci când programul este un proiect de cercetare și dezvoltare, acesta este de un prim tip și există o serie de necunoscute și riscuri în proiect.

Exemplu de abordare RBT

Mai multe abordări de analiză bazată pe risc sunt utilizate în industria IT pentru a depăși riscurile cu care se confruntă producția și impactul acesteia.

Mai jos este prezentată o astfel de abordare:

Această abordare a RBT include identificarea „funcționalităților vitale sau caracteristici cheie” ale produsului și evaluarea riscurilor la care sunt expuse fiecare dintre aceste funcționalități în producție și implementarea măsurilor de atenuare adecvate pentru a reduce sau a reduce riscul.

Prin urmare, abordarea RBT include testarea funcționalităților care au probabilitatea de eșec și cel mai mare impact asupra afacerii. Tipurile de eșecuri ar putea fi operaționale sau de afaceri, tehnice, externe etc.

Modalități de a efectua analiza riscurilor

Nu există un proces sau șablon standard definit ca atare pentru a efectua analiza riscurilor în testarea software pentru fiecare caracteristică a unui produs. Diferite organizații își folosesc propria abordare a metodelor de analiză a riscurilor.

Analiza riscurilor poate fi efectuată pe diferite elemente ale proiectului pentru a identifica riscurile și pentru a implementa o abordare RBT pentru analiză. Aceste articole includ,

• Caracteristici
• Funcționalități
• Povești de utilizatori
• Cerințe
• Cazuri de utilizare
• Cazuri de testare

În acest caz, să ne concentrăm doar pe cazuri de testare pentru a înțelege implementarea abordării de testare bazată pe risc.

Procedura de analiză a riscurilor

Analiza riscurilor include implicarea părților interesate relevante din program atât din partea „ Echipa tehnică și echipa de afaceri ” , care include, proprietarul produsului, manageri de produse, analiști de afaceri, arhitecți, testeri și reprezentanți ai clienților.

Sesiuni de brainstorming care implică aceste părți interesate ar fi organizate pentru a desfășura discuția pentru a identifica importanța fiecărei caracteristici a unui produs și a le acorda prioritate pe baza riscului de eșec și a impactului acestuia asupra utilizatorilor finali în producție.

Diverse „documente de proiect”, cum ar fi documentul privind cerințele, documentele cu specificații tehnice, documentele de arhitectură și proiectare, documentul procesului de afaceri, documentul de caz de utilizare etc., vor deveni elementele de intrare pentru sesiunea de brainstorming.

Cunoștințele părților interesate despre produs și produsul existent pe piață vor fi, de asemenea, un factor de intrare pentru discuție.

Puține alte surse de intrări pot include, de asemenea,

• Pentru a aduna intrări despre cele mai utilizate funcționalități.
• Intrări de la consultarea unui expert în domeniu.
• Date din versiunea anterioară a produsului sau produs similar în piață.

In timpul brainstorming sesiune, sunt identificate riscurile legate de fiecare dintre aceste caracteristici. Tipurile de riscuri ar putea fi operaționale, tehnice sau legate de afaceri. Testele și scenariile legate de acestea sunt ponderate, iar valorile riscurilor sunt evaluate pe baza probabilității de apariție a riscului și a impactului riscului.

„Probabilitatea apariției riscului” se poate datora:

• Înțelegerea slabă a caracteristicii de către echipa de dezvoltare a produsului.
• Arhitectură și design necorespunzător.
• Timp insuficient pentru proiectare.
• Incompetența echipei.
• Resurse inadecvate - oameni, instrumente și tehnologie.

„Impactul riscului” este efectul eșecului utilizatorilor și al afacerii dacă apare. Impactul ar putea fi,

• Impactul costurilor, rezultând într-o pierdere.
• Impactul afacerii care duce la pierderea afacerii sau pierderea cotei de piață, proceduri legale, pierderea licenței.
• Impact asupra calității, rezultând eliberarea produsului necorespunzător sau incompetent.
• Experiență proastă a utilizatorului, care duce la nemulțumirea și pierderea unui client.

Domeniul principal al evaluării riscului unei caracteristici sau a unui produs poate fi,

• Criticitatea funcționalității în zona de afaceri.
• Cele mai utilizate caracteristici și funcționalități importante.
• Defectează zonele predispuse
• Funcționalitatea care are impactul asupra siguranței și securității.
• Zona de proiectare complexă și arhitectură.
• Modificări aduse de la versiunile anterioare.

Metodologia analizei riscurilor

Să înțelegem în detaliu „metodologia de testare bazată pe risc”.

Abordarea testării bazate pe risc utilizează RISC ca criterii în toate fazele de testare ale ciclului de testare, adică planificarea testelor , proiectarea testelor, implementarea testelor, executarea testului și raportarea testelor. În mod ideal, se poate proiecta un număr numeroase de combinații posibile de scenarii de testare.

Prin urmare, abordarea RBT include o clasificare a testelor pe baza gravității riscurilor pentru a afla cea mai defectă sau riscantă zonă de eșec, care provoacă un impact ridicat asupra afacerii.

Principalul obiectiv al analizei riscurilor este de a distinge între 'Valoare ridicata' elemente precum caracteristicile produsului, funcționalități, cerințe, povestirile utilizatorilor și cazuri de testare și „ Valoare mica' unele și, mai târziu, să ne concentrăm mai mult pe cazurile de test „Valoare ridicată”, concentrându-ne mai puțin pe cazurile de test „Valoare mică”. Acesta este pasul inițial al analizei riscurilor înainte de a începe testarea bazată pe risc.

Sarcina principală de clasificare sau grupare a cazurilor de testare în valoare mare și valoare scăzută și atribuirea valorii prioritare fiecăruia dintre aceste cazuri de testare include următorii pași:

Pasul 1) Utilizarea unei grile 3X3

Analiza riscurilor se realizează utilizând o grilă 3X3, unde fiecare funcționalitate, nefuncționalitate și cazurile de test aferente sunt evaluate de o echipă de părți interesate pentru „Probabilitatede eșec ”și„ Impactul eșecului ”.

Probabilitatea de eșec a fiecărei funcționalități din producție este în general accesată de un grup de „experți tehnici” și sunt clasificate ca „Probabil să eșueze, destul de probabil și puțin probabil” de-a lungul axei verticale a grilei.

diferența dintre redirecționarea portului și declanșarea

În mod similar, „Impactul eșecului” acestor caracteristici și funcționalități în producție este experimentat de clientul final, dacă nu este testat, este evaluat de un grup de ' Specialiști în afaceri ”și sunt clasificate în categorii„ Minore, vizibile și de întrerupere ”de-a lungul axei orizontale a grilei.

Pasul 2) Probabilitatea și impactul eșecului

Toate cazurile de testare sunt poziționate în cadranele grilei 3 X 3 pe baza valorilor identificate ale probabilității de eșec și impactului eșecului, care sunt prezentate ca puncte în imaginea de mai jos.

Evident, probabilitatea mare de eșec și impactul mare al eșecului (întrerupere) sunt grupate în colțul din dreapta sus al rețelei, ceea ce este de o importanță ridicată și, prin urmare, se identifică că testele „Valoare ridicată” și testele „Valoare scăzută” sunt grupate în colțul din stânga jos, care este cel mai puțin sau deloc important pentru client, unde se poate acorda o atenție minoră acestor caracteristici sau cazuri de testare.

Pasul 3) Testarea grilei prioritare

Pe baza poziționării de mai sus a cazurilor de testare în grilă, testele sunt prioritizate și etichetate cu prioritățile 1,2,3,4 și 5 și sunt marcate pentru fiecare dintre ele. Cele mai importante teste sunt poziționate într-un 1^Sfgrila care este atribuită cu prioritatea 1 și în mod similar cele mai puțin importante sunt clasificate ca 2, 3, 4 și 5.

În cele din urmă, toate cazurile de testare sunt sortate în funcție de numerele lor de prioritate și sunt preluate pentru executare în ordinea priorității. Cele cu prioritate ridicată sunt preluate pentru execuție mai întâi, iar cele cu prioritate redusă sunt executate mai târziu sau fără scop.

Pasul 4) Detalii de testare

Următorul pas este de a decide cu privire la nivelul detaliilor testării pentru domeniul de testare definit. Adâncimea scopului testării poate fi decisă pe baza clasamentului de mai sus, conform grilei de mai jos.

Testele cu prioritate ridicată cu clasamentul 1 sunt testate „Mai în detaliu” și, în consecință, experții sunt detașați pentru a testa aceste caracteristici de mare criticitate și cazurile de test aferente. În mod similar, testați cazurile cu prioritatea 2, 3 și 4. Se poate lua o decizie de eliminare a caracteristicilor priorității 5 și teste pe baza timpului și a resurselor disponibile.

Prin urmare, abordarea Nivelului de detaliu al testării de prioritizare a caracteristicilor și a cazurilor sale de testare nu numai că îi ajută pe testatori să identifice „testele de valoare ridicată”, ci și îi îndrumă să decidă „nivelul de detaliu al testării” pe baza acestor clasamente prioritare și îi ajută să efectueze teste mai bune și reduce costurile de testare prin procesul de optimizare.

Cum este RBT relevant pentru Agile și DevOps?

Acum, după ce am înțeles abordarea testării bazate pe risc de a efectua testarea pe baza prioritizării testelor, în funcție de „riscul de eșec” al unei anumite caracteristici și de „impactul asupra clientului” în direct, evident, s-ar ridica problema relevanța abordării testării bazate pe risc în practicile Agile și DevOps.

„Automatizează totul”, „Testează totul”, „Testează continuu”, „Testează în mod repetat” sunt conceptele cheie ale acestor practici.

De fiecare dată, când există o modificare a codului sau există o versiune, toate testele proiectate sunt executate prin intermediul automatului Integrare continuă (CI) / Livrare continuă (CD) rapid și repetat, indiferent de stabilirea priorităților lor.

Atunci care este relația dintre RBT și DevOps? Unde s-ar potrivi RBT și ar deveni relevant în Agile și DevOps ???

# 1) Da, așa cum am spus mai devreme, nu fiecare industrie și fiecare produs au o acoperire de automatizare 100% pentru execuțiile lor de testare. Deci, dacă echipa trebuie să facă alegerea prioritizării pentru executarea testelor din alegerea cazurilor de testare manuale și ar dori să economisească energia și efortul resurselor de testare pentru alte activități, atunci RBT este cea mai bună alegere.

Abordarea bazată pe risc este, de asemenea, un pariu mai bun pentru efectuarea testelor automatizate cu prioritate ridicată și testarea cel mai devreme.

#Două) Echipa QA poate adopta abordarea RBT mai eficient în timpul analizei cerințelor, analizând cerințele și oferind un raport în avans cu privire la riscurile probabile ale produselor și caracteristicile, astfel încât echipa programului să poată întreprinde acțiuni adecvate pentru a o atenua.

# 3) Abordarea RBT poate fi utilizată eficient în proiectarea cazurilor de testare și a scenariilor bazate pe risc ridicat, astfel încât să se poată acorda mai multă atenție caracteristicilor și funcționalităților cu risc ridicat.

# 4) Identificarea zonelor „cu risc ridicat” permite echipei de asigurare a calității să își concentreze efortul de testare pe acele zone pentru a testa „mai amănunțit” folosind „testatori cu înaltă calificare”.

# 5) „Fail Fast”, așa cum știm cu toții, este conceptul „Agile” și „DevOps”, pentru care abordarea RBT ajută la identificarea zonelor „cu risc ridicat” din software, la identificarea defectelor devreme și le permite să eșueze rapid și să eșueze mai întâi și lăsați echipa să o remedieze.

# 6) Scopul final al Agile / DevOps este „Orientarea către client” și, prin urmare, abordarea RBT permite QA să se concentreze asupra experienței clientului decât doar pe găsirea defectelor.

Beneficiile abordării testării bazate pe risc

Am înțeles deja scopul și utilizarea abordării RBT de analiză a cerințelor, proiectarea și executarea scenariilor de testare. Există mai multe beneficii ale RBT.

Putem consolida și enumera beneficiile testării bazate pe risc ca:

• Ajută la o utilizare mai eficientă și optimizată a resurselor de testare.
• Ajută la ușurarea activităților de asigurare a calității, testarea, proiectarea și dezvoltarea testelor și pregătirea testelor prin prioritizare.
• Ajută la o mai bună gestionare a resurselor de asigurare a calității prin alocarea resurselor cheie către domenii cu focus mare.
• Ajută la utilizarea eficientă a resurselor și deviază timpul și energia lor asupra lucrurilor mai bune din proiect.
• Ajută echipa QA în planificarea eforturilor de testare bazate pe evaluarea riscurilor și identificarea zonelor volatile și cu risc ridicat.
• Ajută echipa să optimizeze testele care urmează să fie efectuate în funcție de importanță și, prin urmare, elimină testele cu valoare redusă, în acord cu părțile interesate.
• În general, ajută la reducerea costurilor prin activități de testare optimizate și reduse.
• Abordarea RBT permite echipei QA să testeze mai întâi zonele cu risc ridicat și permite produsului să „Eșueze rapid” și să repare rapid.
• Abordarea RBT ajută la aducerea clarității în „ Acoperirea testului ” și „Test Scope” pentru întregul grup de părți interesate.
• Echipa își poate concentra atenția asupra zonelor cu risc ridicat și poate păstra mai puțin concentrarea asupra zonei cu risc scăzut.
• RBT permite echipei să decidă cu mult timp înainte cu privire la implementarea celui mai eficient mod de atenuare a riscurilor produsului.
• RBT ajută la evitarea efectului implementării necorespunzătoare a atenuărilor.
• Testarea bazată pe risc permite echipei să ia măsuri adecvate fie pentru a atenua, fie pentru a planifica situații de urgență, fie pentru a poziționa orice soluție pentru a depăși eșecul sau pentru a reduce impactul acestuia dacă riscul apare în Live.
• RBT ajută la minimizarea riscului rezidual în eliberare.
• Ajută la realizarea „calității îmbunătățite” prin defecte mai puțin costisitoare ale producției.
• În cele din urmă ajută la „Experiență îmbunătățită a clienților” și „Client satisfăcut”.

Apoi, vom învăța cum să gestionăm riscurile în fazele de planificare și executare a testelor din ciclul de viață al testării software-ului.

Managementul riscului în timpul planificării testelor

Cum să gestionați riscurile în timpul fazei de planificare a testului:

Viața este plină de riscuri, la fel și un proiect software. Orice poate merge prost oricând. Suntem întotdeauna în picioare pentru a face lucrurile corecte - dar ce să ne asigurăm că nimic nu merge prost și că atunci când știm exact ce să facem? Introduceți managementul riscurilor - aceasta este o parte a unui proiect de testare software care ne pregătește să prevenim, să înțelegem, să găsim și să trecem peste riscuri.

Un risc este pur și simplu o problemă care poate apărea și, atunci când se produce, va provoca o pierdere.

Pierderea ar putea fi orice: bani, timp, efort sau un compromis de calitate. Pierderea nu este niciodată bună. Indiferent cât de mult îi rotim, nu este pozitiv și nu va fi niciodată. Prin urmare Managementul riscurilor este o parte integrantă a proiectelor software pentru a ne asigura că gestionăm riscurile și prevenim / reducem pierderile.

Testarea bazată pe risc : Deoarece suntem o comunitate de asigurare a calității, permiteți-ne să rămânem exclusiv riscurilor și procesului aferent acesteia în lumea noastră de asigurare a calității. Riscurile sunt evaluate și gestionate aproximativ în 2 faze ale noastre Ciclul de viață al testului software . STLC poate fi clasificat în 3 faze: planificarea testelor, proiectarea testelor și executarea testelor.

Procesul de gestionare a riscurilor are loc de două ori, în timpul:

1. Planificarea testelor
2. Proiectarea cazului de testare (sfârșit) sau uneori în faza de executare a testului

Este obligatoriu în cazul 1, dar în cazul 2 este mai degrabă o situație „bazată pe necesități”.

Seria de articole din două părți:

Chiar dacă procesul de bază este același, tipuri de riscuri abordate în ambele aceste domenii sunt complet diferite. Pentru a le face dreptate în mod individual, le vom trata diferit ca o serie din două părți.

Această secțiune va fi despre „Managementul riscurilor în timpul planificării testelor”.

Procesul de gestionare a riscurilor

Procesul generic de gestionare a riscurilor implică 3 etape importante:

1. Identificarea riscului
2. Analiza impactului riscului
3. Atenuarea riscurilor

Riscuri de testare și exemple de atenuare:

# 1) Identificarea riscului

După cum se spune, primul pas pentru rezolvarea unei probleme este identificarea acesteia. Această etapă implică realizarea unei liste cu tot ceea ce ar putea apărea și perturba fluxul normal al evenimentelor.

Rezultatul principal al acestui pas este o listă a riscurilor.

Această etapă de testare bazată pe risc este condusă în mod obișnuit de conducătorul / managerul / reprezentantul QA. Cu toate acestea, liderul singur nu va putea veni cu întreaga listă - intrarea întregii echipe de QA are un impact uriaș. Putem spune că aceasta este o activitate colectivă condusă de conducătorul QA.

De asemenea, riscurile identificate în timpul fazei de planificare a testelor au o orientare mai „managerială”, ceea ce înseamnă că vom analiza orice ar putea avea impact asupra programului, efortului, bugetului, modificărilor de infrastructură ale proiectului de asigurare a calității, etc. nu AUT, ci modul în care va continua faza QA.

Riscuri în timpul planificării testelor: exemple de testare bazată pe riscuri

Următorul este un exemplu de listă a riscurilor care ar putea fi listate în timpul fazei de planificare a testelor. Vă rugăm să rețineți că AUT și funcționalitatea sa nu se concentrează aici.

1. Programul de testare este strâns. Dacă începutul testării este întârziat din cauza sarcinilor de proiectare, testul nu poate fi prelungit dincolo de data de începere programată UAT.
2. Resurse insuficiente, integrarea resurselor prea târziu (procesul durează aproximativ 15 zile.)
3. Defectele se găsesc într-un stadiu târziu al ciclului sau într-un ciclu târziu; defectele descoperite târziu se datorează cel mai probabil unor specificații neclare și necesită mult timp pentru a le rezolva.
4. Domeniul de aplicare nu este definit complet definit
5. Dezastre naturale
6. Indisponibilitatea Independent Mediu de testare și accesibilitate
7. Testarea întârziată din cauza unor noi probleme

În acest moment, puteți alege să fiți la fel de minuțios pe cât doriți, în funcție de timpul disponibil.

Odată listate toate riscurile, trecem la evaluarea riscului / analiza impactului riscului.

# 2) Evaluarea riscului / Analiza impactului riscului

Analiza riscurilor este ceva de genul acesta? :)

Analiza riscurilor în testarea software-ului : Toate riscurile sunt cuantificate și prioritizate în acest pas. Probabilitatea fiecărui risc (șansa de apariție) și impactul (cantitatea de pierdere pe care l-ar provoca atunci când acest risc se materializează) sunt determinate în mod sistematic.

Înalt - mediu-scăzut , valorile sunt atribuite atât probabilității, cât și impactului fiecărui risc. Riscurile cu probabilitate „mare” și impact „ridicat” sunt luate în considerare mai întâi și apoi ordinea urmează.

Tabelul analizei impactului riscului:

Urmând acești pași, tabelul de analiză a impactului riscului pentru riscurile enumerate mai sus ar arăta cam așa (toate valorile sunt ipotetice și numai în scopul înțelegerii):

# 3) Atenuarea riscurilor

Ultimul pas al acestui proces de testare bazată pe risc (RBT) este de a găsi soluții pentru a planifica modul de gestionare a fiecăreia dintre aceste situații. Aceste planuri pot diferi de la companie la companie, proiect la proiect și chiar de la persoană la persoană.

Tehnici de reducere a riscurilor:

Iată un exemplu în ceea ce se transformă tabelul riscului la finalizarea acestei faze:

Câteva puncte de remarcat:

1. Cu cât managementul riscurilor începe mai repede într-o fază de planificare a proiectului de asigurare a calității, cu atât mai bine.
2. Dintre toți cei 3 pași, Identificarea riscurilor este cea mai importantă . Dacă ceva nu este listat și luat în considerare pentru pași suplimentari, riscul nu este tratat.
3. Încercați să găsiți un interval de timp ideal pentru această activitate. Nu uitați, prea multă planificare lasă prea puțin timp pentru a face acest lucru.
4. De asemenea, după procesul de gestionare a riscurilor, dacă apare o nouă situație, planul de gestionare a riscurilor poate fi modificat sau actualizat pentru a reflecta starea cea mai actuală.
5. Date istorice poate fi foarte util pentru succesul acestui proces.

Concluzie

Acest lucru ne duce la sfârșitul gestionării riscurilor în faza de planificare a testelor. Chiar dacă pașii și principiile de bază sunt similare, procesul de gestionare a riscurilor este mai concentrat către AUT atunci când se întâmplă în faza de proiectare / execuție a testului.

În următoarea noastră secțiune, vom acoperi - Managementul riscului în faza de executare a testului.

Managementul riscului în faza de execuție a testului (cu exemplu)

În călătoria noastră către înțelegerea procesului de gestionare a riscurilor, am vorbit despre modul în care se desfășoară exclusiv în Faza de planificare a testării testării bazate pe risc . De asemenea, am înțeles procesul generic care implică - identificarea riscurilor, evaluarea riscurilor și planul de reducere a riscurilor.

Cum să gestionați riscul la proiectarea testului sau la faza de execuție a testului:

Există o altă formă de Managementul riscurilor (denumit uneori, Testarea bazată pe risc ) care apare în timpul fazei de proiectare a testului sau de execuție a testului în funcție de situație. Acum, despre ce situație vorbim? Să încercăm mai întâi să înțelegem asta.

Știm cu toții că activitatea noastră de testare este reactivă. Fără cerințe (sau domeniu de aplicare definit), nu putem efectua o analiză de fezabilitate și nu putem scrie scenarii de testare sau planuri pentru activități de testare.

În mod similar, atunci când codul nu este gata, nu avem nimic de testat, indiferent cât de mult din lucrările de pregătire am fi fost gata în termenii cazurilor de testare, a datelor de testare etc. De asemenea, testarea este singurul pas rămas înainte ca produsul să treacă Trăi.

Managementul riscurilor - cu accent pe AUT

Să înțelegem mai bine acest lucru cu un exemplu:

Dacă testarea trebuia să înceapă la data menționată, 1 ianuarie^Sfși a trebuit să continue până pe 14 ianuarie^a- la finalizarea testării, data de lansare a produsului este de obicei fixată imediat. Să spunem - 15 ianuarie^apentru simplitate. Acum, într-o lume perfectă lucrurile ar merge exact așa cum s-a planificat. Dar știm cu toții realitatea.

În acest caz, să presupunem că, din anumite motive, testarea nu a început decât pe 7 ianuarie^a, ceea ce înseamnă că am pierdut jumătate din timpul nostru de testare. Dar avem nevoie de 14 zile pentru a testa produsul cu atenție. Am putea muta data de intrare mai departe cu 7 zile - totuși; aceasta de obicei nu este o opțiune. Deoarece produsul este promis să intre pe piață la o anumită dată și eventualele întârzieri nu sunt bune pentru afacere.

Deci, de obicei, echipele de testare trebuie să absoarbă întârzierile, să compenseze cumva, să lucreze cu timpul disponibil și să se asigure că produsul este testat bine. Lucrare grea, nu-i așa?

Aici se folosește din nou procesul de gestionare a riscurilor.

• Acum dacă întârzierile sunt anticipate din timp înainte chiar de începerea testării - procesul are loc în faza de proiectare a testului.
• Dacă întârzierile se întâmplă în timpul unui Faza de executare a testului care a început normal - procesul este urmat în timpul fazei de execuție a testului.
• Pașii și metoda sunt aceleași indiferent de etapa în care se întâmplă.

Care este procesul?

Gestionarea riscurilor are loc pentru a determina ce zone ale AUT (Application Under Test) necesită focalizare maximă. Acestea sunt de obicei zonele funcționale (module sau componente) care sunt critice pentru succesul produsului final și sunt cele mai predispuse la eșec.

Citește și=> Modul de eșec și analiza efectelor (FMEA) este o tehnică de gestionare a riscurilor

Cine o interpretează?

Întrucât se referă la AUT, cunoștințele despre acesta nu sunt doar pentru QA, ci pentru toate celelalte echipe - Dev, BA, Client, echipe de management de proiect etc. De aceea este un efort colectiv, condus de echipa de testare.

Cum are loc testarea bazelor de risc?

Pasul 1) Identificarea riscului

Identificați toate zonele funcționale ale AUT. Aceasta va include pur și simplu realizarea unei liste.

Pasul 2) Evaluare a riscurilor

Toate riscurile sunt cuantificate și prioritizate în acest pas. Cuantificarea este pur și simplu, atribuirea unui număr fiecărui risc din listă, care va oferi o indicație a priorității cu care trebuie abordat.

Probabilitatea fiecărui risc (șansa de apariție) și impactul (cantitatea de pierdere pe care l-ar provoca atunci când acest risc se materializează) sunt stabilite.

Metoda tipică este de a atribui evaluările. De exemplu, Probabilitatea poate lua valorile de la 1 la 5. 1 fiind probabilitatea apariției fiind scăzută (deloc probabil să se întâmple deloc) și 5 fiind ridicată (cu siguranță se va întâmpla).

În mod similar, Impactului i se poate atribui și un rating de 1-5. 1 fiind cu impact redus (chiar dacă acest risc se materializează, pierderea este minimă) și 5 fiind cu impact ridicat (pierderi uriașe atunci când se întâmplă).

test de unitate vs exemplu de test de integrare

Pasul 3)

Realizați un format de tabel și circulați către toți reprezentanții echipei - Dev, BA, Client, PM, QA și oricine altcineva relevant.

Pasul 4)

Indicați fiecărei echipe să completeze valorile pe baza evaluării lor pentru probabilitate și impact.

Deoarece valorile probabilității și impactului sunt numerice, va facilita calcularea valorii „Factorului de risc”.

Factor de risc = Probabilitatea X Impact. Cu cât factorul de risc este mai mare, cu atât problema este gravă.

Un exemplu:

Vă rugăm să rețineți că, în acest moment, acesta este pur și simplu rezultatul evaluării unei echipe. Pentru un proiect în care sunt implicate 5 echipe diferite, echipa QA ar ajunge cu 5 tabele diferite.

Pasul 5)

Luați o medie a valorilor factorului de risc. De exemplu, dacă sunt 5 echipe, pentru fiecare modul, adăugați toate valorile factorului de risc și împărțiți-le la 5. Acestea sunt valorile finale cu care vom trata. Spuneți, aceștia sunt factorii de risc medii:

Cu cât factorul de risc este mai mare, cu atât acel modul trebuie testat.

Deci, modulele 5 și 2 sunt cele mai importante pentru succesul afacerii. Distribuiți rezultatele tuturor echipelor.

Pasul 6)

Planul de reducere a riscurilor : Acum, acesta este pasul care se schimbă de la proiect la proiect. Am identificat că modulele 5 și 2 sunt cele care trebuie concentrate cel mai mult.

Exempleplanul ar putea fi:

1. Modulele 5 și 2 vor fi testate temeinic, asigurându-se că sunt testate toate cazurile de testare legate de acestea. Celelalte module vor fi testate pe bază exploratorie.
2. Modulele 5 și 2 vor fi testate mai întâi și apoi, în funcție de timpul disponibil, celelalte vor fi îngrijite.

Odată realizat un plan, toate echipele ajung la un acord și îl urmează pentru a testa produsul ținând cont de factorul de risc.

Asta este!

Câteva puncte importante de remarcat:

• Deoarece aceasta este o activitate colectivă care necesită avizul tuturor în considerare ; șansele ca acesta să fie corect și eficient sunt mai mari.
• Aceasta este nu o metodă formală și nu trebuie să facă parte din fiecare proiect QA.
• Uneori, chiar dacă echipa alege să nu deseneze tabele și să atribuie valori - a sesiune simplă de brainstorming cu toți cei prezenți, puteți oferi echipei de control calitativ instrucțiuni bune despre cum să procedați.
• contribuția echipei de dezvoltare este foarte important, deoarece ei sunt cei care creează produsul, așa că vor ști ce ar putea funcționa și ce ar putea necesita verificări suplimentare. Asigurați-vă că căutați acest lucru.
• Chiar dacă există mai mulți pași în proces, nu este nevoie de o cantitate considerabilă de timp pentru a le efectua . Mai ales, dacă toate echipele pot sta împreună și pot lucra simultan.
• Amintiți-vă acest proces și rezultatul său este doar alternativa . Obținerea cât mai mult timp planificat pentru testare este cea mai bună modalitate de a efectua activitatea QA.

Concluzie

Abordarea testării bazate pe risc indică în mod clar că accentul testerului nu este doar explorarea continuă a defectelor, indiferent de severitate și prioritate. Acum lucrurile s-au schimbat, testerii trebuie să funcționeze inteligent și trebuie să înțeleagă clar „Nevoia clientului și dorințele utilizatorului”.

Ei trebuie să studieze produsul în detaliu și să înțeleagă care este caracteristica cea mai frecvent utilizată în producție, care este calea cea mai critică pentru generarea de venituri și cum să protejeze și să protejeze clienții de problemele de producție și de amenințările comerciale.

Prin urmare, abordarea RBT îi educă în mod clar pe cei 3 testeri că doar testarea tuturor sau testarea extensivă nu înseamnă că testarea este completă sau că nu există defecte în produs. Testarea eficientă într-un timp stabilit și asigurarea faptului că impacturile critice și majore ale afacerii sunt anulate și acest lucru este destul de important pentru tester.

Astfel, testarea bazată pe risc este instrumentul cel mai eficient pentru echipa QA pentru a ghida părțile interesate din proiect pe baza riscurilor proiectului. Abordarea RBT ajută echipa de asigurare a calității în identificarea continuă a riscului și rezolvarea acestuia, care ar putea pune în pericol realizarea obiectivelor și obiectivelor generale ale proiectului și ajută la atingerea obiectivului final al grupului de asigurare a calității.

P.S. Cuvintele QA și Testare au fost utilizate în mod interschimbabil în tot documentul.

Despre autor: Acest articol este scris de mai mulți membri ai echipei STH - Gayathri Subrahmanyam și Swati S.

Gayathri este un IMM de testare software cu peste 2 decenii de experiență în testarea software și a adoptat pe scară largă abordarea „Testarea bazată pe risc” ca parte a industrializării testelor în mai multe misiuni și a realizat beneficiul optimizării resurselor de testare și testarea calității.

Testarea bazată pe risc a fost o provocare pentru dvs.? Aveți fapte interesante de adăugat la tutorialul nostru? Simțiți-vă liber să vă exprimați gândurile în secțiunea de comentarii de mai jos !!

=> Vizitați aici pentru seria completă de programe de testare

Lectură recomandată

• Proces de integrare continuă: Cum să îmbunătățim calitatea software-ului și să reducem riscul
• Analiza modului de eșec și a efectelor (FMEA) - Cum să analizăm riscurile pentru o calitate software mai bună și clienți satisfăcuți!
• Ghidul final pentru testarea bazată pe risc: gestionarea riscurilor în testarea software-ului
• Top 10 instrumente și tehnici de evaluare și gestionare a riscurilor
• Tipuri de riscuri în proiectele software
• Câteva întrebări interesante despre testarea software-ului
• Alegerea Testelor software ca carieră
• Feedback și recenzii despre cursul de testare software