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?

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.

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

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.

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

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.

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?

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.