Principiile testării software-ului

Este important să obțineți rezultate optime de testare în timp ce efectuați testarea software-ului fără a vă abate de la obiectiv. 

Dar cum stabiliți că urmați strategia potrivită pentru testare? 

Pentru aceasta, trebuie să respectați câteva principii de bază de testare. Pentru a înțelege acest lucru, luați în considerare un scenariu în care mutați un fișier din folderul A în folderul B.

Gândiți-vă la toate modalitățile posibile în care puteți testa acest lucru.

În afară de scenariile obișnuite, puteți testa și următoarele condiții:

• Încercați să mutați fișierul când este deschis
• Nu aveți drepturile de securitate pentru a lipi fișierul în folderul B
• Dosarul B se află pe o unitate partajată și capacitatea de stocare este plină.
• Folder B are deja un fișier cu același nume, de fapt, lista este nesfârșită
• Sau să presupunem că aveți 15 câmpuri de intrare de testat, fiecare având 5 valori posibile, numărul de combinații de testat ar fi 5^15

Dacă ar fi să testați toate combinațiile posibile ale proiectului, timpul de executare și costuri ar crește exponențial. Avem nevoie de anumite principii și strategii pentru a optimiza efortul de testare

Iată cele șapte principii comune de testare care sunt practicate pe scară largă în industria software:

1) Testarea exhaustivă nu este posibilă

Testarea exhaustivă nu este posibilă. În schimb, avem nevoie de cantitatea optimă de testare bazată pe evaluarea riscului aplicației.

Și întrebarea de un milion de dolari este, cum determinați acest risc?

Pentru a răspunde la asta, să facem un exercițiu:

În opinia dvs., care operație este cel mai probabil să provoace defecțiunea sistemului dvs. de operare?

La sigur majoritatea ați fi ghicit, deschizând 10 aplicații diferite, toate în același timp.

Deci, dacă ați testa acest sistem de operare, v-ați da seama că defectele pot fi găsite în activitatea multitasking și trebuie testate temeinic, ceea ce ne duce la următorul nostru principiu Defect Clustering.

2) Defect Clustering (Gruparea defectelor)

Defect Clustering care afirmă că un număr mic de module conțin majoritatea defectelor detectate. Aceasta este aplicarea Principiului Pareto la testarea software-ului: aproximativ 80% dintre probleme se găsesc în 20% din module.

După experiență, puteți identifica astfel de module riscante. Dar această abordare are propriile sale probleme

Dacă aceleași teste sunt repetate iar și iar, în cele din urmă aceleași cazuri de testare nu vor mai găsi erori noi.

3) Pesticide Paradox (Paradoxul pesticidelor)

Utilizarea repetitivă a aceluiași amestec de pesticide pentru eradicarea insectelor în timpul agriculturii va duce, în timp, la dezvoltarea rezistenței insectelor la pesticide, prin urmare ineficiente ale pesticidelor asupra insectelor. Același lucru este valabil și pentru testarea software-ului. Dacă se efectuează același set de teste repetitive, metoda va fi inutilă pentru descoperirea de noi defecte.

Pentru a depăși acest lucru, cazurile de testare trebuie să fie revizuite și revizuite în mod regulat, adăugând cazuri de testare noi și diferite pentru a ajuta la găsirea mai multor defecte.

Testerii nu pot depinde pur și simplu de tehnicile de testare existente. El trebuie să caute în mod continuu să îmbunătățească metodele existente pentru a face testarea mai eficientă. Dar chiar și după toată această transpirație și muncă grea în testare, nu puteți pretinde niciodată că produsul dvs. nu conține erori. Pentru a ajunge acasă la acest punct, să vedem acest videoclip cu lansarea publică a Windows 98.

Crezi că o companie precum MICROSOFT nu și-ar fi testat sistemul în detaliu și și-ar risca reputația doar pentru a-și vedea sistemul de operare prăbușindu-și în timpul lansării publice.

4) Testarea arată prezența defectelor

Prin urmare, principiul testării prevede că – Testarea vorbește despre prezența defectelor și nu vorbește despre absența defectelor. adică testarea software-ului reduce probabilitatea ca defecte nedescoperite să rămână în software, dar chiar dacă nu sunt găsite defecte, nu este o dovadă a corectitudinii.

Dar dacă ai munci din greu, luând toate măsurile de precauție și să faci produsul tău software să fie 99% fără erori. Și software-ul nu satisface nevoile și cerințele clienților.

Acest lucru ne conduce la următorul principiu, care afirmă - Absența erorii

5) Absența erorii – fallacy

Este posibil ca software-ul care este 99% fără erori să fie încă inutilizabil. Acest lucru poate fi cazul dacă sistemul este testat temeinic pentru o cerință greșită. Testarea software-ului nu înseamnă doar găsirea defectelor, ci și verificarea faptului că software-ul răspunde nevoilor afacerii. Absența erorii este o eroare, adică Găsirea și remedierea defectelor nu ajută dacă sistemul este inutilizabil și nu îndeplinește nevoile și cerințele utilizatorului.

Pentru a rezolva această problemă, următorul principiu de testare prevede Testarea timpurie.

6) Testare timpurie

Testare timpurie – Testarea ar trebui să înceapă cât mai devreme posibil în ciclul de viață al dezvoltării software. Astfel încât orice defecțiuni în cerințele sau faza de proiectare să fie surprinse în stadii incipiente. Este mult mai ieftin să remediați un defect în primele etape ale testării. 

Este recomandat să începeți să găsiți bug-ul în momentul în care cerințele sunt definite. Mai multe despre acest principiu într-un tutorial de instruire ulterioară.

7) Testarea depinde de context

Testarea depinde de context, ceea ce înseamnă că modul în care testați un site de comerț electronic va fi diferit de modul în care testați o aplicație comercială de la raft. Toate software-urile dezvoltate nu sunt identice. Puteți utiliza o abordare, metodologii, tehnici și tipuri de testare diferite, în funcție de tipul de aplicație. De exemplu, testarea, orice sistem POS dintr-un magazin cu amănuntul va fi diferit de testarea unui bancomat.