Meniu

Scenariu de testare vs. caz de testare: Care este diferența dintre acestea?

test scenario vs test case

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Diferența dintre scenariul de testare și cazul de testare.

acum 6 ani , în timp ce lucrați cu un MNC de dimensiuni medii, când am sugerat să documentez scenariile de testare, mai degrabă decât să pierd timpul pregătind documentul complet de probă numit cazuri de testare, toate capetele s-au întors către mine, supărate.

Privirea fețelor transmitea în mod clar că am făcut o mare greșeală sugerând-o. Deși nimeni nu a negat ideea, nimeni nu a acceptat. Toată lumea a considerat că respectarea tradiției, adică scrierea documentelor de caz de testare, ar fi mai sigură. Nu puteam să mă cert.

Testează scenariul împotriva cazului de testare

După 4 ani , compania a primit un proiect de testare, unde singura constrângere era timpul și singura așteptare era dovada completă testarea.

Am fost din nou la întâlnire și discutam idei pentru a respecta termenul critic. Aplicația viza în principal căutarea și generarea de rapoarte diferite prin diferite elemente de meniu. Documentarea cazurilor de test ar fi trebuit să smulgă de cele mai multe ori și nu am fost siguri, cât de mult va folosi documentul pentru client.

Am sugerat documentarea scenariilor de testare și cumva, cu o oarecare ezitare, toată lumea a fost de acord. Nu este necesar să menționăm că am putea economisi timp prețios de documentare și l-am putea folosi pentru testare.

Ce veți învăța:

Cazurile de testare sunt înlocuite rapid cu scenarii de testare?

Cu timpul, pe măsură ce totul se schimbă, industria și procesele software s-au schimbat, de asemenea, foarte mult.

test online gratuit pentru testare manuală

Tradiţional Cascadă și Modele în V sunt înlocuite de modele agile și iterative. Documentarea este necesară dar pentru a respecta termenele și pentru a face procesul ușor și transparent, modul de documentare poate fi schimbat.

Când este importantă documentarea cazurilor de testare?

  1. Clientul a cerut același lucru ca parte a proiectului.
  2. Nu există o constrângere de timp (nu cred că este posibil).
  3. Testerele sunt mai proaspete sau necunoscute pentru produs.
  4. Politica companiei (cred cu tărie că poate fi schimbată).

Permiteți-mi să vă împărtășesc o experiență:

Eu și echipa mea am fost implicați în testarea unui proiect de la o companie Fortune 500 cu termene flexibile. Am documentat cazurile de testare cu cel mai bun șablon disponibil și l-am aprobat de către client.

Odată ce versiunea a început să fie lansată echipei QA, pentru cea mai mare parte a zilei, datoria noastră era să urmărim mecanic 100 de cazuri de testare pe zi, să actualizăm documentul cu rezultatul de trecere / eșec și să îl trimitem clientului la sfârșitul zilei. Cele mai multe dintre membrii echipei au început să se plângă muncă monotonă dar compania genera venituri.

Apoi a existat o pauză pentru o zi între ele, fără o nouă construcție de testat. Ne-am așezat împreună la începutul zilei și discutam ce aveam să facem pentru ziua respectivă. Când mi-am propus să generez mai multe idei pentru a îmbunătăți documentul cazului de testare, toți membrii echipei au negat depunerea eforturilor.

Conform acestora, nu mai era nimic de gândit, deoarece am acoperit toate scenariile. Și convingându-i să gândiți-vă dintr-o cutie și generați mai multe idei a fost foarte dur.

De cele mai multe ori, când documentăm cazurile de testare și asta și odată aprobate de client, mintea umană crede că ne-am făcut treaba și mintea noastră încetează automat să ia în considerare orice efort de a se gândi la alte modalități de testare a produsului.

Și credeți-mă, când documentul de testare a cazurilor este pregătit, vrem doar să îl urmărim mecanic. Spuneți-mi de câte ori în carieră ați experimentat că dvs. sau colegul de echipă ați oferit cazuri de testare suplimentare documentului aprobat de cazuri de testare?

Încă o experiență:

În timpul activității săptămânale de provocare a echipei, am anunțat aplicația și le-am cerut membrilor echipei să prezinte scenarii de testare.

Toți membrii echipei, inclusiv cei care au răspuns sau care nu au răspuns, au pus idei. De ce? Nu a existat nicio documentație formală în care trebuie să completeze rezultatul scontat pentru fiecare secvență de funcționalitate și precondiție pentru fiecare caz de testare. Am colectat 40 de scenarii de testare într-o zi și a fost o experiență extraordinară.

