Un produs software este ca un avion: trebuie să fie supus unei verificări tehnice înainte de lansare.

Asigurarea calității este un pas necesar spre lansarea unui produs software de succes. Este doar o mică parte din toată munca proiectului, dar nimeni nu a spus că va fi simplu.

Există atât de multe tipuri de testare software – automată și manuală, explorativă și funcțională, compatibilitate, UI / UX, regresie, unitate, API și teste de performanță. Noroc înfășurându-ți capul în jurul tuturor!

Totuși, ceea ce este comun pentru toate aceste tipuri este că fiecare vă cere să scrieți o documentație completă de testare QA. Calitatea documentelor de testare definește dacă munca ta se va dovedi utilă sau va merge în zadar.

Am scris acest articol pentru a vă ușura viața. Așadar, iată-l, ghidul dvs. final despre cum să scrieți documentația QA software care va funcționa.

Realizați un plan de testare și un raport de progres al testului

Planul de testare este un document orientativ care prezintă o imagine mai largă a procesului de asigurare a calității și include o listă de sarcini, strategie, resurse și program.

Înainte de a crea un document de plan QA, întrebați-vă „Care este scopul soluției software?” și „Ce caracteristici trebuie testate?”. Nu vă grăbiți să testați fiecare parte a software-ului dvs. Trebuie să decideți ce metodologii, tehnologii și instrumente veți utiliza.

Planul de testare vă va ajuta să înțelegeți următoarele:

  • Care sunt criteriile de acceptare?
  • De ce resurse aveți nevoie? Ce sisteme de operare, câte copii și cu ce licență? Aveți nevoie de consultanți tehnici?
  • Rolurile și responsabilitățile dvs. sunt bine desemnate?
  • Ce sunt termenele de testare?

Raportul de progres al testului este o altă parte a documentației QA, care este similară cu planul de testare, dar cu date adăugate despre progresul curent. Acest document vă permite, împreună cu echipa dvs. de dezvoltare, să monitorizați progresul proiectului și să identificați problemele organizaționale, dacă există.

Planul și raportul de testare

Creați cazuri de testare

După ce ați clarificat setul de funcții care trebuie testate în planul de testare, trebuie să creați un caz de testare pentru fiecare parte a software-ului dvs.

Cazurile de testare sunt destul de simple – această documentație QA constă din 7 secțiuni: ID, caz de testare, pași de testare, rezultatul așteptat, stare, rezultat real și comentarii.

  1. ID este un număr unic atribuit cazului dvs. de testare.
  2. În Caz de testare secțiunea, indicați cerințele pe care le veți testa și furnizați un link către aceasta în documentul de specificații.
  3. În Etape de testare secțiunea, listați toate acțiunile necesare pentru a finaliza un caz de testare.
  4. În rezultat asteptat secțiunea, rezumați rezultatul unui anumit test dacă acesta are succes.
  5. În stare secțiunea, indicați dacă un anumit pas a trecut sau nu a reușit testarea.
  6. În Rezultat actual secțiunea, explicați rezultatul unui test eșuat.
  7. Comentarii secțiunea nu este obligatorie, dar o puteți adăuga pentru a lăsa câteva note suplimentare.
Caz de testare

Scrieți un raport de defecte

Raportul privind defectele este un element important al documentației QA. Înregistrează orice problemă nedorită cu programul dvs. Este un element crucial al documentației proiectului, care vă orientează către obținerea unei soluții software fără erori.

Sună simplu, nu? Da, dar numai până începeți documentarea. Aici puteți vedea un exemplu de raport tipic de defecte:

Raportul defectelor

