Nivele de testare

În general, testarea este împărțită pe mai multe nivele: unit testing, integration testing, system testing și acceptance testing. Această împărțire se poate observa în V-cycle.

1. Unit testing

Unit testing presupune testarea individuală a unor module/unitați din software. Printr-o “unitate” se înțelege cea mai mică porțiune de cod (o funcție, o clasă, o metodă, etc) care poate fi testată separat. Acest tip de testare se mai numește Component Testing sau Module Testing.

Care sunt obiectivele?

  • Să se verifice dacă sunt respectate requirementurile la nivel de componentă
  • Să se descopere defectele din componentă care țin de funcționalitate sau structură, pentru a evita ca ele să ajungă la nivelele superioare de testare

Cine și cum testează?

De obicei unit testingul e responsabilitatea developerilor care au scris codul. Tehnica de testare folosită este de tip white-box (adică necesită acces la codul sursă), iar testele sunt automatizate. Developerii crează aceste teste după ce au scris o porțiune de cod, apoi le rulează. Dacă testele au picat, de obicei le corectează imediat fără a urma un proces formal (cum ar fi crearea un bug ticket).

2. Integration testing

După ce au fost executate unit tests pentru fiecare unitate/componentă din cod, acestea vor fi conectate împreună. Așadar, scopul Integration Testing-ului este de a testa interacțiunea dintre aceste componente.

Care sunt obiectivele?

  • Să se verifice dacă componentele funcționează corect odată ce au fost conectate
  • Să se verifice dacă sunt respectate requirementurile care privesc interacțiunea, interfața sau comunicația dintre componente (requirementurile pot fi legate de funcționalitate, performanță, securitate, etc)
  • Să se găsească defectele cât mai devreme în procesul de testare

Cine și cum testează?

Pentru Integration Testing se poate utiliza atât tehnica white-box (persoana care testează are acces la cod), cât și cea black-box (persoana care testează nu are acces la codul sursă și nu cunoaște structura internă a software-ului).

Abordând tehnica white-box, developerul sau un tester cu cunoștințe de programare va crea niște teste automate care vor verifica interacțiunea dintre componente.

Folosind tehnica black-box, testerul va verifica că un anumit modul este integrat corespunzător.

Exemplu – integration testing folosind tehnica black-box

Să luăm ca exemplu un shop online. Tocmai s-a integrat modulul de login, ceea ce înseamnă că un utilizator se poate autentifica pe site folosind un cont și o parolă. Prin urmare, trebuie testată interacțiunea dintre modulul de login și restul site-ului, adică să ne asigurăm că după ce am introdus credențialele și am apăsat pe butonul Login, vom fi redirecționați pe home page-ul site-ului. Dacă se întâmplă acest lucru, înseamnă că modulul de login a fost integrat corect.

3. Sytem testing

System testing se concentrează pe testarea unui produs software ca un întreg. Odată ce toate componentele au fost integrate și testele de integrare au trecut, software-ul este pregătit pentru system testing.

Care sunt obiectivele?

  • Să se verifice că software-ul funcționează conform requirementurilor funcționale și non-funcționale (stress test, load test, security test, configuration test, performance test, etc)
  • Să se găsească cât mai multe defecte – deși mai urmează un nivel de testare, acesta nu se folosește în toate proiectele, iar acest lucru înseamnă că defectele care nu se găsesc la system testing pot ajunge în producție

Cine și cum testează?

La acest nivel testerii vor verifica software-ul folosind tehnica de testare black-box. Testarea poate fi manuală sau/și automată.

Se dorește ca să fie acoperite toate requirementurile, să se testeze end-to-end (adică se consideră tot flow-ul aplicației, de la început și până la sfârșit) și să se testeze cât mai multe cazuri care se pot întâmpla în realitate.

Exemplu

Considerând un shop online, următoarele teste ar putea fi executate la nivel de system testing:

  • În primul rând, site-ul se deschide, toate paginile se încarcă și desingul site-ului e corespunzător
  • Utilizatorii se pot autentifica pe site, dacă există această opțiune
  • Opțiunea de căutare funcționează
  • Sunt afișate categoriile de produse
  • Se pot sorta produsele și se pot aplica filtre
  • Un produs poate fi vizualizat și adăugat în coș
  • Se poate finaliza comanda
  • Plata cu cardul funcționează corect și sunt respectate normele de securitate
  • Se trimite automat email cu datele comenzii
  • Site-ul funcționează corect și pe mobil
  • Site-ul funcționează corect pe diferite sisteme de operare și browsere

În realitate ar fi mult mai multe teste care ar trebui executate pentru un astfel de site.

4. Acceptance testing

Prin Acceptance Testing se verifică dacă software-ul este pregătit pentru a fi lansat pe producție și pentru a fi folosit de end users (utilizatorii finali).

Acest tip de testare urmează după system testing și este ultimul nivel de testare.

Care sunt obiectivele?

  • Produsul software funcționează conform requirementurilor – în special business requirements
  • Se determină dacă produsul satisface nevoile clientului sau/și a utilizatorilor finali

Cine și cum testează?

Pentru acceptance testing se abordează tehnica de testare black-box. Persoanele care testează pot să fie testerii, o altă persoană din echipă sau chiar clientul pentru care se dezvoltă software-ul.

Tipuri de Acceptance Testing

Acceptance testing se împarte în mai multe categorii:

User Acceptance Testing (UAT)

Scopul UAT este să se verifice dacă produsul îndeplinește funcțiile pentru care a fost creat și dacă este ușor de folosit de către utilizatorii finali (end users). De obicei este executat de către client sau de utilizatorii finali, însă mai sunt situații în care testarea se face de către o persoană din echipa care a dezvoltat produsul cum ar fi product owner sau chiar de către testeri. De obicei se folosește testarea funcțională și se verifică funcționalitățile de bază.

UAT ar putea răspunde la întrebări precum:

  • Acest produs este ușor de utilizat de către end users?
  • Produsul satisface nevoile end userilor?
  • Produsul funcționează conform cerințelor de business?

Operational Acceptance Testing (OAT)

OAT este un tip de testare non-funcțională și se verifică aspecte precum performanță, backup/recovery, compatibilitate cu diverse device-uri sau sisteme de operare, mentenabilitate, etc.

Alpha testing

Testarea Alpha este organizată în cadrul companiei care a creat produsul, iar testarea efectivă este realizată de către persoane care ar putea fi potențiali utilizatori ai software-ului, fie că sunt angajați sau din exterior. Este indicat ca acele persoane să nu fi fost direct implicate în crearea produsului (programatori, testeri).

Beta testing

Testarea Beta se face de către utilizatori reali care folosesc software-ul pe device-urile personale. Ei vor raporta companiei eventualele bug-uri și care a fost experiența lor ca și utilizatori.