Testarea software. Intrebari tipice si raspunsuri

Este timpul pentru inca un articol din seria noastra despre testarea software. In acest articol vom aborda o serie de intrebari tipice si raspunsuri care apar in acest proces.

Intrebare

Este util sa ramanem la estimarea initiala de 500 de ore de lucru? Sau mai bine agreem estimarile oferite de manager, trasnferand astfel responsabilitatea catre el?

Raspuns

Sa nu ne amagim cu faptul ca transferam responsabilitatea. Daca ai agreat 300 de ore in loc de 500, atunci iti asumi responsabilitatea pentru testarea tuturor functionlitatilor in acest interval. Clientul va veni si v-a intreba: Unde sunt rezultatele pe care le-ai promis? Ai spus ca vei testa TOT in 300 de ore, si ca nu vor mai fi defecte. Dar inca exista defecte. Pentru ce te-am platit?

Daca stii cum sa faci testre software in 300 de ore, si 200 de ore sunt indeajuns, e ok. Altfel, stai pe un butoi cu pulbere.

Intrebare

Cat ne va lua sa stabilim o estimare pentru proiect si cine il o v-a face?

Raspuns

Nu iti ia foarte mult timp, dar trebuie sa intelegi ca fiecare companie are un anumit set de procese.

Legat de rol, de obicei estimarea este facuta de un test lead sau test manager. Dar uneori avem doar un singur tester in echipa — — un manager, lead, sau automation engineer — care va face estimarea. Legat de resurse, testarea software este facuta de cei care sunt calificati sa o faca.

Ca timp, estimrea poate sa ia de la 4 ore pana la 3 zile, daca proiectul este gestionabil. Daca proiectul este mare, asemenea estimari vor fi facute regulat, deoarece pot sa nu mai fie actuale. Nu are o durata atat de mare incat sa afecteze proiectul presupunad ca exista un proces de estimare deja existent. Daca o facem de fiecare data de la zero nu e bine.

Intrebare

Ar trebui sa includem o estimare a eforturilor de estimare in estimarea totala?

Raspuns

Depinde de cat de granulara e planificarea. Daca planifici pe ore, da. Daca planifici pe zile, nu.

Depinde, din nou, de complexitatea proiectului. Urmatoarea comparatie ar putea sa para ciudata dar este utila. Care este cea mai buna metoda de a saruta? In ce parte ne indoim capul? Ar trebui sau nu sa inchidem ochii? Dar criteriul este foarte simplu — cand doi oameni se saruta, important este ca amandurora sa le placa. Software development este ceva prea complex ca sa oferim raspunsuri simple.

Intrebare

Dupa cum mentionam mai sus, ar trebui sa comparam eforturile de munca si costurile cu potentialele probleme cauzate de faptul ca anumite defecte ar putea sa fie identificate in timpul utilizarii. Cum ar trebui sa evaluam impactul negativ al unui defect, in special daca nu l-am gasit inca?

Raspuns

Dupa cum urmeaza: noi gestionam defectele. Orice defect este de fapt un dezavantaj al unui risc. Riscul este ca am putea sa avem un defect in productie si apoi sa vedem ce inseamna: ar trebui sa stim indeajuns de bine business-ul clientului, si sa intelegm care ar fi pierderile financiare care ar putea sa apara daca o anumita functionalitate nu este disponbiila pentru o zi.

Aceasta evaluare poate sa fie foarte utila pentru justificarea costurilor testarii software. Cand clientul intreba, “De ce ar trebui sa alocam 500 de ore pentru testare?” tu poti raspunde, “OK. Reducem la 300. Aceasta functionalitate va avea probleme lunar, si sistemul o sa cada timp de 6 ore. Poti calcula cat de mult o sa va coste acest downtime?” Nu vrei sa platesti pentru 500 de ore, atunci o sa ai pierderi, care vor costa la fel de mult (de fapt mai mult decat cele 500 de ore).

Daca nu stim anumite detalii legate de business, putem intreba. Nu putem testa tot. Dar putem testa o mare parte din tot, si sa obtinem un anumit rezultat. Putem testa mai putin, si atunci s-ar putea sa fie alte consecinte. Cineva trebuie sa isi asume responsabilitatea pentru decizii legate de riscurile financiare. Sarcina noastra este sa indentificam acele riscuri si sa oferim optiuni.

Daca riscurile sunt identificate si evaluate corect (cu cifre, beneficii, costuri, pierderi), atunci putem sa vorbim pe acelasi limbaj cu clientul si top management-ul. Cu cat vorbim cu cineva mai sus in ierarhie, cu atat vor fi mai interesati de partea financiara si mai putin de tehnologii.

Spre exemplu, un contract pentru un proiect de testare software din care am facut parte spunea ca daca exista 6 defecte serioase in productie in urmatoarele 6 luni, vor exista penalitati echivalente cu pretul contractului de software development. Sase defecte pentru o solutie software complexa este ceva absolut realist. Este rezonabil sa ne asumam asemenea riscuri?

Vrei sa incepi o cariera in testare software sau sa iti imbunatatesti abilitatile de testare software? Descopera cursurile noastre.

Alexandr Alexandrov
Software Testing Consultant

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