Pentru a-mi favoriza experiența, Aș dori să prezint un exemplu.

Luați un exemplu de aplicație, spuneți pagina de conectare cu butoane de nume de utilizator, parolă, conectare și anulare. Dacă vi se cere să scrieți cazuri de testare pentru același lucru, vom ajunge să scriem mai mult de 50 de cazuri de testare prin combinarea diferitelor opțiuni și detalii.

Dar dacă scenariile de testare vor fi scrise, va fi vorba de 10 rânduri după cum urmează:

Scenariu la nivel înalt: Funcționalitate de conectare
Scenarii de nivel scăzut :

dfs și bfs c ++

1. Pentru a verifica Aplicația se lansează
2. Pentru a verifica conținutul textului pe pagina de autentificare
3. Pentru a verifica câmpul Nume utilizator
4. Pentru a verifica câmpul Parolă
5. Pentru a verifica butonul Login și a anula funcționalitatea butonului

Vezi si=> 180+ Scenarii de testare a probelor pentru testarea aplicațiilor web și desktop.

Deoarece cu toții ne lipsește timpul, scenariile de testare funcționează mai degrabă ca spray de analgezic decât ca IODEX de altădată. Și totuși, efectul este același.

Diferențele dintre scenariul de testare și testul cazului în format tabelar

În cele din urmă, aș dori să rezum diferența dintre scenariul de testare și cazul de testare:

Cazuri de testareTestează scenarii
Ce este => Un concept care oferă informații detaliate despre ceea ce trebuie testat, pașii care trebuie luați și rezultatul preconizat al acestuiaUn concept care oferă informații pe o singură linie despre ceea ce trebuie testat.
Este vorba despre => Este mai mult despre documentarea detaliilor.Este mai mult despre a gândi și a discuta detalii.
Importanță => Este important atunci când testarea nu este garantată și dezvoltarea este la fața locului. Scrierea cazurilor de testare cu detalii va ajuta sincronizarea atât a echipei dev, cât și a echipei QA.Este important atunci când timpul este mai mic și majoritatea membrilor echipei pot fi de acord / să înțeleagă detaliile din scenariul unic.
Avantaj => O documentare unică a tuturor cazurilor de testare este benefică pentru a urmări runde de 1000 de teste de regresie în viitor.
De cele mai multe ori, este util în timpul raportării erorilor. Testerul trebuie doar să furnizeze referința ID-ului cazului de testare și nu necesită menționarea fiecărui detaliu minut.
O activitate de economisire a timpului și de generare de idei, preferată de comunitatea de testare software de nouă generație.
Modificarea și adăugarea sunt simple și nu specifice unei persoane.
Pentru un proiect uriaș, în care grupul de oameni cunoaște doar module specifice, această activitate oferă șansa tuturor să privească în alte module și să creeze furtuna creierului și să discute
Benefic pentru => Un document complet de caz de testare este o linie de viață pentru noul tester.O acoperire bună a testului poate fi realizată prin împărțirea aplicației în scenarii de testare și reduce repetabilitatea și complexitatea produsului
Dezavantaj => Consumă timp și bani, deoarece necesită mai multe resurse pentru a detalia totul despre ce să testați și cum să testațiDacă este creat de o anumită persoană, recenzorul sau celălalt utilizator ar putea să nu sincronizeze ideea exactă din spatele acestuia. Aveți nevoie de mai multe discuții și eforturi de echipă.

Concluzie

Cazurile de testare sunt cea mai importantă parte a ciclului de viață al dezvoltării software-ului și fără acesta, este dificil să urmăriți, să înțelegeți, să urmăriți și să argumentați ceva. Dar în era Agile, cazurile de testare sunt înlocuite rapid cu scenarii de testare.

Un obisnuit lista de verificare a testului pentru fiecare tip de testare (testarea bazei de date, testarea GUI, testarea funcționalității, etc.) împreună cu scenariile de testare este artileria modernă pentru testerii de software. Discuțiile, instruirea, întrebările și practica pot schimba cu siguranță graficul final al productivitatea ta precum și o matrice de raportare Bug.

Ca de obicei, vă salutăm gândurile și întrebările. Vă rugăm să acordați.

PREV Tutorial | NEXT Tutorial

Lectură recomandată

^