3 worst defect reporting habits
Defectele sunt afaceri serioase, iar micile greșeli pot fi costisitoare.
Știi ce să faci când găsești un defect. Tu îl raportezi; fie într-un Urmărirea defectelor / Instrumentul de gestionare a defectelor sau într-o foaie Excel. Principiile de bază sunt aceleași pentru ambele metode.
Instrumentele de gestionare a defectelor nu garantează o raportare mai bună. Bunele practici salvează ziua.
Pentru a aprecia binele, trebuie să recunoaștem ceea ce nu este.
Ce veți învăța:
- 3 Cele mai grave obiceiuri de raportare a defectelor și modul de a le sparge
- # 1) Lene
- # 2) Graba
- # 3) Lipsa creativității
- Lectură recomandată
3 Cele mai grave obiceiuri de raportare a defectelor și modul de a le sparge
Iată:
# 1) Lene
Nu vă faceți timp pentru a face tot ce puteți.
Acesta este procesul de urmărire a defectelor urmat în majoritatea echipelor:
(Notă- faceți clic pe orice imagine pentru vizualizare mărită)
După cum puteți vedea, potențialul de testare examinează defectele înainte de a le trimite din echipele de asigurare a calității.
Această recenzie include confirmarea:
- Valabilitate - Este o eroare?
- Complet - Titlu, pași, date, captură de ecran etc.
- Dubluri
- Reproductibil sau nu ... etc.
Știu direct că este imposibil ca un client QA să fie 100% complet.
Deci, atitudinea: „Voi raporta problema așa cum îmi doresc. Conducătorul QA poate verifica din nou. El poate decide dacă defectul este valid / complet sau nu ”este sfârșitul credibilității echipei dvs. de asigurare a calității.
Știați că unii clienți au un SLA pentru numărul de defecte nevalide acceptabile? Odată ce numărul depășește, încep penalizarea contractanților pentru fiecare defect nevalid raportat?
Remediu: Faceți diligența și fiți responsabil pentru livrabil. A apărut un defect pentru că nu aveți suficiente informații sau că nu este un bug? Este posibil să nu fie întotdeauna vina echipei de dezvoltare. Nu este faptul că nu vor să dețină problemele din aplicație. Ar putea fi o adevărată încurcătură a echipei QA. Nu lăsa să se întâmple.
# 2) Graba
Să facem acest lucru cu unexemplu.
Mai jos este o captură de ecran a OpenEMR’s ecran create-pacient. Este un sistem open source de gestionare a spitalelor.
Acest ecran permite utilizatorului să introducă data nașterii pacientului printr-o funcție de calendar. Ceea ce nu face este să restricționeze intrarea la alegerea din calendar. Ceea ce vreau să spun este că poți alege DOB ca să zici „31-Mar-1983” din calendar. Mai târziu, schimbați-l în „31-Feb-1983”.
De ce 31 februarie? A implementa eroare de ghicit și încercați o dată negativă în teren; care este tot punctul de testare, nu-i așa?
Odată terminat, dau clic pe „Creează pacient”. Deoarece data nu este validă, mă aștept ca sistemul să afișeze o eroare și să nu creeze pacientul. Dar asta nu se întâmplă. Acesta creează pacientul ca mai jos.
Rețineți câmpurile Vârstă și Data nașterii în ecranul de mai jos:
Când testați, ați putea încerca acest lucru de câteva ori și puteți decide că:
- Este un bug.
- Este reproductibil.
- Nu este un duplicat (verificați cu echipa dvs. pentru a confirma)
- Cunoașteți descrierea exactă a problemei
- De asemenea, știți pașii exacți care o fac să se întâmple.
Acum, că aveți materia primă, sunteți bine să mergeți.
Începi să-l raportezi. Atribuirea severității defectelor este un pas obligatoriu și echipa dvs. ar putea folosi ceva similar cu următorul tabel de referință:
| Severitate | Impact |
|---|---|
| 1 (critic) | • Această eroare este suficient de critică pentru a bloca sistemul, a provoca corupția fișierelor sau a provoca pierderi potențiale de date • Provoacă o revenire anormală la sistemul de operare (apare un mesaj de avarie sau de eroare a sistemului). • Face ca aplicația să se blocheze și necesită repornirea sistemului. |
| 2 (ridicat) | • Provoacă lipsa funcționalității vitale a programului cu soluție. |
| 3 (mediu) | • Această eroare va degrada calitatea sistemului. Cu toate acestea, există o soluție inteligentă pentru realizarea funcționalității dorite - de exemplu printr-un alt ecran. • Această eroare împiedică testarea altor zone ale produsului. Cu toate acestea, alte zone pot fi testate independent. |
| 4 (scăzut) | • Există un mesaj de eroare insuficient sau neclar, care are un impact minim asupra utilizării produsului. |
| 5 (Cosmetic) | • Există un mesaj de eroare insuficient sau neclar care nu are niciun impact asupra utilizării produsului. |
Deoarece acest defect nu blochează sistemul sau nu blochează o funcționalitate vitală sau nu împiedică testarea celorlalte zone ale aplicației, s-ar putea să mergem cu „Low”.
Se pare că nu?
GRESIT. Din datele pacientului, toate imunizările și alte memento-uri sunt întârziate. Acest lucru poate fi sau nu corect. De asemenea, pentru un pacient, vârsta lor determină dacă vede un medic pediatru sau un medic general etc.
Afectează dozele de medicamente și multe alte domenii de tratament pe care poate nici nu le știm.
Deci, voi merge cu „Înalt”. Sunt de acord că este puțin probabil ca personalul spitalului să intre în DOB-ul unui pacient greșit. Dar lăsați-l să fie un factor care să afecteze prioritatea momentului în care să rezolvați problema.
Sarcina mea de tester este să mă asigur că comunic seriozitatea problemei cât mai bine posibil.
Remediu: Nu vă grăbiți să raportați. Fiți 100% sigur că înțelegeți impactul problemelor din mai multe unghiuri. Este cea mai bună valoare adăugată pe care o putem oferi testerii. Nu spunem doar „Ceva nu funcționează”. De asemenea, spunem „Iată ce se va întâmpla dacă acest lucru continuă să nu funcționeze”. Tone de diferență, nu-i așa?
# 3) Lipsa creativității
Testerii au o oportunitate minunată de a face sugestii pentru a îmbunătăți software-ul.
În dumneavoastră Instrument de gestionare a defectelor de asemenea, puteți trimite un defect de tip „Sugestie de îmbunătățire”. Aici puteți deveni creativi.
Remediu: Gandeste in afara cutiei. Dacă credeți că unei anumite caracteristici îi lipsește un factor „Wow” și știți cum să o aduceți în ea, prezentați ideea. În cel mai rău caz, ar putea fi respins și este în regulă. Partea importantă este încercarea.
De asemenea, utilizați această super putere cu precauție. Încercați să nu faceți comentarii precum „Urăsc culoarea bannerului, vă rugăm să o schimbați”.
Iată un bineexemplua unei sugestii de îmbunătățire pe care am întâlnit-o: Înlocuirea opțiunii „Trimiteți un e-mail către dealer” cu opțiunea „Chat cu dealerul” de pe un site de distribuție auto. Se estimează că va converti mai mult trafic în vânzări.
Mi-aș dori să fiu atât de creativ! Dar, poate că putem lucra cu toții în acest sens.
Iată un bonus. O listă de verificare pentru a elibera aceste obiceiuri proaste:
1. Titlul meu transmite problema în mod clar și concis?
De exemplu:„Creează pacientul nu funcționează” nu este un titlu bun. „Crearea pacientului eșuează chiar și atunci când toate câmpurile de introducere conțin valori corecte” este.
Două. Care este rata de reproductibilitate?
Cu alte cuvinte, se întâmplă întotdeauna? Știu secvența exactă a pașilor care vor repeta problema?
3. Această problemă este specifică platformei, browserului sau utilizatorului?
Patru. Pașii sunt completați și vă ajută să treceți la problema dvs.?
5 . Am o captură de ecran inclusă?
6. Trebuie să adnotez captura de ecran pentru a evidenția anumite zone?
7. Numele fișierului imagine atașat este descriptiv?
Nu folosiți ceva de genul „Untitled.jpg”. Dă-i un nume descriptiv.
8. Am inclus datele testului?
De exemplu:Pentru un defect într-un modul de administrare care are nevoie de acreditări de autorizare, includeți-le. Echipa de dezvoltare poate avea sau nu acces la mediul QA. Nu doriți o întârziere și o monitorizare a unui lucru la fel de simplu ca acesta.
9. Pot da alte detalii pentru a-mi întări defectul?
(Exemplu:o referință la FRD sau o conversație cu clientul etc.)
10. Înțeleg cât de gravă este problema din diferite perspective?
unsprezece. Știu cauza principală a problemei? Dacă da, am dovezi (poate fișiere jurnal) și pot să le includ? Rețineți că este posibil să nu știți întotdeauna acest lucru sau să aveți nevoie să știți acest lucru. Dar dacă o faci, nu strică să o incluzi.
12. Este raportul defectului lipsit de probleme de gramatică, format, ortografie și punctuație?
cum să vizualizați fișiere XML în word
13. Știu o modalitate de a îmbunătăți produsul?
Te gândești că asta consumă mult timp? Ei bine, odată ce devine un obicei, nu va mai fi.
Înrădăcinarea pentru mai bine raportarea defectelor rutine!
Despre autor: Acest articol este scris de Swati, membru al echipei STH.
Nu ezitați să postați întrebările / comentariile dvs. mai jos.
Lectură recomandată
- De ce raportarea erorilor este o artă care ar trebui învățată de fiecare tester?
- Ce este ciclul de viață al defectelor / erorilor în testarea software-ului? Tutorial privind ciclul de viață al defectelor
- Exemple de rapoarte de erori pentru aplicații web și produse
- Ce este tehnica de testare bazată pe defecte?
- Procesul de gestionare a defectelor: Cum să gestionați eficient un defect
- Procesul de triere a defectelor și modalitățile de gestionare a întâlnirii de triere a defectelor
- Cum se scrie un raport bun de eroare? Sfaturi și trucuri
- 3 strategii pentru tratarea unui defect de blocare