Abordarea bazata pe prioritizarea riscurilor — Cum oferim valoare maxima intr-o perioada scurta de timp

Prioritizarea bazata pe riscuri este un pas fundamental atunci cand vrei sa oferi valoare maxima intr-o perioada scurta de timp. Daca o faci ca la carte si in mod eficient te ajuta sa eficientizezi intregul proces de software development. O provocare critica in testarea software este sa aflam daca cerintele pot sa fie testate. Mai complicat este sa le prioritizam si sa le clasificam pentru a putea sa planificam si sa optimizam dezvoltarea si testarea in consecinta.

• Vrei sa afli daca cerintele tale sunt testabile?
• Vrei sa intelegi cat de critice sunt cerintele tale in termeni cuantificabili?
• Vrei sa intelegi care sunt cele mai importante cerinte din proiectul tau chiar si inainte de a ajunge in etapa de dezvoltare?
• Vrei sa economisesti din resursele pe care le cheltuiesti pe testarea defectelor, defecte care ar putea sa fie identificate mult mai devreme in cadrul ciclului de dezvoltare al produsului software?

Daca raspunsul la acest intrebari este da, atunci prioritizarea bazata pe riscuri este solutia.

Este un proces care o sa te ajute sa clarifici, sa redefinesti si sa prioritizezi cerintele tale inainte chiar de a incepe procesul de software development sau etapa de testare software.

In cadrul acestui articol ne vom uita la cum sa identificam cat de testabile sunt cerintele, cum sa facem aceste cerinte testabile, idea de baza in prioritizarea bazata pe riscuri precum si procesul in sine si beneficiile pe care le aduce.

Identificarea testabilitatii cerintelor

