Meniu

Cum să revizuiți documentul SRS și să creați scenarii de testare - Instruire de testare software într-un proiect live - Ziua 2

how review srs document

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Acesta este al doilea tutorial din „Instruire gratuită online pentru testarea software-ului pe un proiect live” serie. Dacă sunteți nou aici, vă rugăm să verificați primul tutorial de introducere: Instruire de testare software de la un capăt la altul pentru un proiect live.

Să intrăm acum într-o analiză detaliată a modului în care se întâmplă o soluție SRS, ce este ceea ce trebuie să identificăm din acest pas, ce pași prealabili trebuie să facem înainte de a începe, care sunt provocările cu care ne-am putea confrunta etc. o manieră detaliată.

Cum să revizuiți documentul SRS și să creați scenarii de testare_

Faza de proiectare a SDLC:

Următoarea fază a SDLC este „Proiectare” - aici se traduce cerințele funcționale în detaliile tehnice. Echipele de dezvoltare, proiectare, mediu și date sunt implicate în acest pas. Rezultatul acestui pas este de obicei un document de proiectare tehnică - TDD.

Introducerea este documentul SRS atât pentru crearea TDD, cât și pentru ca echipa QA să înceapă să lucreze la aspectul QA al proiectului - care este de a revizui SRS și de a identifica obiectivul testului.

Ce veți învăța:

Ce este o revizuire SRS?

SRS este un document creat de echipa de dezvoltare în colaborare cu Business Analists și echipele de mediu / date. În mod obișnuit, acest document, odată finalizat, va fi împărtășit cu echipa QA printr-o întâlnire în cadrul căreia este organizată o prezentare detaliată.

Uneori, pentru o aplicație deja existentă, este posibil să nu avem nevoie de o întâlnire oficială și de cineva care să ne ghideze prin acest document. S-ar putea să avem informațiile necesare pentru a face acest lucru singuri.

Revizuirea SRS nu este altceva decât să parcurgeți documentul cu specificațiile cerințelor funcționale și să încercați să înțelegeți cum va fi aplicația țintă.

Formatul formal și un eșantion v-au fost împărtășite tuturor în articolul anterior. Nu înseamnă neapărat că toate SRS vor fi documentate exact în acest fel. Întotdeauna forma este secundară conținutului .

Unele echipe vor alege doar să scrie o listă cu marcatori, unele echipe vor include cazuri de utilizare, unele echipe vor include exemple de capturi de ecran (cum ar fi documentul pe care l-am avut), iar altele descriu doar detaliile în paragrafe.

Pași prealabili pentru revizuirea specificațiilor cerințelor software

Pasul 1) Documentele trec prin mai multe revizuiri, deci asigurați-vă că avem versiunea corectă a documentului de referință, SRS.

Pasul 2) Stabiliți orientări cu privire la ceea ce se așteaptă la sfârșitul revizuirii de la fiecare membru al echipei. Cu alte cuvinte, decideți ce rezultate sunt așteptate de la acest pas - de obicei, rezultatul acestui pas este de a identifica scenariile de testare. Scenariile de testare nu sunt altceva decât un singur indicator al „ce trebuie testat” pentru anumite funcționalități.

Pasul 3) De asemenea, stabiliți îndrumări cu privire la modul în care trebuie prezentat acest livrabil - adică șablonul.

Pasul 4) Decideți dacă fiecare membru al echipei va lucra la întregul document sau îl împărțiți între ei. Este foarte recomandat ca toată lumea să citească totul, deoarece acest lucru va împiedica concentrarea cunoștințelor cu anumiți membri ai echipei.

Dar în cazul unui proiect uriaș, cu documentele SRS care rulează aproape 1000 de pagini, abordarea de a rupe modulul documentului în mod înțelept și de a aloca membrilor individuali ai echipei este cea mai practică.

Pasul 5) Revizuirea SRS ajută, de asemenea, la o mai bună înțelegere dacă există cerințe preliminare specifice necesare pentru testarea software-ului.

Pasul 6) Ca produs secundar, o listă de interogări în care unele funcționalități sunt dificil de înțeles sau dacă mai multe informații trebuie încorporate în cerințele funcționale sau dacă sunt identificate greșeli în SRS.

c # vs c ++ vs java

De ce avem nevoie pentru a începe?

  • Versiunea corectă a documentului SRS
  • Instrucțiuni clare despre cine va lucra despre ce și cât timp au.
  • Un șablon pentru a crea scenarii de testare.
  • Alte informații cu privire la cine să contactați în cazul unei întrebări sau pe cine să raportați în cazul unei inconsecvențe a documentației

Cine ar furniza aceste informații?

Conducătorii echipei sunt în general responsabili pentru furnizarea tuturor articolelor enumerate în secțiunea de mai sus. Cu toate acestea, contribuțiile membrilor echipei sunt întotdeauna importante pentru succesul acestui întreg efort.

