10 reasons why your bugs are getting rejected
Nu am de gând să o cruț. Am respins 7 erori, în ultimele trei zile. Știu că folosește resentimente personale ca sabie profesională ……
Un coechipier fumegea și discuția a luat brusc foc atunci când alți doi coechipieri s-au alăturat împărtășind aceeași experiență cu alți dezvoltatori. Reuniunea echipei a transformat un punct de discuție despre respingerea erorilor. După o discuție, am decis cu toții să facem un exercițiu simplu pentru a ne salva de umilința bugului respins, în viitor.
Fiecare dintre noi a început să scoată notițe ca motive pentru respingerea erorilor pentru ultimele 10 erori, raportate și respinse. Lista acestor note de respingere s-a dovedit utilă pentru a înțelege urmărirea viitoare a raportării erorilor și care a fost presupunerea greșită.
Respingerea erorilor și motivele din spatele acesteia
În loc să dezvăluie lista, aș dori să împărtășesc punctele rezultate ale listei. Iată-l -
# 1) Înțelegerea greșită a cerințelor:
Din orice motiv, dacă nu ați înțeles cerința în mod corespunzător, veți căuta cu siguranță cerința interpretată greșit în implementarea efectivă și atunci când nu o veți găsi, ar fi o eroare conform dvs., care va fi în cele din urmă respinsă.
Exemplu din viața reală : După ce ați testat o rețetă, ați constatat că nu are gust, deoarece sarea nu a fost adăugată, dar nu știați că sarea ar trebui să fie adăugată în momentul servirii, altfel poate afecta aspectul rețetei.
# 2) Implementarea cerinței:
Ca parte a unei discuții anterioare, ați fost conștient de faptul că cerința specifică va fi implementată în mod XYZ. Dar, în timpul dezvoltării, dezvoltatorul a constatat că nu este posibil să urmeze calea XYZ și astfel a urmat calea ABC și asta nu ți-a fost comunicat.
În cele din urmă, veți raporta o eroare atunci când ați constatat că cerința nu a fost implementată așa cum a fost discutată.
Exemplu din viața reală : Ai cerut croitorului să pregătească o cămașă și când ți s-a cerut procesul, l-ai respins spunând că nu ai găsit nasturi. Când croitorul explică faptul că punerea butoanelor pe partea din față ar fi afectat aspectul general al cămășii și, prin urmare, ar fi pus-o în interiorul marginii frontale, cu siguranță ai fi uimit.
# 3) Nu există cerințe clare:
Atunci când nu există cerințe clare disponibile, toată lumea este liberă să-și asume cerința în felul său, ceea ce duce la o presupunere la nivel personal. Când vedeți că presupunerea personală nu este satisfăcută, o marcați ca o eroare.
Exemplu din viața reală : Trebuie să desenați un ciclu când profesorul a anunțat că se aștepta ca elevii să deseneze o bicicletă. După o jumătate de oră, când a verificat desenul tuturor, nu a găsit pe nimeni care să se potrivească cu așteptările ei. Toată lumea a luat declarația vagă în felul său și rezultatul a fost un triciclu, ciclul bebelușului, prea multe cicluri, ciclul cu scaunul cu rotile și așa mai departe.
# 4) Modificarea cerinței:
Un alt exemplu de comunicare greșită, de cele mai multe ori. Când testerii nu sunt informați cu privire la modificările cerințelor, vor fi raportate mai multe erori și în cele din urmă respinse.
Exemplu din viața reală : Cu siguranță veți respinge sandvișul atunci când îl veți folosi mai degrabă decât pâine cu miere decât pâine cu banane pe care ați comandat-o. Cel puțin știați că partenerul dvs. a schimbat tipul de pâine pentru comandă în timp ce erați la telefon și, bineînțeles, el / ea nu a considerat necesar să o împărtășească cu dvs.
# 5) Înțelegerea domeniului:
În timpul testării, începeți să testați ceva care nu trebuie considerat ca testabil la un anumit punct sau care nu este deloc acoperit de criteriile de produs; vei fi o victimă a respingerii erorilor.
cum deschid fișierul a.swf
Exemplu din viața reală : Ar trebui să măturați o cameră și acesta este singurul obiectiv. Totuși, dacă vă plângeți de mizeria din celelalte zone, cu siguranță veți fi ignorat.
# 6) Mediul de testare:
O aplicație / produs este o combinație de multe cerințe hardware și software - atât majore cât și minore, și atunci când nu se utilizează un mediu de testare adecvat sau lipsește ceva din mediul de testare, aplicația / produsul se blochează și se raportează o eroare critică ...
Ce se întâmplă în continuare este - investigații aprofundate, deoarece de cele mai multe ori, neintenționat, nu avem grijă să oferim detalii minore despre mediul de testare pe care l-am folosit și care sporește munca dezvoltatorului. În cele din urmă, bug-ul este respins.
Exemplu din viața reală : Acele brioșe delicioase pe care le-ai gustat în casa unui prieten înainte de câteva zile au fost grozave și după ce ai urmat rețeta brioșele nu erau nici mai aproape de cea pe care o aveai.
Ei bine, nu trebuia să folosești unt învechit deoarece untul proaspăt nu era disponibil, nu trebuia să adaugi un vârf de făină de gram, deoarece ai crezut că ar putea adăuga gustul, nu trebuia să-l gătești pe tigaie ca cuptorul. a fost defect.
Lectură recomandată => Cum să pregătiți eficient „mediul de testare”.
# 7) Date de test utilizate:
Datele de testare utilizate pentru testare nu corespundeau cu o cerință.
Exemplu din viața reală : Chiar și după ce ați știut că calculatorul este util pentru procesarea numerică dacă încercați să adăugați caractere speciale și când calculatorul răspunde în mod neașteptat, credeți că a fost incorect. Într-adevăr?
Lectură recomandată => Sfaturi pentru proiectarea datelor de testare și Testarea tehnicilor de gestionare a datelor .
# 8) Eroare duplicat:
Cineva a raportat deja același bug și nu ați avut grijă să verificați același bug înainte de a raporta bug-ul. Din nou respingere.
Exemplu din viața reală: Persoana de asistență pentru clienți nu va fi fericită atunci când va primi mai multe apeluri de reclamații pentru același produs de la fiecare membru al familiei. S-ar gândi că nu era suficient un singur telefon.
tehnician de birou de asistență intervievează întrebări și răspunsuri
# 9) Descriere incorectă a erorilor:
Când dezvoltatorul nu reușește să înțeleagă ce ați încercat să transmiteți prin raportul de erori, așteptați-l să fie respins deoarece sunt încărcați și cu alte sarcini și când nu găsesc descrierea corectă și detaliile necesare în raportul de erori, indiferent de modul în care critic este bug-ul, se așteaptă să fie marcat ca Respins.
Lectură recomandată => Cum se scrie un raport bun de eroare? Sfaturi și trucuri.
Exemplu din viața reală: Trebuie să deblocați mașina, ar trebui să vă așezați și ar trebui să începeți prin mișcarea tastelor în sensul acelor de ceasornic .... mașina nu a pornit și astfel vă supărați. Nu ați fost instruit să verificați benzina? O, o greșeală în manual, deoarece a presupus că veți înțelege cu siguranță că ar trebui să fie verificat implicit.
# 10) Bug-uri nereproductibile:
În timp ce raportați o eroare, nu ați realizat niciodată importanța reproductibilității erorii. Doar asigurându-vă dacă eroarea este reproductibilă întotdeauna sau apare aleatoriu, puteți economisi ore de muncă și încă o eroare respinsă.
Exemplu din viața reală: Ce ar verifica medicul atunci când vă plângeți de frigul aspru, dar acesta nu găsește niciun simptom. Oh, doar strănuteam tare , nu va îmbunătăți situația.
Concluzie
De cele mai multe ori, natura noastră umană ne permite să gândim negativ atunci când eroarea raportată este respinsă. Într-adevăr, dezvoltatorii nu văd un motiv specific pentru a respinge eroarea dacă este validă.
Deci, data viitoare, vă rugăm să nu vă concentrați asupra numărului de erori. Concentrați-vă asupra erorilor calitative cu detalii adecvate, deoarece în cele din urmă ceea ce contează este modul în care ați ajutat la îmbunătățirea calității produsului și nu câte erori ați raportat.
De asemenea, citiți => Cum să vă rezolvați toate erorile fără eticheta „Eroare nevalidă”?
Despre autor: Acest articol util este scris de membrul echipei STH Bhumika Mehta. Ea este un lider de proiect care are peste 7 ani de experiență în testarea software-ului.
Testare fericită! Ca de obicei, așteptăm opiniile dvs. despre același lucru.
Lectură recomandată
- Cum să vă rezolvați toate erorile fără eticheta „Eroare nevalidă”?
- De ce raportarea erorilor este o artă care ar trebui învățată de fiecare tester?
- Arta de raportare a erorilor: Cum să comercializați și să vă remediați erorile?
- De ce software-ul are erori?
- 7 tipuri de erori software pe care ar trebui să le cunoască fiecare tester
- 11 moduri în care știi că ești tester ..
- Exemplu de raport de erori
- 5 moduri de a fi un tester de software îndrăzneț și sigur