De cate ori te-ai aflat in situatii unde Project Managerii sau Test Managerii erau dornici sa inteleaga daca cerintele sunt testabile (adica daca pot sa fie testate? De cate ori te-ai aflat in situatii unde cerintele tale sunt revizuite ca ‘Team Exercise’? Situatii de acest gen se intampla des.

Aceasta este una din provocarile critice in Test Management si o amenintare la adresa procesului de testare.

Pentru a te asigura ca cerintele tale sunt testabile, trebuie sa te asiguri ca aceste cerinte sunt Complete, Concise, Corecte, Fezabile si lipsite de Ambiguitate. Daca indeplinesc aceste 5 caracteristici, poti spune cu incredere ca toate cerintele tale sunt testabile si ca toata lumea din echipa ta va putea sa le inteleaga si sa le interpreteze in acelasi fel.

‘Identificarea testabilitatii cerintelor’ este primul pas in prioritizarea bazata pe riscuri. Acum, urmatoarea intrebare este cand in cadrul ciclului de viata al produslui software sau procesului Agile ar trebui sa faci acest lucru? Raspunsul este destul de direct. Cand te afli in Etapa de analiza / Planificare a sprintului, este responsabilitatea analistilor tai de business de a aduna toate cerintele si de a se asigura ca acele cerinte au sens si pot sa fie testate.

Evident ca atunci cand te afli in etapa de analiza nu ai inca identificata echipa de testare daca mergi pe software development lifecyle sau echipa Scrum atunci cand folosesti Agile. Insa recomandarea este sa identifici cel putin unul din membrii echipei tale de baza (Test Manager, ingineri de testare sau programatori) care sa lucreze la clarificarea cerintelor.

Daca toate cerintele sunt testabile si esti increzator, e perfect! Insa daca ai cerinte care nu sunt testabile ar trebui sa incerci sa le faci testabile prin intermediul acestei tehnici de prioritizare pe baza de riscuri.

Cum sa iti faci cerintele testabile?

Spre exemplu, definitia cerintei tale spune “Aplicatia ar trebui sa arate un mesaj de status sau sa deconecteze un utilizator daca nu exista activitate timp de 60 de secunde”

Daca ne uitam la definitia acestei cerinte, vedem ca are niste ambiguitati asa ca trebuie sa punem niste intrebari.

• Despre ce aplicatie vorbim?
• Ar trebui sa arate un mesaj de status sau sa deconecteze un utilizator sau ar trebui sa le arate pe ambele?
• Specifica intervalul ca fiind de „60 de secunde”. Asa ca intrebarea este — este ok sa deconectam un utilizator daca nu este activitate timp de 50 de secunde?

Din moment ce aceasta cerinta are ambiguitatile de mai sus, nu poate sa fie testata. Cei din echipa ta vor interpreta aceasta cerinta in mod diferit. Programatorii tai s-ar putea sa implementeze ceva si cei care fac testare software s-ar putea sa testeze altceva. Astfel ca produsul pe care il vei scoate pe piata nu va avea valoare si gradul de satisfactie al clientilor va fi zero. Astfel ca rolul tau este sa te asiguri ca cerintele sunt cat se poate de clare.

Pentru a face o cerinta testabila trebuie sa listezi toate ambiguitatile/intrebarile si sa le dai mai departe catre analistul de business. Dupa ce ai primit raspunsurile la aceste intrebari, cerintele tale trebuie actualizate si documentatia legata de cerinte trebuie sa circule in cadrul echipei. Dupa aceasta etapa incepem procesul.

Idea de baza in prioritizarea bazata pe riscuri

Prioritizarea bazata pe riscuri este un proces:

• Unde verificam daca cerintele sunt testabile
• In care intelegem ce trebuie sa testam legat de cerinte
• In care prioritizam cerintele in functie de cat de critice sunt. Si prin critic ne referim ca fiind critice pentru business

Primul bullet a fost deja discutat mai sus. Cerintele trebuie analizate pe baza celor 5 criterii si apoi transformate in cerinte testabile.

La bulletul numarul 2 avem in minte faptul ca fiecare cerinta in cadrul procesului de software development are un risc asociat. Sa presupunem ca ai o cerinta care spune „Schimbarea fontului de pe website-ul companiei”. Chiar daca aceasta cerinta pare a fi una simpla, are anumite riscuri asociate. Important este intelegem pasii necesari pentru a atenua acel risc.

La cel de-al treilea bullet folosim numere pentru a analiza Impactul si Probabilitatea fiecarei cerinte.

Spre exemplu, sa presupunem ca avem 100 de cerinte. Vom numerota parametrii pentru fiecare din cele 100 de cerinte. Acesti doi parametri sunt in general analizati pe o scara de la 1 la 3. 1 este „Scazut” si 3 este „Ridicat”.

Impact indica importanta cerintei. Care sunt consecintele sau ramificatiile pe care le vei intalni daca acea cerinta esueaza in procesul de productie? Acest lucru este indicat de ‘impact’

Spre exemplu, daca impactul este „Ridicat” putem sa il notam cu 3. Daca este „Scazut” il putem nota cu 1. Daca impactul este mediu, il notam cu 2. Aceasi logica o aplicam si la Probabilitate.

Probabilitatea indica sansele de esec sau sansele ca erorile sa fie livrate in productie. Din nou le notam de la 1 la 3.

Acum, pe baza numerelor pe care le-am folosit pentru Impact si Probabilitate, calculam scorurile de risc pentru fiecare cerinta folosind formula de mai jos:

Risk Score = Impact * Probabilitate

Conform acestei formule cel mai mare scor de risc este 9 (i.e. Impact X Probabilitate = 3*3 = 9) si cel mai scazut este 1. Astfel ca scorurile variaza intre 1 si 9.

In momentul in care ai identificat aceste scoruri, imparti cerintele in Ridicat, Mediu si Scazut pe baza unor cerinte similare cu cele de mai jos.

In functie de compania unde activezi parametrii si modelul de scorare pot sa varieze.

Tabelul din stanga arata instructiunile pe care le ai pentru a clasifica cerintele si in tabelul din dreapta sunt diferitele permutari si combinatii pe care le poti avea impreuna cu categoriile de risc. In cea de-a doua parte a acestui articol vom discuta despre proces.

Vrei o cariera in testarea software sau vrei sa faci un upgrade?

Descopera cursurile noastre de testare software.

Originally published at https://www.luxoft-training.ro.