Acest tutorial explică ce este un scenariu de testare împreună cu importanța, implementarea, exemplele și modelele unui scenariu de testare:
Orice funcționalitate/caracteristică software care poate fi testată se numește scenariu de testare. Perspectiva utilizatorului final este luată în considerare la scrierea scenariilor de testare.
Acest tutorial vă va ajuta să răspundeți la întrebările: de ce sunt necesare scenariile de testare, când se scriu scenariile de testare și cum se scriu scenariile de testare.
Ce este un scenariu de testare?
Luați în considerare o situație ipotetică: Există un ocean imens, pe care trebuie să-l traversezi de la un țărm la altul. De exemplu, de la Mumbai, India Seashore la Colombo, Srilanka Seashore.
Modurile de călătorie pentru care puteți opta sunt:
(i) Căile aeriene: Luați un zbor spre Colombo
(ii) Căile navigabile: Preferați o navă pentru a călători la Colombo.
(iii) Căile ferate: Luați un tren spre Srilanka.
Trecem acum la scenariile de testare: Călătoria de la malul mării Mumbai la malul mării Colombo este o funcționalitate care trebuie testată.
Scenariile de testare includ:
- Călătoriile pe calea aerului,
- Călătorii pe căi navigabile sau
- Călătoria pe calea ferată.
Aceste scenarii de testare vor avea cazuri de testare.
Cazurile de testare care pot fi scrise pentru scenariile de testare de mai sus includ:
Scenariu de testare: Călătoriile pe calea aerului
Cazurile de testare pot include scenarii precum:
- Zborul se efectuează conform orei programate.
- Zborul nu este conform orarului programat.
- S-a creat o situație de urgență (ploi abundente și furtună).
În același mod, se poate scrie un set separat de cazuri de testare pentru alte scenarii rămase.
Să trecem acum la scenariile de testare tehnologică.
Orice lucru care poate fi testat este un scenariu de testare. Astfel, putem afirma că orice funcționalitate software care este testată poate fi împărțită în mai multe funcționalități mai mici și poate fi numită "scenariu de testare".
Înainte de a livra orice produs clientului, calitatea produsului trebuie apreciată și evaluată. Scenariul de testare ajută la evaluarea calității funcționale a unei aplicații software care este în conformitate cu cerințele de afaceri.
Un scenariu de testare este un proces prin care testerul testează o aplicație software din perspectiva utilizatorului final. Performanța și calitatea aplicației software sunt evaluate în detaliu înainte de implementarea în mediul de producție.
Importanța scenariului de testare
- Un scenariu de testare poate avea mai multe "cazuri de testare". Acesta poate fi considerat ca o imagine panoramică mare, iar cazurile de testare sunt părțile mici care sunt importante pentru a completa panorama.
- Este o declarație pe o singură linie, iar cazurile de testare cuprind o descriere etapizată pentru a completa scopul declarației scenariului de testare.
- Exemplu:
Scenariu de testare: Efectuați plata pentru serviciul de taxi utilizat.
Aceasta va avea mai multe cazuri de testare, după cum se menționează mai jos:
(i) Metoda de plată care trebuie folosită: PayPal, Paytm, Card de credit/debit.
(ii) Plata a fost efectuată cu succes.
(iii) Plata efectuată nu a avut succes.
(iv) Între timp, procesul de plată a fost întrerupt.
(v) Nu puteți accesa metodele de plată.
(vi) Aplicația se întrerupe între timp.
- Scenariile de testare ajută astfel la evaluarea aplicației software în funcție de situațiile din lumea reală.
- Scenariile de testare, atunci când sunt stabilite, ajută la bifurcarea domeniului de aplicare a testării.
- Această bifurcație se numește prioritizare, care ajută la determinarea funcționalităților importante ale aplicației software.
- Testarea prioritară a funcționalităților ajută într-o mare măsură la implementarea cu succes a aplicației software.
- Pe măsură ce scenariile de testare sunt prioritizate, cele mai importante funcționalități pot fi identificate cu ușurință și testate cu prioritate. Acest lucru asigură că majoritatea funcționalităților esențiale funcționează bine și că defectele legate de acestea sunt capturate și corectate în mod corespunzător.
- Scenariile de testare determină fluxul procesului de afaceri al software-ului și, astfel, este posibilă testarea de la un capăt la altul a aplicației.
Diferența dintre scenariul de testare și cazul de testare
| Scenariu de testare | Cazuri de testare |
|---|---|
| Scenariul de testare este un concept. | Cazurile de test sunt soluțiile pentru a verifica acest concept. |
| Scenariul de testare este o funcționalitate de nivel înalt. | Cazurile de testare sunt proceduri detaliate de testare a funcționalității de nivel înalt. |
| Scenariile de testare sunt derivate din cerințele/povestirile utilizatorilor. | Cazurile de testare sunt derivate din scenariile de testare . |
| Scenariul de testare este "Ce funcționalitate trebuie să fie testată". | Cazurile de testare sunt "Cum se testează funcționalitatea". |
| Scenariile de testare au mai multe cazuri de testare. | Cazul de testare poate sau nu să fie asociat la mai multe scenarii de testare. |
| Scenariile de testare unice nu sunt niciodată repetabile. | Un singur caz de testare poate fi utilizat de mai multe ori în diferite scenarii. |
| Se cer scurte documentații. | Este necesară o documentație detaliată. |
| Sunt necesare sesiuni de brainstorming pentru a finaliza un scenariu de testare. | Este necesară cunoașterea tehnică detaliată a aplicației software |
| Economisește timp, deoarece nu este nevoie de detalii amănunțite. | Consumă mult timp, deoarece trebuie să se țină cont de fiecare detaliu. |
| Costul de întreținere este scăzut, deoarece resursele necesare sunt reduse. | Costul de întreținere este ridicat, deoarece resursele necesare sunt mari |
De ce sunt indispensabile scenariile de testare?
Scenariile de testare sunt derivate din cerințe sau din poveștile utilizatorilor.
- Să luăm exemplul unui scenariu de testare pentru rezervarea unui taxi.
- Scenariile pot fi: opțiuni de rezervare a taxiurilor, metode de plată, urmărire GPS, harta rutieră afișată corect sau nu, detalii despre taxi și șofer afișate corect sau nu etc., toate acestea sunt enumerate în modelul de scenariu de testare.
- Să presupunem acum că scenariul de testare trebuie să verifice dacă serviciile de localizare sunt activate, iar dacă nu sunt activate, să afișeze mesajul "Activați serviciile de localizare". Acest scenariu este ratat și nu este listat în șablonul scenariilor de testare.
- Scenariul "Serviciu de localizare" dă naștere altor scenarii de testare legate de acesta.
Acestea pot fi:
- Serviciul de localizare a apărut în gri.
- Serviciul de localizare este activat, dar nu există internet.
- Restricții privind serviciile la fața locului.
- Este afișată o locație greșită.
- Lipsește un singur scenariu poate însemna să ratezi multe alte scenarii cruciale sau cazuri de testare Acest lucru poate avea o mare impact negativ în timpul implementării aplicației software, ceea ce duce la o mare pierdere de resurse (termene).
- Scenariile de testare ajută într-o mare măsură la evitarea testării exhaustive Se asigură că toate fluxurile de afaceri cruciale și așteptate sunt testate, ceea ce ajută și mai mult la testarea aplicației de la un capăt la altul.
- De asemenea, nu este necesară o descriere mult mai detaliată a cazurilor de testare. Se specifică o descriere de o linie despre ce trebuie testat.
- Scenariile de testare sunt scrise după sesiuni de brainstorming Astfel, probabilitatea de a rata orice scenariu (crucial sau minor) este minimă. Acest lucru se face ținând cont de aspectele tehnice și, de asemenea, de fluxul de afaceri al aplicației software.
- În plus, scenariile de testare pot fi aprobate fie de un client analist de afaceri, fie de ambii, care au cunoștințe explicite despre aplicația testată.
Scenariile de testare sunt astfel o parte indispensabilă a SDLC.
Implementarea scenariilor de testare
Să vedem cum se implementează scenariile de testare sau cum se scriu scenariile de testare:
- Se formează cerințele epice/de afaceri.
- Exemplu de Epic : Creați un cont Gmail. Epic poate fi o caracteristică majoră a unei aplicații sau o cerință de afaceri.
- Epopeea este împărțită în povestiri mai mici pentru utilizatori pe parcursul sprinturilor.
- Poveștile utilizatorilor sunt derivate din poveștile epice. Aceste povești ale utilizatorilor trebuie să fie definite și aprobate de către părțile interesate.
- Scenariile de testare sunt derivate din povestirile utilizatorilor sau din BRS (Business Requirement Document), SRS (System Requirement Specification Document) sau FRS (Functional Requirement Document), care sunt finalizate și bazate pe baze.
- Testatorii scriu scenariile de testare.
- Aceste scenarii de testare sunt aprobate de Team Lead, Business Analyst sau Project Manager, în funcție de organizație.
- Fiecare scenariu de testare trebuie să fie legat de cel puțin o poveste a utilizatorului.
- Trebuie identificate atât scenarii de testare pozitive, cât și negative.
- Poveștile utilizatorilor cuprind Criterii de acceptare, cum ar fi :
- Criteriile de acceptare sunt o listă de condiții sau starea de intenție pentru cerințele clientului. În redactarea criteriilor de acceptare se iau în considerare așteptările clientului, dar și neînțelegerile.
- Acestea sunt unice pentru o poveste de utilizator și fiecare poveste de utilizator trebuie să aibă cel puțin un criteriu de acceptare care trebuie să poată fi testat independent.
- Criteriile de acceptare ajută la determinarea caracteristicilor care fac parte din domeniul de aplicare și a celor care nu fac parte din domeniul de aplicare al unui proiect. Aceste criterii ar trebui să includă caracteristici funcționale și nefuncționale.
- Analiștii de afaceri scriu criteriile de acceptare, iar proprietarul produsului le aprobă.
- Sau, în unele cazuri, proprietarul produsului poate scrie el însuși criteriile.
- Scenariile de testare pot fi obținute din criteriile de acceptare.
Exemple de scenarii de testare
#1) Scenarii de testare pentru aplicația Kindle
Kindle este aplicația care permite cititorilor de cărți electronice să caute cărți electronice online, să le descarce și să le cumpere. Amazon Kindle oferă cititorului de cărți electronice experiența reală de a ține o carte în mână și de a o citi. Chiar și întoarcerea paginilor este frumos simulată în aplicație.
Acum să notăm scenariile de testare. ( Notă: Scenariile limitate sunt enumerate mai jos pentru a obține o idee generală pentru scrierea scenariului de testare. Pot exista mai multe cazuri de testare derivate din acesta).
| Scenarii de testare # | Scenarii de testare |
|---|---|
| 1 | Verificați dacă aplicația Kindle App se lansează corect. |
| 2 | Verificați dacă rezoluția ecranului se ajustează în funcție de diferitele dispozitive, după lansarea aplicației. |
| 3 | Verificați dacă textul afișat este lizibil. |
| 4 | Verificați dacă opțiunile de mărire și micșorare funcționează. |
| 5 | Verificați dacă fișierele compatibile importate în aplicația Kindle pot fi citite. |
| 6 | Verificați capacitatea de stocare a aplicației Kindle. |
| 7 | Verificați dacă funcționalitatea de descărcare funcționează corect. |
| 8 | Verificați dacă simularea Page Turn funcționează corect |
| 9 | Verificați compatibilitatea formatelor de cărți electronice cu aplicația Kindle. |
| 10 | Verificați fonturile acceptate de aplicația Kindle. |
| 11 | Verificați durata de viață a bateriei utilizate de aplicația Kindle. |
| 12 | Verificați performanța Kindle în funcție de conectivitatea rețelei (Wi-Fi, 3G sau 4G). |
Mai multe cazuri de testare pot fi derivate din fiecare scenariu de testare menționat mai sus.
#2) Criterii de acceptare pentru Google Docs
"Google Docs" este o aplicație bazată pe web pentru a crea, edita și partaja documente Word, foi de calcul, slide-uri și formulare. Toate fișierele pot fi accesate online folosind un browser web care are o conexiune la internet.
Documentele create pot fi partajate sub formă de pagină web sau de document gata de imprimare. Utilizatorul poate stabili restricții cu privire la persoanele care pot vizualiza și edita documentele. Un singur document poate fi partajat în mod colaborativ și poate fi prelucrat de diverse persoane din diferite locații geografice.
Mai jos sunt menționate scenarii de testare limitate pentru o înțelegere generală. Scenariile de testare în profunzime pentru Google Docs pot fi un subiect separat.
| Criterii de acceptare # | Criterii de acceptare |
|---|---|
| 1 | Word, Sheets sau Formularele pot fi deschise cu succes, fără erori. |
| 2 | Sunt disponibile șabloane pentru documente, foi și diapozitive. |
| 3 | Șabloanele disponibile sunt accesibile pentru utilizatori. |
| 4 | Șablonul utilizat este editabil (de exemplu: fonturi, dimensiunea fontului, adăugarea de text, ștergerea textului, inserarea de diapozitive). |
| 5 | În cazul în care conexiunea la internet nu este disponibilă temporar, fișierul poate fi stocat la nivel local și încărcat atunci când este disponibilă o conexiune la internet. |
| 6 | Modificările efectuate de mai mulți utilizatori nu sunt rescrise. |
| 7 | Mai mulți utilizatori pot lucra la un singur document. |
| 8 | Munca efectuată este stocată în cazul în care conexiunea la internet este pierdută în timpul încărcării unui fișier. |
| 9 | Restricțiile de partajare sunt aplicate corect. |
| 10 | Utilizatorii cu restricție de vizualizare nu pot efectua nicio modificare a documentelor. |
| 11 | Documentele pot fi publicate pe internet pentru publicul larg. |
| 12 | Modificările aduse documentelor sunt salvate cu ștampila de timp & detalii despre autor. |
Numărul de scenarii de testare va fi multiplu și foarte mare pentru Google Docs. În astfel de cazuri, în general, doar criteriile de acceptare sunt stabilite și aprobate de către părțile interesate, iar membrii echipei lucrează la aceste criterii de acceptare. Scrierea cazurilor de testare pentru sau mai degrabă a scenariilor de testare poate fi o sarcină exhaustivă pentru aplicații uriașe.
Aceste criterii de acceptare joacă un rol major în planificarea procesului iterativ și nu trebuie niciodată neglijate. Definirea lor în prealabil și în avans evită surprizele sau șocurile de la sfârșitul sprinturilor sau al versiunilor.
Având în vedere o condiție prealabilă.
Când pentru a efectua o acțiune.
Apoi rezultatul este cel așteptat.
Formatele "dat", "când" și "apoi" sunt utile pentru a specifica criteriile de acceptare.
Exemplu de șablon de scenariu de testare
| Utilizați numărul de identificare a poveștii | Scenariul de testare ID # | Versiunea # | Scenarii de testare | # Nr. de cazuri de testare | Importanță |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1.1 | Kin12.4 | Verificați dacă aplicația Kindle App se lansează corect. | 4 | Mare |
| USID12.1 | TSID12.1.2. | Kin12.4 | Verificați capacitatea de stocare a aplicației Kindle. | 3 | Mediu |
Concluzie
În orice testare de software, înțelegerea ciclului de viață și stabilirea scenariilor de testare este un element foarte important. Calitatea software-ului poate fi îmbunătățită prin existența unei baze bune pentru scenariile de testare. În mod frecvent, utilizarea cazurilor de testare și a scenariilor de testare poate fi schimbată.
Cu toate acestea, regula de bază este că scenariul de testare este utilizat pentru a scrie mai multe cazuri de testare sau putem spune că cazurile de testare sunt derivate din scenariile de testare. Scenariile de testare bine definite asigură o bună calitate a software-ului.