writing test cases from srs document
Scrierea cazurilor de testare din documentul SRS (Descărcați exemplele de testare a proiectelor live) - Testarea software-ului QA Training Day 4
Doar pentru a reface ceea ce am făcut până acum - ne străduim drumul prin Instruire pentru testarea software-ului mini-curs pe un proiect live OrangeHRM.
În această serie gratuită de instruire online de calitate, până acum, am terminat cu:
- Revizuirea SRS,
- Scenariul de testare / Identificarea scopului de testare și
- Documentat planul de testare .
Acum, am ajuns la partea care este adevărata afacere,cazurile de testare.
Așa cum se indică în articolul anterior: Cazurile de testare sunt documentate de echipa QA în timp ce se desfășoară faza de cod a SDLC. Cu alte cuvinte, în timp ce echipa Dev dezvoltă sistemul software, echipa de testare se pregătește cu cazurile de testare care ne-ar ajuta să testăm sistemul odată ce este gata, adică la sfârșitul fazei de cod.
Deci, în articolul de astăzi, vom lucra la înțelegerea care sunt cazurile de testare, cum să le creăm și vom scrie câteva exemple de cazuri de testare pentru proiectul nostru live.
Haideți să ajungem la el imediat.
Ce veți învăța:
- Bazele scrierii cazurilor de testare
- Câmpuri în cazuri de testare
- Metode de scriere / optimizare a cazurilor de testare
- Câteva puncte importante de remarcat
- Concluzie
- Lectură recomandată
Bazele scrierii cazurilor de testare
# 1) În cazul în care scenariile de testare erau despre, „Ce vom testa” pe AUT - toate cazurile de testare sunt despre „Cum vom testa o cerință”.
De exemplu , dacă scenariul de testare este „Validați funcționalitatea de conectare a administratorului” - Acest lucru ar rezulta în 3 cazuri de testare (sau condiții) - Autentificare (reușită), Autentificare-nereușită la introducerea numelui de utilizator incorect, Autentificare-nereușită la introducerea parolei incorecte . Fiecare caz de test ar avea, la rândul său, pași pentru a aborda modul în care putem verifica dacă o anumită condiție de testare este sau nu îndeplinită.
#Două) Intrarea pentru a crea un document de caz de testare este FRD, scenarii de test create în pasul anterior și orice alte documente de referință, dacă sunt prezente.
# 3) Documentația cazului de testare este o livrare importantă de către echipa de asigurare a calității și este împărtășită cu BA, PM și alte echipe atunci când este finalizată pentru feedback-ul lor.
# 4) Munca este împărțită între membrii echipei și fiecare membru va fi responsabil pentru crearea cazurilor de testare pentru un anumit modul sau o parte a unui anumit modul.
# 5) La fel ca în cazul scenariilor de testare, înainte de a începe documentația cazului de testare, trebuie să fie convenit un șablon comun. Practic orice poate fi folosit pentru a crea cazuri de testare. Cele mai des utilizate 2 opțiuni sunt MS Excel și MS word.
# 6) Șablon MS Word arata cam asa:
# 7) Șablon Excel ar putea arăta după cum urmează:
# 8) Din cele două șabloane de mai sus, se poate observa că câmpurile (sau componentele) care compun un caz de testare sunt aceleași, singura diferență este modul în care sunt organizate.
Deci, atâta timp cât există un câmp pentru fiecare dintre tipurile de informații care trebuie incluse într-un test, formatul șablonului nu contează. Cu toate acestea, preferatul meu personal se întâmplă să fie foaia Excel, deoarece este ușor să extindeți, să restrângeți, să sortați etc. Dar, din nou, alegeți orice format care funcționează cel mai bine pentru dvs.
Câmpuri în cazuri de testare
Să luăm un moment, să observăm câmpurile care fac parte dintr-un caz de testare.
Id-ul cazului de testare și descrierea cazului de testare sunt cele generice.
Celelalte câmpuri pot fi explicate după cum urmează:
- Condiție prealabilă: Starea AUT (starea în care trebuie să fie AUT pentru a începe).
- Intrare: Etape de introducere a datelor. Pentru acești pași, este important să rețineți ce tip de informații de intrare sunt necesare - date de testare.
- Punct de validare / declanșator / acțiune : Ce cauzează validarea? (Faceți clic pe un buton sau comutați sau pe linkul de acces. Asigurați-vă că există cel puțin un punct de validare pentru un caz de testare - în caz contrar, totul va fi introducerea de date, fără a căuta nimic. De asemenea, pentru a ne asigura că avem suficientă modularitate, încercați să nu combinați prea multe puncte de validare într-un singur caz de testare. 1 pentru fiecare caz de testare este optim.)
- Ieșire: Rezultat asteptat.
- Postcondiție: Acestea sunt informații suplimentare care sunt furnizate în beneficiul testerului, doar pentru a face cazul testului mai inteligent și mai informativ. Aceasta include o explicație a ceea ce se întâmplă sau a ceea ce se poate aștepta de la AUT după ce toți pașii de testare sunt finalizați.
Vezi și => Exemplu de șablon de caz de testare
Proiecte live Exemple de cazuri de testare (descărcare)
Acum, că avem suficiente informații de bază pentru a începe procesul de creare a cazurilor de test, permiteți-ne să începem și să creăm câteva cazuri de testare pentru proiectul nostru live.
Pe baza procesului menționat mai sus, am creat câteva exemple de cazuri de testare pentru modulul de cont OrangeHRM. Acestea ar trebui să vă ofere un format exact al cazului de testare și o idee despre cum să abordați scrierea cazurilor de testare.
=> Descărcați exemplele de documente de testare pentru proiectul nostru live aici .
Notă: Există puține imagini referitoare la exemplele de cazuri de testare a documentului XLS. Dacă vedeți acest lucru pe versiunea mai veche MS Office, este posibil să vă confruntați cu probleme de compatibilitate.
Am enumerat acele imagini de mai jos, după numele lor, în fișierele XLS:
Vizualizați imaginea 1
Vedeți imaginea 2
Vizualizați imaginea 3
Acolo, totul făcut și toate bune.
Metode de scriere / optimizare a cazurilor de testare
Acum, imaginați-vă o situație în care o anumită pagină are câteva zeci de câmpuri sau are o logică de afaceri complexă care este implementată acolo. Pentru a ne asigura că optimizăm procesul de creare a cazurilor de testare în astfel de situații, testerii dispunem de anumite metode de optimizare a cazurilor de testare.
Mai jos sunt enumerate linkurile furnizate pentru mai multe informații despre aceste metode.
ce este un fișier .bin?
- Analiza valorii limită
- Partiționarea echivalenței
- Eroare de ghicit - Aceasta este o metodă foarte simplă și se bazează pe intuiția unui tester. De exemplu , Spuneți că există un câmp de dată pe o pagină. Cerințele vor specifica faptul că o dată validă trebuie acceptată de acest câmp. Acum, un tester poate încerca „30 februarie” ca dată - deoarece în ceea ce privește numerele, este o intrare validă, dar februarie este o lună care nu are niciodată 30 de zile în ea - deci o intrare nevalidă.
- Diagrame de tranziție de stat
- Tabelele de decizie
Folosind tehnicile de mai sus și urmând procesul general de creare a cazurilor de testare, creăm un set de cazuri de testare care ar testa eficient aplicația la îndemână.
Câteva puncte importante de remarcat
- Cazurile de testare pe care le creăm nu sunt doar punctul de referință pentru faza QA, ci și pentru UAT.
- Cazurile de testare internă sunt Evaluat de colegi în cadrul echipei .
- Când o anumită situație nu este abordată de un caz de testare - regula generală este că nu va fi testată. Deci, acesta este un loc bun pentru a verifica dacă suita de testare pe care am creat-o atinge obiectivul de acoperire a testului de 100% sau nu. Pentru a face acest lucru, se poate crea o matrice de trasabilitate. Verificați tot ce trebuie să știți despre Matricea de trasabilitate aici .
- Instrumente - Testează instrumente de gestionare precum QC , qTest ajutați-ne cu activitatea de creare a cazurilor de testare. Pentru un exemplu despre modul în care cazurile de testare pot fi tratate folosind Quality Center, consultați acest lucru Tutorial Quality Center .
- Instrumentele de automatizare pot fi utilizate pentru a crea cazuri de testare, caz în care sunt denumite scripturi de testare.
Asta ne aduce la sfârșitul unui alt segment interesant.
Concluzie
Sfârșitul procesului de creare a testului / faza de proiectare a testului (STLC) și sfârșitul fazei de cod (SDLC) vor marca, în general, sfârșitul fazei de pregătire a testului și începutul fazei de execuție a testului.
Următorul tutorial în acest curs de testare software - În articolul care urmează, vom vorbi despre ce este Execuția testului, ce include și care sunt așteptările de la echipa QA în această fază.
=> Ziua 5 de instruire QA: Executarea testului
Sperăm că toți lucrați împreună cu această serie. Din motive de simplitate, au fost create doar câteva cazuri de testare. Cu toate acestea, cele mai bune rezultate pot fi văzute atunci când lucrați la testarea pe scară largă, ceea ce înseamnă că scrieți din ce în ce mai multe cazuri de testare. Așadar, vă rugăm să nu vă limitați munca și să faceți cât de mult puteți.
Vă rugăm să ne anunțați întrebările și comentariile dvs. de mai jos. Testare fericită!
Lectură recomandată
- Exemplu de șablon de caz de testare cu exemple de cazuri de testare (Descărcare)
- Cum să scrieți un document de strategie de testare (cu un șablon de strategie de testare exemplar)
- Exemplu de document de plan de testare (exemplu de plan de testare cu detalii despre fiecare câmp)
- Cum se scrie un raport sumar eficient al testului (Descărcare exemplu de raport)
- Cum să scrieți cazuri de testare: ultimul ghid cu exemple
- Instruire pentru testarea software-ului: instruire de la un capăt la altul în cadrul unui proiect live - Instruire online gratuită pentru QA Partea 1
- Exemplu de șablon de plan de testare software cu format și conținut
- Cum se scriu cazuri de testare pentru bancomat (exemple de scenarii)