Tester vs. Developer Ц partea 2

In prima parte a articolului am discutat despre relatia dintre testeri si programatori si am explorat diferite strategii pentru a imbunatatii comunicarea intre cele doua roluri Ц in special pe partea de soft skills. In cea de-a doua parte ne vom uita la modalitati de a imbunatatii aspectele de feedback tehnic.

Dec 13, 2016 2220
In prima parte a articolului am discutat despre relatia dintre testeri si programatori si am explorat diferite strategii pentru a imbunatatii comunicarea intre cele doua roluri Ц in special pe partea de soft skills. In cea de-a doua parte ne vom uita la modalitati de a imbunatatii aspectele de feedback tehnic.

Bug-uri dubioase

Neintelegeri si chiar conflicte pot avea loc intre testeri si programatori legate de bug-uri. Uneori programatorii resping un defect sau au un feedback negativ legat de modul in care este descris. Este acum randul testerilor sa fie capabili sa primeasca critici intr-un mod adecvat si constructiv. Haideti sa ne uitam la cateva situatii tipice.

BUGSPHEMY Ц O ACTIUNE, CUVANT SAU INTENTIE LIPSITA DE RESPECT CU PRIVIRE LA UN BUG PE CARE L-AI DESCRIS.

УNu este un bug, este un feature.Ф

Probabil ca fiecare tester s-a confruntat cu o asemenea situatie. Tu crezi ca este un bug dar developerul nu este de aceeasi parere. Ce ar trebui sa faci? Vei fi de acord sau nu?

Poate ca nu ai oferit destule dovezi ca exista cu adevarat un bug. Gandeste-te ce caracteristici il fac cu exactitate un bug. Reia test basis, citeste din nou cerintele si analizeaza matricea de trasabilitate (traceability matrix). Poate dupa ce vei parcurge din nou toate aceste aspecte vei cadea de acord cu programatorul. Daca in continuare nu esti de acord cauta mai multe argumente pentru a-ti sustine punctul de vedere.

Se intampla in anumite cazuri ca atat testerul cat si programatorul sa fi citit aceleasi documente dar sa inteleaga diferit ce trebuie sa se intample. Intrebarea ramane: cine a inteles corect si cine a inteles gresit. S-ar putea ca ambele persoane au inteles gresit. Acest lucru trebuie sa fie clarificat fata in fata. Daca nu se ajunge la un acord implicati si alte persoane Ц analistul de business, managerul de proiect sau orice alta persoana a carei autoritate este recunoscuta de amandoi.

Tester vs Developer_2.jpgУNu poate sa fie reprodusФ

Nu exista tester care sa accepte o situatie unde primeste un asemenea raspuns. Este nevoie de aprofundare. Poate sa fie un indiciu care sa iti arate ca problema poate sa tina de mediul de dezvoltare.

Poate ca programatorul a verificat in alta versiune Ц unde s-au facut deja schimbari. Acest lucru ar trebui clarificat.
Este de asemenea posibil sa fi omis sa descrii pasii indeajuns de in detaliu sau ai uitat sa mentionezi o preconditie. Sau bug-ul nu este intotdeauna reproductibil dar nu ai observat asta. Aceasta este o alta situatie care nu este placul nimanui...

Cu toate astea trebuie sa gasesti o solutie. Dar argumentul Уmerge pe calculatorul meuФ este unul slab si nu poate sa fie folosit ca o scuza pentru a nu rezolva bug-ul. Daca bug-ul poate sa fie reprodus in versiunea de testare si in mediul tau de testare, trebuie sa insisti. Adauga dovezi precum screenshot-rui sau log-uri. In cazuri mai complexe s-ar putea sa ai nevoie de extended logging.

Tester vs Developer_3.jpgO descriere incorecta a unui defect

O descriere incorecta a unui defect poate sa cauzeze conflicte legate de un bug. Criteriul legat de Уrezultatele asteptateФ este de cele mai multe ori omis. Programatorul se uita la specificatii si nu intelege de ce este un bug. Ce este corect? La ce te-ai asteptat? Adauga de fiecare data si aceasta informatie chiar daca pare triviala. Nu dureaza mult dar ajuta la clarificarea situatiei.

Prioritati gresite

Atunci cand un bug este etichetat cu un nivel excesiv de severitate pot aparea probleme. Cand programatorii primesc un bug cu eticheta Уgrad de severitate: criticФ de cele mai multe ori lasa totul deoparte si incep sa se uite la problema. Daca se dovedeste ca aceasta severitate nu este atat de critica pe cat s-a spus, este de inteles de ce vor aparea situatii neplacute Ц ai intrerupt munca cuiva pentru ceva minor. Onestitatea este importanta pentru testeri. Nu supraestimati severitatea bug-urilor! Dar nici nu trebuie sa o subestimati altfel riscati neglijarea problemelor critice.

Pentru a evita aceste situatii este important sa avem o clasificare general acceptata cu privire la severitate intre testeri si developeri. Puteti sa folositi un sistem standard sau sa dezvoltati voi unul Ц singurul lucru care conteaza este sa fie agreat de toata lumea.

Nu este specificat daca poate sa fie reprodus

Conflicte pot aparea si atunci cand in descrierea bug-ului nu este indicat faptul ca nu poate sa fie reprodus de fiecare data. Si daca severitatea este si mai are atunci situatia este si mai complicata.
Reproducerea, ca un camp standard in descrierea defectului, nu apare in toate sistemele de bug tracking. Este in Mantis, spre exemplu. Acolo poti sa alegi una din optiunile de mai jos:
  • Always
  • Sometimes
  • Random
  • Have not tried
  • Unable to duplicate

Este util sa adaugam un asemenea camp in bug tracker. Chiar daca nu ai un asemenea camp indica in descriere daca defectul poate sa fie reprodus Ц atunci cand nu apare de fiecare data.

O alta optiune este sa iti atribui tie task-ul mai intai si sa continui sa il testezi pana cand reusesti sa descoperi anumite aspecte care au loc regulat si/sau strangi destule informatii despre comportamentul defectului.

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.