Procesul de testare

Executarea testelor este importantă însă există și alte activități pe care trebuie să le îndeplinim, cum ar fi crearea unui plan de testare sau raportarea rezultatelor.

La bază, procesul de testare este aproximativ la fel indiferent de situație, însă poate să difere nivelul de formalitate sau activitățile desfășurate în fiecare etapă a procesului (principiul 6 – testarea e dependentă de context). Nivelul de formalitate se decide în funcție de tipul de software și riscurile asociate acestui software. Pentru un software de care depinde siguranța unei persoane, în mod sigur vor fi respectate procesele cu rigurozitate.

Câțiva factori care influențează procesul de testare sunt:

  • Domeniul și tipul de business
  • Riscurile software-ului
  • Modelul de Software Development Life Cycle folosit în companie/proiect (Agile, Waterfall etc)
  • Nivelul, tipurile și tehnicile de testare care se doresc a fi folosite (System testing, Functional testing, Black-box testing etc)
  • Dimensiunea proiectului
  • Buget, resurse și termene limită
  • Practicile și standardele companiei/proiectului

Așadar, fazele procesului de testare software sunt următoarele:

  • Test planning
  • Test control
  • Requirements analysis and test design
  • Test creation
  • Test execution
  • Evaluating exit criteria and reporting
  • Test closure activities.

În funcție de proiect, aceste etape pot fi executate în altă ordine sau chiar să se suprapună.

1. Test planning

În perioada de test planning ne asigurăm că înțelegem obiectivele clienților/proiectului și riscurile asociate testării. Bazat pe aceste informații vom stabili obiectivele testării propriu-zise și vom crea un plan de testare (Test Plan), care definește următoarele aspecte:

  • Scop și obiective de testare (ex: dorim ca prin activitățile de testare să ne asigurăm că software-ul îndeplinește cerințele tehnice, funcționale și de business)
  • Ce se testează: descrierea software-ului sau a componentelor unui software care trebuie să fie testate
  • Test approach: se determină tehnicile de testare, cum se va desfășura testarea, cât de mult trebuie testat (ce coverage să aibă testele)
  • Resurse: persoanele care vor testa, test environment, echipamente hardware și identificarea oricăror altor nevoi care pot să apară pe parcursul testării
  • În funcție de ce Software Development Life Cycle este folosit, se încadrează activitățile de testare într-un orizont de timp sau se stabilește contextul în care începe testarea
  • Riscuri
  • Exit criteria – se stabilesc criterii care trebuie îndeplinite pentru a putea considera testarea completă (exemplu: test coverage de 80%)

2. Test control

Test control-ul este o activitate care se desfășoară pe toată perioada testării și presupune că mereu se compară progresul actual cu cel planificat (Test Plan) și se iau măsurile necesare. În acest context, pe parcursul procesului de testare, Test Plan-ul poate suferi modificări. Exemple de activități:

  • Se analizează rezultatele testelor (câte teste sunt passed/failed, considerându-se și prioritatea lor)
  • Se monitorizează test coverage-ul
  • Se documentează progresul și se transmit rapoarte către manager sau/și echipă
  • Se iau măsuri când este necesar (exemple: se prioritizează defectele care au severitate ridicată, se testează mai mult unde s-au descoperit/corectat defecte, etc) – Test Plan-ul se actualizează cu aceste măsuri

3. Requirements analysis and test design

În această etapă se analizează requirement-urile, se indentifică elementele care pot fi testate și se schițează Test Case-urile (se crează doar o listă cu Test Case-uri sau o structură, ele urmând a fi implementate în etapa următoare).

Ce este un requirement?

Requirement-urile sunt niște documente care conțin informații despre funcționalități, design sau despre comportamentul unui software. Astfel de documente fie sunt primite de la client, fie există un membru al echipei care adună informațiile și creează documentele.

Exemple de documente care pot fi folosite ca și requirements: software requirements, business requirements, system requirements, epic stories, use cases, functional requirements, performance requirements, diagrame UML, design, etc.

Pe baza acestor documente programatorii vor crea software-ul, iar testerii vor crea teste.

Ce face un tester în această etapă?

Câteva activități care se desfășoară în perioada de requirements analysis and test design sunt:

  • Se analizează requirement-urile cu scopul de a:
    • Identifica funcționalități care trebuie (și pot fi) testate
    • Identifica lipsurile și ambiguitățile și pentru a cere clarificări (o eroare nedescoperită în requirements poate duce la implementarea greșită a software-ului)
  • Se crează high-level Test Cases – este mai degrabă o listă cu Test Case-uri care urmează a fi dezvoltate mai târziu. Prima dată ne creăm o imagine de ansamblu și planificăm ce avem de făcut, abia apoi trecem la crearea lor (exemplu de high-level Test Case: “User-ul se poate loga pe site folosind credențialele corecte”)
  • Se grupează Test Case-urile în Test Suites – sunt grupate acele Test Case-uri care acopera o anumită zonă cum ar fi partea de login
  • Test Case-urile care acopera o anumită funcționalitate se grupează în Test Suites (spre exemplu, testele pentru Login pot fi grupate împreună, testele pentru adăugarea unui produs în coșul de cumpărături pot reprezenta un alt Test Suite)
  • Se identifică alte nevoi, spre exemplu tool-uri (și se modifică Test Plan-ul dacă este necesar)

4. Test creation

Pe baza Test Case-urilor high-level dezvoltate anterior se începe crearea Test Case-urilor low-level (descriu detaliat cazul de test, conțin expected results etc).

Exemple de activități:

  • Crearea testelor manuale (conțin descriere, pași de test, expected result și actual result)
  • Crearea testelor automatizate (dacă e cazul)
  • Prioritizarea testelor
  • Pregătirea/verificarea test environment-ului

Mai multe detalii despre crearea și prioritizarea Test Case-urilor sunt prezentate în lecția următoare.

5. Test execution

Se începe executarea testelor în conformitate cu Test Plan-ul. Deci testerul va fi ocupat cu:

  • Executarea Test Case-urilor, fie ele manuale sau automate
  • Compararea rezultatelor obținute (actual results) cu cele așteptate (expected results) – în cazul testelor manuale
  • Verificarea rezultatelor obținute în urma executării testelor automate – dacă sunt teste care au picat atunci trebuie investigată cauza (testul e de vină sau chiar e un bug?)
  • Examinarea anomaliilor și a potențialelor defecte/bug-uri
  • Logarea rezultatelor în Test Case-uri. Exemplu: Passed (testul a trecut) / Failed (testul a picat)
  • Raportarea bug-urilor – este recomandat ca de îndată ce suntem siguri că avem de-a face cu un bug, să îl și raportăm chiar dacă mai avem de testat

6. Test closure activities

Chiar dacă s-au rulat toate testele, mai sunt câteva lucruri care trebuie făcute, cum ar fi:

  • Raportarea rezultatelor prin crearea unui document numit Test Report (periodic sau la finalul perioadei de testare) – acest document va fi folosit de echipă, manager, client, etc
  • Ne asigurăm că toate bug tickets (rapoartele bug-urilor) au fost procesate (fie corectate și retestate, fie amânate pentru un release următor sau respinse din motive obiective)
  • Se face o retrospectivă pentru a identifica aspecte care ar putea fi îmbunătățite în viitor.