Raportul de defecte constă din următoarele secțiuni: identificator, rezumat, descriere, pași de reproducere, reproductibilitate, severitate, prioritate, mediu și atașamente.

  1. Fiecărei probleme software specifice i se atribuie un număr unic – identificator. Optimizează navigarea prin documente QA și facilitează comunicarea între dezvoltatori, testeri și PM.
  2. În rezumat secțiunea, oferiți un răspuns concis la trei întrebări simple: ce s-a întâmplat, unde și în ce circumstanțe.
  3. În Descriere secțiune, descrieți eroarea în detaliu. Ar trebui să spuneți despre rezultatele reale și cele așteptate. Este util să furnizați un link către cerințele dvs. software.
  4. Apoi, scrieți despre pași pentru reproducere (STR). Acest lucru arată dezvoltatorilor exact cum să reproducă problema. Nu ratați un pas sau raportul dvs. vă poate reveni.
  5. În reproductibilitate , clarificați dacă apare eroarea de fiecare dată când urmați STR. Ar trebui să utilizați numerele pentru a afișa șanse aproximative, de exemplu de 7 ori din 10.
  6. În severitate secțiunea, explicați cât de mult poate dăuna bug-ului proiectului. Cu alte cuvinte, arată gradul tehnologic de influență a defectului asupra întregului sistem. Chiar și o mică problemă poate afecta grav întreaga aplicație.
  7. Prioritate arată cât de important este un anumit raport de defecte. Prioritatea poate fi notată cu ajutorul literelor – „A” pentru cel mai urgent și „Z” pentru cel mai puțin urgent, cifre – „1” pentru cel mai urgent și „9” pentru cel mai puțin urgent, sau pur și simplu cuvinte precum „mare” ”,„ Mediu ”sau„ scăzut ”.
  8. În mediu inconjurator secțiunea, ar trebui să definiți ce sisteme de operare sau versiuni de browser au fost afectate.
  9. În cele din urmă, atașamente includeți lista de videoclipuri, capturi de ecran sau fișiere jurnal de consolă adăugate la raportul de defecte.

Rețineți aceste sfaturi utile pentru scrierea raportului de defecte

  1. Scrieți un rezumat suficient și adecvat. Nu contează dacă este lung sau scurt. Ceea ce contează este să fie clar.
  2. Aruncați o privire la rezumat și descriere. Arată cam la fel? Trebuie să fi uitat să descrieți rezultatele așteptate și reale în descriere și să adăugați linkul la cerințe.
  3. Capturați problema cu ajutorul unei capturi de ecran. S-ar putea să vă economisiți mult timp și echipei de dezvoltare. Uneori, o singură privire asupra imaginii este suficientă pentru a înțelege situația.
  4. Înainte de a raporta problema, încercați să o reproduceți de cel puțin 3 ori pentru a vă asigura că există.
  5. Raportați problema cât mai curând și anunțați managerul de proiect sau proprietarul produsului dacă problema este majoră.
  6. Verificați dacă există greșeli de gramatică în documentația dvs. de asigurare a calității, astfel încât poliția gramaticală să nu vă dea jos.
  7. Oricât de comic ar suna, asigurați-vă că problema nu este o caracteristică – revedeți din nou documentația!
  8. Nu ratați nicio informație importantă în Pașii dvs. de reproducere.

Trimiteți un raport de defecte

Rapoartele de defecte trec printr-un ciclu de viață – din momentul în care raportați o problemă până în momentul în care problema este închisă.

Ciclul de viață al raportului de defecte

Primul pas este de a compila și Trimite raportul defectului. În acest moment, managerul de proiect sau un conducător tehnic decide dacă atribui către un dezvoltator sau către declin pe motive de insuficiență sau inadecvare.

După ce dezvoltatorul alocat are fix bug-ul, în calitate de QA trebuie să verificați dublu și verifica a fost remediat. Dacă da, puteți închide raportul defectelor. Cea mai bună practică este închiderea acestuia într-o săptămână sau două.

Dacă eroarea nu este remediată, tu redeschide raportul de defecte și trimiteți-l înapoi dezvoltatorului atribuit. Procesul de remediere a erorilor poate fi unul lung, dar trebuie să rămâneți puternic până când toate rapoartele de defecte sunt finalizate.

Pentru a încheia

Asigurarea calității este un proces pe care pur și simplu nu îl puteți evita. Fiecare avion înainte de plecare este supus unei verificări tehnice. Dacă există vreo problemă, aeronava este împământată până când problema este rezolvată.

În mod similar, fiecare produs software trebuie verificat înainte de lansare. Nu vă puteți permite să implementați software buggy, deoarece utilizatorii nu vor oferi aplicației dvs. o a doua șansă.

Trebuie să îmbunătățiți calitatea software-ului dvs.?

Compania mea KeenEthics oferă soluții solide servicii de dezvoltare și asigurare a calității. În cazul în care aveți nevoie de o estimare pentru un proiect similar, nu ezitați Intrați în legătură.

Dacă v-a plăcut articolul, ar trebui să continuați cu Ce este prototiparea și de ce avem nevoie de ea și Produs viabil minim: între o idee și produs.

PS

Articolul original postat pe blogul KeenEthics poate fi găsit aici: Cum se scrie o documentație QA care va funcționa?