Cum sa facem requirements testing?

Stim cu totii despre conceptul de „cerinte pentru cerinte” (“requirements for requirements”). Caracteristici precum cat de complete si lipsite de ambiguitate sunt, consistenta, eficienta, grad de testare si asa mai departe. Pentru mine aceste “requirements for requirements” sunt mantre, deoarece nu este de fiecare data clar cum le putem testa pe bune.

Dar in software testing, orice defect in termeni de cerinte inseamna ca trebuie sa revizuim test cases, datele rezultate in urma testelor software, scripturile automate si testele repetate. Astfel ca, software testerii, mai mult decat oricare alti oameni din echipa, sunt implicati in verificarea acestor mantre.

O metoda eficienta, din punctul meu de vedere, pentru a le testa este designul timpuriu al scenariilor de testare (test scenarios). Poate nici macar scenariile de testare cat conditiile de testare (test conditions) sau ideile de testare (test ideas) – un set de planuri legate de CE si CU CE SCOP (dar nu cum) vom testa.

Si in paralel, incepi sa dezvolti conexiuni intre scenariile de testare si cerinte (ce si unde verificam) care apoi vor fi transformate intr-o full coverage matrix.

Cerinte si testare fara scenarii de testare si/sau software testeri

Multi credeau ca programatorii isi pot testa cu succes propriul cod (nu doar unit tests) si astfel nu era nevoie de software testeri. Apoi toata lumea a realizat ca nu era asa, dar idea ca putem avea teste fara testeri software nu a disparut.

O noua abordare este ca analistii de business sa faca testarea. Insa trebuie sa tinem minte ca testarea software in general si test design-ul in particular reprezinta arii diferite si fiecare are propriile reguli si tehnologii. Daca un business analyst nu are cunostinte de test engineering, nu va putea sa se ocupe de teste la nivelul la care trebuie si in perioada de timp dorita. Si daca au asemenea cunostinte atunci sunt sofware testeri (mai rar se intampla asta).

In final, sa tinem minte ca defectele la nivel de cerinte, sunt cele care sunt o prioritare pentru testeri.
Astfel ca, ar trebui ca analistii sa analizeze cerintele pe care le fac pentru a vedea daca exista defecte? Imi pare o situatie asemanataore cu cea in care programatorii isi testeaza propriul cod.

Cerinte si testare in proiectele de mentenanta software

In proiectele de mentenanta software cerintele minore duc la corectii minore la nivel de cod, care insa s-ar putea sa necesite un nivel ridicat de testare software. Exemplele tipice includ adaugarea unui nou camp pentru informatii sau code refactoring. Asta inseamna ca putem renunta la proportiile acceptate de programatori, software testeri si munca pentru programare si testare software. Aici trebuie sa ne concentram pe evaluarea adecvata si justificata a eforturilor de testare, lucru care poate sa fie facut doar de software testeri.

Cerinte si schimbari

Mai devreme am mentionat dezvoltarea unei test scenario coverage matrix. Din moment ce in toate proiectele software se pot intampla schimbari (si se intampla), dezvoltarea unei coverage matrix este o activitate obligatorie in procesul de testare software.

Coverage matrix ne permite sa aflam raspunsurile la urmatoarele intrebari:

• Ce scenarii de testare ar trebui sa fie folosite pentru a verifica o anumita cerinta?
• Care sunt cerintele ce trebuie verificate printr-un scenariu de testare concret?

Nevoia de a raspunde la prima intrebare apare cand trebuie sa evaluam eforturile pentru testarea schimbarilor la nivel de cerinte. Nevoia de a raspunde la doua intrebare apare atunci cand evaluam cat de critice sunt defectele software gasite in urma rularii unui scenariu de testare.

Cerintele legate de riscurile testarii software

Cele mai comune riscuri in testarea software apar datorita cerintelor incomplete. Cateva exemple ar fi:

• O calitate scazuta a cerintelor atunci cand incep testele, lucru care ne poate opri sa dezvoltam si sa aplicam scenarii de testare cu un nivel ridicat de calitate
• Intarzierea inceperii testarii software, care ne pote opri din a respecta termenele limita si cerintele legate de buget
• Absenta sau implementarea tarzie a unei evaluari temeinice a cerintelor, care ne poate opri din a implementa toate activitatile de testare la calitatea dorita
• Ignorarea test scenario coverage matrix pentru cerinte (spre exemplu, omiterea unor cerinte este descoperita din intamplare)

Vrei sa incepi o cariera in testare software sau sa iti imbunatatesti abilitatile de testare software? Descopera cursurile noastre.

Alexandr Alexandrov
Software Testing Consultant