7 Principii ale testării software-ului cu exemple

Acest tutorial prezintă cele șapte principii de bază de testare a software-ului pe care ar trebui să le cunoască fiecare testator de software și profesionist QA.

Să învățăm principiile de testare cu următoarele exemplu video-

Clic aici dacă videoclipul nu este accesibil

Context

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. Iată cele șapte principii comune de testare care sunt practicate pe scară largă în industria software.

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 prin 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 COSTURILE ar crește exponențial. Avem nevoie de anumite principii și strategii pentru a optimiza efortul de testare

Iată cele 7 principii:

1) Testarea exhaustivă nu este posibilă

Da! 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ă vă provoace Operasistemul de ting eșuează?

Sunt sigur că majoritatea dintre voi ați fi ghicit, deschizând 10 aplicații diferite, toate în același timp.

Deci, dacă ai testa asta OperaȚineți seama că defectele pot fi găsite în activitatea multi-tasking și trebuie testate temeinic, ceea ce ne duce la următorul nostru principiu. Defect ClusterING

2) Defect ClusterING

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) Paradoxul pesticidelor

Utilizarea repetitivă a aceluiași amestec de pesticide pentru eradicarea insectelor în timpul agriculturii va duce, în timp, la insectele să dezvolte rezistență 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 fi riscat 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ă Testare software 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 ce se întâmplă dacă ai munci din greu, luând toate măsurile de precauție și să faci produsul tău software 99% fără erori. Și software-ul nu satisface nevoile și cerințele clienților.

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

5) Absența erorii – eroare

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ă construcția sistemului este inutilizabilă și nu îndeplinește nevoile și cerințele utilizatorului.

Pentru a rezolva această problemă, următorul principiu de testare prevede că 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 defecte în cerințele sau faza de proiectare să fie surprinse în faze incipiente. Este mult mai ieftin să remediați un defect în primele etape ale testării. Dar cât de devreme ar trebui să înceapă testarea? 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 antrenament ulterior.

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 pe 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.

Mit: „Principiile sunt doar pentru referință. Nu le voi folosi în practică.”

Acest lucru este atât de neadevărat. Principiile de testare vă vor ajuta să creați un sistem eficient Strategia de testare și proiecte de cazuri de testare pentru captarea erorilor.

Dar învățarea principiilor de testare este la fel ca învățarea de a conduce pentru prima dată.

Inițial, în timp ce înveți să conduci, acorzi atenție tuturor și la toate, cum ar fi schimbările de viteză, viteza, manevrarea ambreiajului etc. Dar, cu experiență, te concentrezi doar pe condus, restul vine de la sine. Astfel încât să ții chiar conversații cu alți pasageri din mașină.

Același lucru este valabil și pentru principiile de testare. Testerii cu experiență au interiorizat aceste principii la un nivel în care le aplică chiar și fără să se gândească. Prin urmare, mitul potrivit căruia principiile nu sunt folosite în practică este pur și simplu neadevărat.