Conducătorii echipei întreabă adesea - Ce fel de intrări? Nu ar fi mai bine să atribuiți un anumit modul cuiva interesat de acesta decât unui membru al echipei care nu este? Nu ar fi frumos să decidem data țintă pe baza opiniei echipei decât să decidem asupra lor? De asemenea, pentru succesul unui proiect, șabloanele sunt importante.

Ca regulă generală, șabloanele au o rată mai mare de eficiență atunci când sunt adaptate la confortul și confortul echipei specifice. Prin urmare, trebuie remarcat faptul că conducătorii echipei mai mult decât orice sunt membri ai echipei. Este esențial ca echipa dvs. să ia parte la deciziile de zi cu zi pentru buna desfășurare a proiectului.

Este necesar șablonul pentru scenariile de testare?

De ce un șablon pentru scenarii de testare - nu este suficient dacă facem doar o listă?

Cu siguranță e. Cu toate acestea, proiectele software nu sunt spectacole „one-man”. Acestea implică lucru in echipa .

Imaginați-vă o echipă formată din 4 - dacă fiecare dintre ei decide să revizuiască fiecare modul al specificațiilor cerințelor software. Membrul echipei A a făcut o listă pe o foaie de hârtie. Membru al echipei 2 a folosit o foaie Excel. Membru al echipei 3 a folosit un blocnotes. Membru al echipei 4 a folosit un cuvânt doc. Cum consolidăm toată munca depusă pentru proiect la sfârșitul zilei?

De asemenea, cum putem decide care este standardul și cum putem spune ce este corect și ce nu dacă nu am creat regulile, pentru început?

Acesta este șablonul: Un set de linii directoare și un format agreat pentru uniformitate și concurență pentru întreaga echipă.

Cum se creează un șablon pentru scenarii de testare QA?

Șabloane nu trebuie să fie complicat sau inflexibil.

Tot ce trebuie să fie sunt un mecanism eficient pentru a crea un artefact de testare util. Ceva simplu ca cel pe care îl vedem mai jos:

șablon scenarii de testare

Antetul acestui șablon conține spațiul necesar pentru a capta informații de bază despre proiect, documentul curent și documentul de referință.

Tabelul de mai jos ne va permite să creăm scenarii de testare. Coloanele incluse sunt:

Coloana # 1) ID scenariu de testare
Fiecare entitate din procesul nostru de testare trebuie să fie identificabilă în mod unic. Deci, fiecărui scenariu de test trebuie să i se atribuie un ID. Regulile de urmat în timpul atribuirii acestui ID trebuie definite.

De dragul acestui articol vom urma convenția de numire ca TS (prefix care înseamnă Test Scenario) urmat de „_”, numele modulului PE MINE (Modulul My Info al proiectului Orange HRM) urmat de „_” și apoi subsecțiunea ( De exemplu, PE MINE pentru modulul meu de informații, P pentru fotografie și așa mai departe) urmat de un număr de serie. Un exemplu ar fi: „TS_MI_MIM_01”.

Coloana # 2) Cerință
Ajută la faptul că, atunci când creăm un scenariu de testare, ar trebui să putem să îl mapăm înapoi la secțiunea din documentul SRS de unde l-am ales. Dacă cerințele au ID-uri, le-am putea folosi. Dacă nu, numerele de secțiune sau chiar numerele de pagină ale documentului SRS de unde am identificat o cerință testabilă va face.

cum se scrie un makefile c ++

Coloana # 3) Descrierea scenariului de testare
Un singur liner care specifică „ce să testez”. Ne-am referi, de asemenea, la acesta ca obiectiv al testului.

Coloana # 4) Importanță
Aceasta este pentru a da o idee despre cât de importantă este o anumită funcționalitate pentru AUT. Valori precum ridicat, mediu și scăzut pot fi atribuite acestui câmp. De asemenea, puteți alege un sistem de puncte, cum ar fi 1-5, 5 fiind cel mai important, 1 fiind mai puțin important. Indiferent de valoarea pe care o poate lua acest câmp, trebuie decisă în prealabil.

Coloana # 5) Nr. Cazuri de testare
O estimare aproximativă a numărului de cazuri individuale de testare pe care am putea ajunge să scriem acel scenariu de testare. De exemplu, Pentru a testa datele de conectare - includem aceste situații: Corectați numele de utilizator și parola. Corectați numele de utilizator și parola greșită. Parola corectă și numele de utilizator greșit. Deci, validarea funcționalității de conectare va duce la 3 cazuri de testare.

Notă: Puteți extinde acest șablon sau puteți elimina câmpurile după cum doriți.

De exemplu , puteți adăuga „Revizuit de” în antet sau puteți elimina data creării etc. De asemenea, în tabel puteți include un câmp „Creat de” pentru a desemna testerul responsabil pentru un anumit scenariu de testare sau pentru a elimina „Nu. a coloanei Test cases ”. Alegerea este a ta. Mergeți cu ceea ce funcționează cel mai bine pentru întreaga echipă.

Să examinăm acum documentul nostru Orange HRM SRS și să creăm scenarii de testare

Pro Tip: consultați cuprinsul din eșantionul SRS pe care l-am furnizat în primele tutoriale pentru a vă face o idee bună despre cum va curge orice document și cât de mult ar putea implica munca.

