Acest tutorial introduce cele șapte principii de bază de testare a software-ului pe care ar trebui să le cunoască fiecare tester de software și profesionist în QA.
7 Principii de testare software
- Testarea arată prezența defectelor
- Testarea exhaustivă nu este posibilă
- Testarea timpurie
- Clusterarea defectelor
- Paradoxul pesticidelor
- Testarea depinde de context
- Absența erorilor eroare
Să învățăm principiile de testare cu următorul exemplu video-
Faceți clic aici dacă videoclipul nu este accesibil
fundal
Este important să obțineți rezultate de testare optime în timp ce efectuați teste software fără a abate de la obiectiv. Dar cum determinați că urmați strategia potrivită pentru testare? Pentru aceasta, trebuie să respectați câteva principii de testare de bază. Iată cele șapte principii comune de testare care sunt practicate pe scară largă în industria software-ului.
Pentru a înțelege acest lucru, luați în considerare un scenariu în care mutați un fișier din folderul A în dosarul 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
- Încercarea de a muta fișierul când este deschis
- Nu aveți drepturile de securitate pentru a lipi fișierul în folderul B.
- Dosarul B este pe o unitate partajată, iar capacitatea de stocare este completă.
- Dosarul B are deja un fișier cu același nume, de fapt, lista este interminabilă
- 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, proiectul EXECUTION TIME & COSTS 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.
Iar î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 cea mai probabilă ca urmare a defectării sistemului dvs. de operare?
Sunt sigur că majoritatea dintre voi ar 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ă este posibil ca defectele să se regăsească în activitatea multi-tasking și să fie testate cu atenție, ceea ce ne duce la următorul nostru principiu Defect Clustering
2) Clusterarea defectelor
Clusterarea defectelor, care afirmă că un număr mic de module conțin majoritatea defectelor detectate. Aceasta este aplicația principiului Pareto la testarea software-ului: aproximativ 80% din probleme se găsesc în 20% din module.
Prin experiență, puteți identifica astfel de module riscante. Dar această abordare are propriile sale probleme
Dacă aceleași teste se repetă iar și iar, în cele din urmă aceleași cazuri de test nu vor mai găsi noi erori.
3) Paradoxul pesticidelor
Utilizarea repetată a aceluiași amestec de pesticide pentru eradicarea insectelor în timpul cultivării va duce, în timp, la dezvoltarea insectelor de rezistență la pesticide. Prin urmare, ineficiența 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 noi și diferite cazuri de testare pentru a găsi mai multe defecte.
Testerii nu pot depinde pur și simplu de tehnicile de testare existente. El trebuie să se uite continuu pentru a îmbunătăți 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 conduce acasă acest punct, să vedem acest videoclip al lansării publice a Windows 98
Credeți că o companie precum MICROSOFT nu și-ar fi testat sistemul de operare cu atenție și și-ar risca reputația doar pentru a-și vedea sistemul de operare prăbușit în timpul lansării sale publice!
4) Testarea arată o prezență a defectelor
Prin urmare, principiul testării afirmă că - Testarea vorbește despre prezența defectelor și nu vorbește despre absența defectelor. De exemplu, testarea software reduce probabilitatea ca defectele nedescoperite să rămână în software, dar chiar dacă nu se găsesc defecte, nu este o dovadă a corectitudinii.
Dar ce se întâmplă dacă lucrați din greu, luând toate măsurile de precauție și faceți produsul software 99% fără erori. Iar 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 cerința greșită. Testarea software-ului nu este 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ă construirea sistemului este inutilizabilă și nu îndeplinește nevoile și cerințele utilizatorului.
Pentru a rezolva această problemă, următorul principiu al testării afirmă că Testarea timpurie
6) Testarea timpurie
Testarea timpurie - Testarea ar trebui să înceapă cât mai curând posibil în ciclul de viață al dezvoltării software-ului. Astfel încât orice defecte ale cerințelor sau ale fazei de proiectare să fie capturate în stadii 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 eroarea în momentul în care sunt definite cerințele. Mai multe despre acest principiu într-un tutorial de formare ulterior.
7) Testarea este dependentă de context
Testarea depinde de context, ceea ce înseamnă practic că modul în care testați un site de comerț electronic va fi diferit de modul în care testați o reclamă publicitară. Toate software-urile dezvoltate nu sunt identice. S-ar putea să utilizați o abordare diferită, metodologii, tehnici și tipuri de testare, în funcție de tipul aplicației. De exemplu, testarea, orice sistem POS dintr-un magazin cu amănuntul va fi diferit de testarea unui bancomat.
Mitul: "Principiile sunt doar pentru referință. Nu le voi folosi în practică."
Acest lucru este foarte neadevărat. Principiile de testare vă vor ajuta să creați o strategie de testare eficientă și să proiectați cazurile de testare a erorilor.
Dar învățarea principiilor de testare este la fel ca a învăța să conduci pentru prima dată.
Inițial, în timp ce înveți să conduci, ești atent la fiecare, cum ar fi schimbările de viteză, viteza, manevrarea ambreiajului, etc. Dar, cu experiență, te concentrezi doar asupra conducerii, restul vine natural. Astfel încât poți purta 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 pe care le aplică chiar și fără să se gândească. Prin urmare, mitul conform căruia principiile nu sunt folosite în practică pur și simplu nu este adevărat.