Testarea software. Rezultatele procesului de testare
Continuam seria noastra de articole legate de testarea software.
Versiunea 1.0 in detaliu
Subestimarea eforturilor de testare duce de multe ori nu la schimbarea strategiei de testare, ci la mai multe eforturi (timp in plus, personal suplimentar etc) si in consecinta la deadline-uri depasite si / sau costuri mai mari pentru proiect. Ne aflam deci in situatia in care am subestimat eforturile necesare pentru testarea software sau altcineva a facut acest lucru pentru noi — ce putem face?
“Trebuie sa ne oferiti lucrurile de care avem nevoie! Da, avem o estimare de 3500 de ore de lucru, insa totul merge prost si avem nevoie de mai mult timp si mai multi oameni.” Este acest lucru ceva rau? Depasim limitele care ne-au fost stabilite, orizontul de timp si costurile. Si nu este nimic mai rau pentru client deoarece timpul inseamna totul. Bineinteles ca este inacceptabil sa ne facem treaba la timp dar prost. Dar este la fel de inacceptabil sa livram proiectul cu sase luni intarizere.
Un exemplu: “Principalul obiectiv este sa obtinem proiectul, si apoi vedem ce si cum.” Participam la o licitatie si am estimat 500 de ore ca efort de testare. Este costisitor. Ni se spune sa reducem orele, dar nu si programatorii. Cu asemenea costuri in ceea ce priveste munca, proiectul nu poate merge mai departe. Astfel ca ne decidem sa reducem testarea software la 300 de ore. Nu este inca clar ce vor face software testerii in acest proiect. Daca livram software cu defecte, este evident ca nu este ok. “Daca scriu test cases — cine are nevoie de aceste test cases pana la urma?!” Am auzit aceasta fraza de la top manegement de multe ori.
OK, am agreat 300 de ore. Dar nu stim inca cum vom reusi sa facem tot ceea ce am promis. Dar am agreat aceasta estimare si am promis ca ne vom ocupa de tot. Si timpul a expirat. Care sunt urmatorii pasi? Nu exista nici o solutie miraculoasa. Fie oprim testarea software, lucru care nu este benefic pentru proiect din punct de vedere tehnic, fie continuam testarea dar proiectul va fi pe pierdere. Si daca compania este listata la bursa, actionarii vor spune “rata de profit este foarte scazuta”. Astfel calitatea produsului devine imprevizibila.
Un alt exemplu: “Orice va doriti de bugetul pe care il aveti”. De cate ori i-ati spus asta unui client? Clientul o ia la propriu si incepe sa ceara tot felul de lucrui. Proiectul este livrat pe baza unui model Fixed Price, astfel ca toata lumea incearca sa minimizeze costurile. Incep sa aiba loc tot felul de schimbari si apare si nevoia de retestare. Avem cele 500 de ore de lucru, si le-am folosit pe diferitele dorinte ale clientului. Dar rezultatul este dezastruos. Testele fie sunt oprite, fie sunt facilitate pe pierdere. Iar caliyatea produsului este imprevizibila.
Exemplul numarul 3: Am estimat 500 de ore de testare si am primit aprobare pentru ele. Avem o echipa si incepem sa testam fara sa ne gandim la obiective si prioritati. Dar cele 500 de ore s-au dus. Unele functionalitati au fost testate, altele nu. S-au scris unele scripturi de testare automatizata care nu functioneaza dar exista. Testarea regresiva prin automatizare poate sa consume foarte multe resurse fara a face nimic. Testarea este fie oprita, fie continua in pierdere. Calitatea produsului este imprevizibila.
Exemplul numarul 4: Toti software testerii din companie sunt adusi in proiect pentru a face testare. Poate nu avem experienta in test design, dar avem un numar mare de testeri juniori care sunt dispusi sa lucreze in weekend. Testarea este finalizata exact in ziua in care proiectul ar trebui sa se incheie. Dumnezeu stie ce rezulta la final. In functie de ce noroc avem. De obicei nu unul foarte bun. Calitatea produsului este imprevizibila.
Versiunea 2.0 pe scurt
Hai sa ne uitam un pic la diferentele dintre versiunile 1.0 si 2.0. Din pacate versiunea 1.0 este paradigma in care multi dintre noi lucreaza in ziua de azi. Am primit anumite resurse si acum trebuie sa producem un anumit rezultat. De ce sunt lucrurile asa? Pentru ca stim cum sa utilizam aceste resurse. Spre exemplu stim ca undeva la 200 de ore din cele 500 de ore vor fi utilizate pentru scrierea test cases, 100 pentru teste automatizate si 200 pentru testare manuala. Dar toate aceste lucruri se intmpla intr-o lume ideala, unde nu sunt schimbari radicale si unde testerii software lucraza ca la carte. Si daca daca justificam estimarea noastra si aratam ca este realistica si eficienta si evaluam riscurile, atunci suntem responsabili pentru ea.
In cele din urma avem un plan stabilit. Un plan fix pe care incercam sa il respectam. In versiunea 2.0 ar trebui sa folosim eforturile de testare eficient pe baza unei analize a situatiei proiectului. Ar trebui sa scriem test cases? Daca raspunsul este da, atunci care? Ce date legate de testare fom folosi si de unde le obtinem?
De la client? De la noi? De ce tip de software testeri avem nevoie — o mana de oameni cu experienta (si scumpi) sau un grup mai mare cu mai putina experienta (si implicit mai ieftini). Avem nevoie de o echipa stabila pentru acest proiect sau nu? Avem nevoie de automatizare, si daca da, de ce instrumente si care este gradul de acoperire de care este nevoie?
In timp ce pentru versiunea 1.0 principalul criteriu este (ROI), in versiunea 2.0 principalul criteriu este maximizarea profitului. Doua lucruri diferite.
Punctele principale
- Testarea exhaustiva este imposibila
- Testarea software, impreuna cu multe alte lucruri, este o activitate economica
- Versiunea 1.0 inseamna ca lucram pe baza unui plan si a unei estimari; daca ne lipsesc resurse le cerem (o abordare extensiva)
- Versiunea 2.0 inseamna ca lucram pe baza unui plan si a unei estimari cat mai eficient posibil (abordare intensiva)
Vrei sa incepi o cariera in testare software sau sa iti imbunatatesti abilitatile de testare software? Descopera cursurile noastre.
Originally published at https://www.luxoft-training.ro.
