Despre testare - testare - raport de eroare - scrierea unui raport de eroare

Raportul de eroare este un document tehnic și, în această privință, dorim să remarcăm că limba descrierii problemei ar trebui să fie tehnică. terminologia corectă ar trebui să fie utilizat atunci când se utilizează numele de elemente de interfață utilizator (casetei de editare, listbox, ComboBox, link-ul, zona de text, buton, meniu, meniu pop-up, bara de titlu, bara de sistem, etc.), o acțiune de utilizator (click link-ul, apăsați butonul , selectați elementul de meniu etc.) și rezultatele obținute (fereastra este deschisă, mesajul de eroare este afișat, sistemul sa prăbușit etc.).

Câmpuri obligatorii pentru raportul de eroare

Rețineți că câmpurile obligatorii pentru raportul de eroare sunt: Rezumat de eroare, Severitate, Pași pentru reproducere, Rezultat real, Rezultat așteptat. Mai jos sunt cerințele și exemplele de completare a acestor câmpuri.

Scurtă descriere

Numele vorbește de la sine. Într-o singură propoziție trebuie să se potrivească înțelesul tuturor rapoartelor de erori, și anume: scurte și clare, folosind terminologia corectă pentru a spune ceea ce și în cazul în care nu funcționează. De exemplu:

Aplicația se blochează atunci când încercați să salvați un fișier text mai mare de 50MB.
Datele din formularul "Profil" nu sunt salvate după ce faceți clic pe butonul "Salvați".

În plus, vă sugerăm să studiați Principiul "Unde? Ce? Când?". descrisă pe paginile blogului "Nestul de QA":

"Care este acest principiu?
Faceți o propunere în care faptele defectului sunt prezentate în următoarea ordine:

seriozitate

Pe scurt, se poate observa faptul că dacă o problemă se găsește în funcționalitatea de bază a aplicației și după apariția cererii devine complet indisponibil, iar lucrul cu ei, nu este posibil, atunci acesta este blocat. De obicei, toate problemele de blocare sunt găsite în timpul verificării inițiale pentru noi versiuni ale produsului (Build test de verificare. Test de fum), ca prezența lor nu permite testarea pe scară largă. Dacă testarea poate fi continuată, atunci severitatea acestui defect va fi critică. În detrimentul celor semnificative. minore și trivială, întrebarea este destul de transparentă și, în opinia noastră, nu necesită explicații inutile.

Pași pentru redare / rezultat / rezultat așteptat

Este foarte important să descrieți în mod clar toți pașii, menționând toate datele de intrare (numele de utilizator, datele de completat în formular) și rezultatele intermediare.

Principalele greșeli în scrierea rapoartelor de erori

Lipsa datelor furnizate
Nu este întotdeauna una și aceeași problemă poate apărea atunci când toate valorile de intrare și la orice utilizator logat, de aceea este foarte recomandat pentru a face toate informațiile necesare într-un raport de eroare

Definiția severity
Foarte des, apare o supraestimare sau o subestimare a severității defecțiunii, ceea ce poate duce la o secvență incorectă în rezolvarea problemei.

Limbajul descrierii
Adesea, atunci când se descrie problema, se utilizează terminologia incorectă sau întoarcerea complicată a vorbirii, ceea ce poate induce în eroare persoana responsabilă pentru rezolvarea problemei.

Lipsa rezultatului așteptat
În cazurile în care nu specifică ce ar trebui să fie necesar de comportamentul sistemului, iti petreci timpul dezvoltator, pentru a găsi aceste informații, prin aceasta încetinind corectarea defectului. Trebuie să specificați elementul în cerințe, cazul testului scris sau opinia dvs. personală dacă această situație nu a fost documentată.

Completarea câmpurilor de raportare a erorilor

Tabelul de mai jos descrie câmpurile principale ale raportului de eroare și rolul angajatului responsabil pentru completarea acestui câmp. Culoarea roșie indică câmpurile obligatorii:

Responsabil pentru umplerea câmpului

Articole similare

Pagina anterioară

Pagina următoare