Sectiunea 1 este scopul documentului. Nu există cerințe testabile acolo.

Secțiunea 2.1 : Prezentare generală a proiectului- Audiență- nici cerințe testabile acolo.

Secțiunea 2.2 : Hardware și găzduire - Această secțiune vorbește despre cum va fi găzduit site-ul Orange HRM. Acum, aceste informații sunt importante pentru noi testerii? Răspunsul este da și nu. Da, pentru că atunci când testăm trebuie să avem un mediu similar cu mediul în timp real.

Acest lucru ne oferă o idee despre cum trebuie să fie. Nu, pentru că nu este o cerință testabilă - un fel de condiție prealabilă pentru testare.

Secțiunea 3: Există un ecran de conectare aici și detaliile tipului de cont pe care trebuie să îl avem pentru a intra pe site. Aceasta este o cerință testabilă. Deci, trebuie să facă parte din scenariile noastre de testare.

Vă rugăm să consultați documentul de scenarii de testare în care au fost adăugate scenarii de testare pentru câteva secțiuni din SRS. Pentru practică, vă rugăm să adăugați restul scenariilor într-un mod similar. Cu toate acestea, merg direct la secțiunea 4 a documentului.

Secțiunea 4: Cerințe și instrucțiuni estetice / HTML - Această secțiune explică cel mai bine modul în care unele cerințe ar putea să nu aibă sens pentru echipa de testare la momentul revizuirii SRS, dar echipa ar trebui să le noteze ca fiind cerințe testabile la fel.

Cum să le testăm și dacă avem nevoie de o configurare specifică / de ajutorul oricărei echipe pentru validare sunt detalii pe care s-ar putea să nu le cunoaștem în acest moment. Dar a le face parte din domeniul nostru de testare este primul pas pentru a ne asigura că nu le ratăm.

Exemple de scenarii de testare pentru aplicația OrangeHRM: (faceți clic pentru a mări imaginea)

șablon scenarii de testare

=> Vă rugăm să consultați și descărcați documentul Test Scenarios pentru mai multe informatii.

Câteva observații importante privind revizuirea SRS

# 1) Nicio informație nu trebuie lăsată neacoperită.
#Două) Efectuați analize de fezabilitate pentru a stabili dacă o anumită cerință este corectă sau nu și, de asemenea, dacă poate fi testată sau nu.
# 3) Cu excepția cazului în care există o performanță / securitate separată sau orice altă formă de echipe de testare - este treaba noastră să ne asigurăm că trebuie luate în considerare toate cerințele nefuncționale.
# 4) Nu toate informațiile sunt destinate testerilor, deci este important să înțelegeți ce să notați și ce nu.
# 5) Importanța și nu. de cazuri de testare pentru un scenariu de testare nu trebuie să fie exacte și pot fi completate cu o valoare aproximativă sau pot fi lăsate goale.

întrebări și răspunsuri la interviurile oracle sql

Pentru a rezuma, revizuirea SRS are ca rezultat:

  • Lista de scenarii de testare
  • Rezultatele revizuirii - erori de documentare / cerință constatate prin parcurgerea / verificarea statică a documentului SRS
  • O listă de întrebări pentru o mai bună înțelegere - în cazul în care există
  • Ideea preliminară despre cum ar trebui să fie mediul de testare
  • Identificarea domeniului de testare și o idee aproximativă despre câte cazuri de testare am putea ajunge - deci cât timp avem nevoie pentru documentare și, eventual, pentru executare.

Puncte importante de reținut:

# 1) Scenariile de testare nu sunt livrabile externe (nu sunt partajate cu analistii de afaceri sau echipele de dezvoltare), dar sunt importante pentru consumul intern de QA. Ele sunt primul nostru pas către un obiectiv de acoperire 100% a testelor. Scenariile de testare odată finalizate sunt supuse unei evaluări inter pares și, odată ce acest lucru este finalizat, toate sunt consolidate.

Pentru mai multe detalii despre modul în care sunt revizuite documentele QA, consultați articolul: Cum să efectuați recenzii ale documentației de test în 6 pași simpli.

#Două) Am putea folosi un instrument de gestionare a testelor precum HP ALM sau qTest pentru a crea scenariile de testare. Cu toate acestea, crearea scenariilor de testare în timp real este o activitate manuală. După părerea mea, este mai convenabil manual. Deoarece este pasul 1, nu este nevoie să scoatem încă armele mari. Foile simple Excel sunt cel mai bun mod de a face acest lucru.

Următorul pas către această serie este că - vom lucra la crearea de cazuri de testare și vom intra mai departe în faza de proiectare a testelor. Înainte de asta, vom intra și în ... Ce este planificarea testelor?Unde se încadrează în întregul proiect QA? Ca întotdeauna, lucrați cu noi pentru cele mai bune rezultate.

Ziua 3 de instruire QA: Cum se scrie un document SRS de la zero.

Vă rugăm să păstrați întrebările și comentariile dvs. Vă mulțumim pentru cititori!

Lectură recomandată

^