Testarea software. Intrebari tipice si raspunsuri
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.
21 Dec 2021
646
Other articles
Object-relational Mapping folosind JPA, Hibernate si Spring Data JPA. Persistence cu JPA
Cum sa interogam Kafka Streaming Data?
Procrastinarea. Care sunt avantajele ei?
Object-relational Mapping folosind JPA, Hibernate si Spring Data JPA
Procrastinarea
Cerinte. De ce avem nevoie de ele?
Dezvolta-ti abilitatile cu training-urile noastre
Programarea reactiva Java. Implementari
Testarea software. Intrebari tipice si raspunsuri. Continuare
Programarea reactiva Java. Reactive Streams spec
Intrebare
Raspuns
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
Raspuns
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
Raspuns
Depinde de cat de granulara e planificarea. Daca planifici pe ore, da. Daca planifici pe zile, nu.
Intrebare
Raspuns
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
Alexandr Alexandrov
Software Testing Consultant