'Y'

Cele mai comune greseli ale testerilor incepatori - partea 2

In prima parte a articolului am vorbit despre scrierea unor descrieri corecte legate de bug-uri. In cea de-a doua parte, vom analiza cateva bune practici despre cum sa imbunatatim modul in care scriem un rezumat legat de defecte.

Aug 8, 2018 1035
In prima parte a articolului am vorbit despre scrierea unor descrieri corecte legate de bug-uri. In cea de-a doua parte, vom analiza cateva bune practici despre cum sa imbunatatim modul in care scriem un rezumat legat de defecte.

Fiti concisi, dar nu prea mult.

Nu uitati ca rezumatul este o descriere scurta, asa incat nu trebuie sa scrieti un eseu in acel camp. In general, 7-10 cuvinte sunt fi suficiente (excluzand prepozitiile si articolele. Dar nu exagerati nu veti putea descrie in mod clar un bug cu 1-3 cuvinte)

2. Scapati de cuvintele de umplutura, nu va agitati.

De exemplu: Deschiderea fiecarei noi imagini atunci cand se vizualizeaza pe un tab nou.

Prea multe cuvinte, dar doar un simptom este descris si nu neaparat foarte clar.

Iar aici ideea este ca atunci cand se da clic pe fiecare imagine, aceasta se va deschide intr-un tab nou, ceea nu este foarte convenabil si nu indeplineste asteptarile rezonabile ale utilizatorilor. Acelasi lucru ar putea fi exprimat intr-o maniera mai scurta si mai clara: La clic, fiecare imagine se deschide intr-un tab nou."

De asemenea, ar fi bine sa se precizeze in ce sectiune a site-ului se petrece aceasta (evident ca nu in fiecare).

Alt exemplu:

La intrarea in sectiunea de achizitii de pe site, se produce eroare atunci cand incerc sa ofer feedback.

Apropiindu-ma de gara, mi-a zburat palaria. Evitati sa folositi exprimari ciudate, neclare. Daca va simtiti nesiguri cu acest tip de fraze, nu le folositi. Si mai bine, evitati constructiile anevoioase.

pe site" este total inutil. Toate bugurile care apar in softul produsului sunt legate de acel site, asadar de ce sa il mai mentionati in descrierea defectului?

Eliminare:

Eroare atunci cand incerc sa ofer feedback." Apropo, ce tip de eroare? Ar fi bine sa fie identificata cumva clasa, cod Nu este nevoie sa fie reprodus tot mesajul de eroare in raportul despre bug.

Raportarea cu titluri obscure a bugurilor creaza dificultati chiar si testerilor. Inainte de inregistrarea unui bug, ar trebui sa cautati in sistemul de monitorizare a bugurilor pentru a va asigura ca nu este o dublura. .. Pentru asta, avem nevoie de titluri scurte, clare si fara ambiguitati despre defecte.

2. Absenta rezultatelor asteptate

Atunci cand testerii inregistreaza un defect, ei au cu siguranta o idee despre ceea ce ar trebui sa fie corect. Dar exista o capcana: dezvoltatorii, ca toti ceilalti oameni, nu ghicesc gandurile! Iar, daca rezultatele asteptate nu sunt descrise explicit, exista intotdeauna un risc de neintelegere.

Mai este si un alt risc. Dezvoltatorul poate sa isi traga propriile concluzii despre ceea ce ar trebui sa fie corect, apoi sa repare codul si sa il trimita la verificare. Si, atunci, sa apara controverse: Este corectat! Nu, nu este! - Dar am facut schimbari aici! Nu era nevoie sa faceti! Prin urmare, ati irosit timpul si efortul mai multor oameni..

Ar fi mult mai usor sa se explice chiar de la inceput ce rezultate asteptati. Chiar daca ele par evidente si clare pentru toti. Una dintre legile lui Murphy spune, Tot ceea ce poate fi inteles gresit, va fi inteles gresit." As sfatui testerii incepatori sa isi faca obiceiul de a descrie mereu, intr-o maniera explicita, rezultatele asteptate. (Ar fi chiar mai bine daca v-ati sustine descrierea printr-o referire la o cerinta specifica.)

Cele mai comune greseli ale testerilor incepatori - partea 2.jpg


3. Etape de reproducere necorelate

Chair daca este de bun simt prefer sa spun. Descrieti etapele pas cu pas: un rand o etapa, numerotat sau nu, cum doriti. Nu scrieti totul intr-un paragraf lung, in care puneti la gramada cand, in timp ce, cine, atunci, etc. Citirea unei astfel de fraze lungi si sofisticate poate face dificila reproducerea bugului. Chiar si un lucru simplu poate fi complicat in exces, daca il descrieti asa:

Atunci cand cumparam diverse produse, in momentul in care apasam tasta cumpara, apare o fereastra pop-up, care atunci cand este apasata pentru a continua cumparaturile, se duce pe pagina de comenzi"

Acesta poate fi descris in felul urmator:

Tasta de Continuare cumparaturi redirectioneaza la pagina de Comenzi

Bineinteles ca apasarea tastei nu trebuie sa va redirectioneze catre pagina de comenzi, utilizatorul ar trebui sa ramana pe pagina initiala ca sa continue cumparaturile. Astfel de detalii pot fi specificate in descriere.

4. O captura de ecran in loc de rezultatul actual

Bineinteles ca este foarte util sa se adauge capturi de ecran la descrierile defectului, in special in cele care descriu probleme UI. Dar! Nicio captura de ecran nu ar putea inlocui o descriere textuala inteligibila.

Rezultat actual: Solicitare esuata de validare (a se vedea captura de ecran)"

Nu ar trebui facut asa. Tinand cont de experienta pe care o am, as spune ca este extrem de rara o situatie in care sa nu poti descrie in cuvinte rezultatul real. Da, am intalnit cateva bug-uri care aveau nevoie de video pentru a ilustra problema. Dar asta s-a intamplat doar de cateva ori in 10 ani. Daca intampinati dificultati, atunci poate nu intelegeti bine ce se intampla. Intotdeauna, o captura de ecran este o sursa suplimentara de informatii.

Apropo, in acest caz, daca din anumite motive, nu ati reusit sa faceti captura, ar fi imposibil sa aflam despre ce este vorba in acel bug.

Uneori, chiar si o captura trebuie sa fie imbunatatita, cu atat mai mult daca interfata este complexa. Ocazional, trebuie sa verifici amanuntit si indelung captura de ecran pentru a vedea unde este bugul, Desenati o sageata, un cerc sau subliniati-l pentru a indica locul in care apare bugul. Sau poate ar fi mai bine sa se scoata toate elementele inutile si sa ramana doar cele care sunt utile pentru a arata bugul.

In general, testarea poate fi considerata ca un serviciu de informare: sarcina noastra este sa oferim informatii clare si impartiale despre calitatea produsului. Pentru a identifica un bug nu este de ajuns; trebuie sa-l si descrieti in mod corect. Prin urmare, testerii trebuie sa poata sa isi exprime ideile logic, intr-o maniera usor de inteles, in cateva cuvinte dar cu acuratete.

Va urma ...

Victoria Slinyavchuk
Consultant on Software Testing

Daca iti place acest articol, distribuie-l si prietenilor tai!




Mai ai intrebari?
Contacteaza-ne.
Thank you.
Your request has been received.