Cele mai comune greseli ale testerilor incepatori – prima parte
Cele mai comune greseli ale testerilor incepatori – prima parte
Cei care se afla la inceputul carierei de software tester fac de multe ori cateva greseli tipice, pe care as vrea sa le analizez in acest articol si sa ofer cateva sfaturi despre cum pot sa fie evitate.
17 Jan 2017
7720
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
Testarea software. Intrebari tipice si raspunsuri
Cei care se afla la inceputul carierei de software tester fac de multe ori cateva greseli tipice, pe care as vrea sa le analizez in acest articol si sa ofer cateva sfaturi despre cum pot sa fie evitate.
In primul rand as vrea sa abordez problema documentarii defectelor. Din moment ce aceasta este cea mai comuna activitate a procesului de testare, orice tester trebuie sa fie capabil sa documenteze bug-uri corect. Ne putem descurca fara test cases, dar nu fara defecte.
1. Rezumat “gol”
S-ar scris destule articole despre ce ar trebui si nu ar trebui sa fie scris in titlurile defectelor, dar cei aflati la inceput fac cateva greseli specifice. O recomandare de bun simt este ca titlul defectului ar trebui sa raspunda la trei intrebari (Ce? Unde? Cand?). Sfatul este foarte bun dar de ce este atat de dificil sa fie urmat?
Primul lucru pe care ar trebui sa il avem in minte este ca titlul defectului trebuie sa descrie inima problemei. De multe ori facem asta cu o propozitie scrisa conform regulilor gramaticale specifice limbii pe care o folosim.
In general, o descriere scurta (rezumat) al unui defect trebuie sa raspunda la urmatoarea intrebare “Ce este in neinregula?” sau cu alte cuvinte “Despre ce problema este vorba?”. Titlul in sine trebuie sa contina indeajuns de multa informatie ca cel care il citeste sa isi faca o idee despre problema. Pentru a face acest lucru usor de inteles, cel putin in termeni generali, ar trebui sa raspundem la fiecare dintre cele trei intrebari de mai jos:
Puteti sa exersati asta uitandu-va in descrieri ale defectelor pentru a vedea daca ele reflecta esenta problemei.
“Cautare incorecta pe website”
Despre ce este vorba in aceasta descriere? Putem sa vedem ca defectul este legat intr-un fel de o anumita functionalitate, mai exact functia de cautare pe site. Raspunde la intrebarea “Unde?”. Dar ce este in neinregula cu functia de cautare? Cum se manifesta acest defect? De asta nu ne putem da seama. Sub ce conditii putem reproduce defectul? Nici la aceasta intrebare nu avem un raspuns.
Iata un alt sumar al aceluiasi bug: “Rezultatul actiunii unui camp gol de cautare pe site”.
Parca ne apropiem... Putem sa intelegem la ce functie se refera bug-ul si chiar sa identificam conditiile sub care il putem reproduce. Dar nici un raspuns legat de ce nu merge cum trebuie. Doar “Rezultatul...” – un rezultat fara elemente specifice... Si asta ar trebui sa conteze!
Pentru a intelege o problema, trebuie sa intelegem toata descrierea si sa putem reproduce bug-ul. In cazul unei cautari unde campul de cautare este gol, in fata listei de produse apare o fereastra category view unde o imagine este prea mare si nu respecta UI. Putem sa descriem pe scurt asta in rezumat dupa cum urmeaza:
“Dupa ce am dat search cu casuta goala apare o imagine prea mare in “category-view” div.”
Bineinteles ca un screenshot ar trebui sa fie atasat.
Un alt exemplu:
“comentariu”
Da, doar atat... Un cuvant care face trimitere la o arie functionala.
Ar putea sa fie mai usor de inteles daca l-am scrie ca mai jos:
“Fatal error: 463 atunci cand incerc sa postez un review pe pagina cu descrierea produsului.”
“broken layout”
Aceasta descriere este un simptom, un comportament incorect, asa ca poate sa fie vazut ca un raspuns (unul destul de general) al intrebarii “Ce (se intampla)?”. Dar unde se intampla exact? Pe ce pagina? Pe fiecare pagina? Nu este clar. Si ce ar trebui facut ca sa ajungem la acest rezultat? Acest lucru nu apare.
Descrierea corecta ar trebui sa fie:
“Pe imaginile unde dam 150% zoom toate paginile sunt suprapuse.”
Si inca un exemplu:
“Inregistrare cu email invalid.”
Poate ca acest titul ar parea mai degraba ca test case. Stim clar la ce functie se refera bug-ul – “inregistrare” si stim care este factorul declansator – “email invalid” (desigur si aici ar trebui sa clarificam ce insemna email invalid). Dar ce inseamna acest bug?
O descriere mai corecta ar fi:
“Inregistrarea este posibila cu adresa de mail invalida”
Sau
“Email-ul nu este validat la inregistrare.”
In cea de-a doua parte a acestui articol vom discuta despre cateva sfaturi legate de scrierea unor rezumate de bug-uri.
Victoria Slinyavchuk
Consultant on Software Testing
In primul rand as vrea sa abordez problema documentarii defectelor. Din moment ce aceasta este cea mai comuna activitate a procesului de testare, orice tester trebuie sa fie capabil sa documenteze bug-uri corect. Ne putem descurca fara test cases, dar nu fara defecte.
1. Rezumat “gol”
S-ar scris destule articole despre ce ar trebui si nu ar trebui sa fie scris in titlurile defectelor, dar cei aflati la inceput fac cateva greseli specifice. O recomandare de bun simt este ca titlul defectului ar trebui sa raspunda la trei intrebari (Ce? Unde? Cand?). Sfatul este foarte bun dar de ce este atat de dificil sa fie urmat?
Primul lucru pe care ar trebui sa il avem in minte este ca titlul defectului trebuie sa descrie inima problemei. De multe ori facem asta cu o propozitie scrisa conform regulilor gramaticale specifice limbii pe care o folosim.
In general, o descriere scurta (rezumat) al unui defect trebuie sa raspunda la urmatoarea intrebare “Ce este in neinregula?” sau cu alte cuvinte “Despre ce problema este vorba?”. Titlul in sine trebuie sa contina indeajuns de multa informatie ca cel care il citeste sa isi faca o idee despre problema. Pentru a face acest lucru usor de inteles, cel putin in termeni generali, ar trebui sa raspundem la fiecare dintre cele trei intrebari de mai jos:
- “Ce?” – trebuie descris comportamentul programului care este in opinia noastra incorect sau nu respecta cerintele/standardele/asteptarile. Cu alte cuvinte acesta este un simptom.
- “Unde?” – in ce zona a sistemului sau produsului (modul, pagina, functie). Aceasta ar fi locatia.
- “Cand?” – sub ce conditii poate sa fie reprodus defectul. Acesta este un factor declansator.
Puteti sa exersati asta uitandu-va in descrieri ale defectelor pentru a vedea daca ele reflecta esenta problemei.
“Cautare incorecta pe website”
Despre ce este vorba in aceasta descriere? Putem sa vedem ca defectul este legat intr-un fel de o anumita functionalitate, mai exact functia de cautare pe site. Raspunde la intrebarea “Unde?”. Dar ce este in neinregula cu functia de cautare? Cum se manifesta acest defect? De asta nu ne putem da seama. Sub ce conditii putem reproduce defectul? Nici la aceasta intrebare nu avem un raspuns.Iata un alt sumar al aceluiasi bug: “Rezultatul actiunii unui camp gol de cautare pe site”.
Parca ne apropiem... Putem sa intelegem la ce functie se refera bug-ul si chiar sa identificam conditiile sub care il putem reproduce. Dar nici un raspuns legat de ce nu merge cum trebuie. Doar “Rezultatul...” – un rezultat fara elemente specifice... Si asta ar trebui sa conteze!
Pentru a intelege o problema, trebuie sa intelegem toata descrierea si sa putem reproduce bug-ul. In cazul unei cautari unde campul de cautare este gol, in fata listei de produse apare o fereastra category view unde o imagine este prea mare si nu respecta UI. Putem sa descriem pe scurt asta in rezumat dupa cum urmeaza:
“Dupa ce am dat search cu casuta goala apare o imagine prea mare in “category-view” div.”
Bineinteles ca un screenshot ar trebui sa fie atasat.
Un alt exemplu:
“comentariu”
Da, doar atat... Un cuvant care face trimitere la o arie functionala.
Ar putea sa fie mai usor de inteles daca l-am scrie ca mai jos:
“Fatal error: 463 atunci cand incerc sa postez un review pe pagina cu descrierea produsului.”
“broken layout”
Aceasta descriere este un simptom, un comportament incorect, asa ca poate sa fie vazut ca un raspuns (unul destul de general) al intrebarii “Ce (se intampla)?”. Dar unde se intampla exact? Pe ce pagina? Pe fiecare pagina? Nu este clar. Si ce ar trebui facut ca sa ajungem la acest rezultat? Acest lucru nu apare.
Descrierea corecta ar trebui sa fie:
“Pe imaginile unde dam 150% zoom toate paginile sunt suprapuse.”
Si inca un exemplu:
“Inregistrare cu email invalid.”
Poate ca acest titul ar parea mai degraba ca test case. Stim clar la ce functie se refera bug-ul – “inregistrare” si stim care este factorul declansator – “email invalid” (desigur si aici ar trebui sa clarificam ce insemna email invalid). Dar ce inseamna acest bug?
O descriere mai corecta ar fi:
“Inregistrarea este posibila cu adresa de mail invalida”
Sau
“Email-ul nu este validat la inregistrare.”
In cea de-a doua parte a acestui articol vom discuta despre cateva sfaturi legate de scrierea unor rezumate de bug-uri.
Vrei sa incepi o cariera in testare software? Descopera cursurile noastre.
Victoria Slinyavchuk
Consultant on Software Testing