Principiile testării

1. Testarea exhaustivă nu este posibilă

Testarea tuturor posibilităților nu este fezabilă, iar în anumite situații este chiar imposibilă. E nevoie de o cantitate optimă de testare bazată pe o analiză de risc a aplicației, alegerea tehnicilor potrivite de testare și prioritizarea testelor.

Un exemplu simplu ar fi să considerăm că avem de testat un câmp care accepta doar numere din intervalul [1, 100]. Nu are sens să testăm dacă fiecare număr din acest interval este acceptat. Ar însemna să avem mai mult de 100 de test case-uri (considerând scenariile valide plus cele invalide cum ar fi numerele mai mici ca 0 sau mai mari ca 100). Ce s-ar întâmpla dacă am avea de testat un câmp care acceptă numere de la 1 la 1000000?

În astfel de cazuri folosim tehnici precum Equivalence Partitioning și Boundary Values, care ne ajută să reducem numărul de Test Case-uri. Prin Equivalence Partitioning alegem câteva seturi de valori care vor fi procesate în același fel, iar din fiecare set vom testa o singură valoare (exemplu: set de date valide cu 1 cifra, set de date valide cu 2 cifre, set de date invalide, s.a.m.d.). Tehnica Boundary Values este o extensie pentru Equivalence Partitioning prin care se testează și valorile limită ale intervalului (ex: 0, 1, 2, 99, 100, 101).

Concluzie: în loc de >100 Test Case-uri vom avea maxim 10 Test Case-uri. Timpul și efortul s-au redus considerabil.

2. Testarea arată prezența defectelor și nu garantează lipsa lor

Prin testare se pot descoperi defecte și se poate reduce considerabil numărul acestora, dar nu se poate garanta că un software nu mai are nici un defect. Chiar și atunci când toate testele noastre trec, nu putem dovedi că software-ul are 0 defecte.

3. Testarea timpurie

Testarea ar trebui să înceapă cât mai devreme în procesul de dezvoltare (Software Development Life Cycle – SDLC) pentru a salva timp și bani. Încă din fazele incipiente ale proiectului, când se pun cap la cap requirement-uri, se poate executa testare statică (adică nu presupune executarea componentei care se testează – poate fi spre exemplu revizuirea requirement-urilor, a Test Planului, a Test Case-urilor, a codului sursa etc) asupra requirement-urilor pentru a identifica lipsuri, contraziceri etc.

 De îndată ce este gata prima versiune testabilă a software-ului, se poate începe testarea dinamică (acest tip de testare presupune executarea software-ului – spre exemplu, deschiderea site-ului și executarea diferitor acțiuni).

4. Gruparea defectelor

Acest principiu se referă la faptul că defectele nu vor fi împărțite uniform în mai multe module ale aplicației software, ci vor fi concetrate într-o anumită zonă. Acest lucru ajută la reducerea numărului de Test Case-uri și a timpilor de testare.

5. Paradoxul pesticidului

Repetarea acelorași teste va deveni ineficientă în timp și nu se vor mai descoperi defecte noi.

Dacă aceleași teste vor fi repetate la nesfâșit, de la un moment dat acestea nu vor mai găsi defecte noi. De aceea e recomandat să se actualizeze din când în când testele și datele cu care se testează. Poate chiar să fie adăugate teste noi.

Desigur, acest principiu s-ar putea să nu fie aplicabil în toate cazurile. Spre exemplu, dacă avem teste de regression automatizate.

Principiul se numește astfel deoarece funcționează asemenea pesticidului folosit în culturile agricole: folosirea aceleiași substanțe pentru înlăturarea insectelor de la un moment dat nu va mai avea efect.

6. Testarea diferă în funcție de context

Testarea se va face diferit în contexte diferite. Spre exemplu, nu se va testa în același fel un modul dintr-o mașina care este reponsabil de siguranța șoferului și un joc pentru telefon.

De asemenea, testarea poate fi diferită în funcție de modul de lucru. În companiile unde se folosește metodologia Agile testarea va fi diferită față de o companie în care se folosește metodologia Waterfall.

7. Nu există software lipsit de erori

După cum știm din primele două principii, nu se poate testa 100% un software și nu se pot găsi toate defectele. Deci mereu va exista șansa ca să apară un defect sau o problemă.

Spre exemplu, chiar dacă au fost găsite și s-au corectat foarte multe defecte, cerințele clientului au fost respectate întocmai și să presupunem că 99% din software funcționează conform acestor cerințe, tot nu se poate garanta succesul aplicației software. Există posibilitatea ca acea aplicație să fie greu te utilizat de către consumatori, nu e user-friendly.