Uneori, testarea unui număr mare de noștri testere Fitch uită chiar și despre cele mai importante principii de testare și, prin urmare, face o mulțime de erori strategice și de comportament în testarea software-ului.
În acest articol, vă voi aminti principiile bine cunoscute și de bază despre care nu trebuie să uitați, când testați orice aplicație sau un nou Fitch
Principii de bază în testarea software-ului
Dintre cele mai multe principii pe care fiecare tester de testare software le-a identificat probabil pentru sine, sunt cele principale, în opinia comunității de testeri care ar dori să-și exprime singur:
1) Testarea exhaustivă nu este posibilă cu nici unul dintre testeri. Cred că toată lumea înțelege că este imposibil să testeze toate cazurile și combinațiile posibile, desigur, dacă acest lucru nu este un caz trivial.
Toate cazurile pur și simplu nu pot fi incluse în suita de testare, deoarece ne-ar lua foarte mult timp și în final nu ar merita efortul. Dacă fiecare tester va sta în jos și să se gândească cu atenție la toate scenariile și, dacă da, care Fitch a testa un alt tester, atunci, de obicei, este încă o mulțime de scenarii posibile și studii de caz care pot fi incluse. Prin urmare, în testarea software-ului pentru a analiza produsul acceptat sau un nou Fitch apoi să se concentreze eforturile în testarea pentru cazurile mai riscante și prioritare și părți ale produsului nostru.
2) Acumularea de bug-uri. Dacă luăm produsul și rupe-l în module, procesul de testare se poate observa că cea mai mare parte de bug-uri se află într-una sau mai multe unități de produs, prin urmare, efectul poate fi observat acumulări de bug-uri. De obicei, acest lucru poate fi observat în produse complet diferite. În scopul de a testa în mod eficient produsul nostru, ar trebui să aloce eforturile în testele efectuate pe densitatea reală a erorilor în modulele de produse, în cazul în care testul de prima dată, proporțional cu densitatea așteptată. În timp, tendința cu acumularea de bug-uri poate varia de la modul la modul. Acest lucru ar trebui monitorizat și redistribuit în testele viitoare.
3) Eficiența testelor timpurii. Este foarte important ca testarea să înceapă cât mai curând posibil și să anticipeze eventualele greșeli pe care dezvoltatorul le poate face.
Înainte de a dezvolta și testa un anumit produs, ar trebui să afli specificul unor posibile conflicte în caietul de sarcini, incapacitatea noului Fitch interactioneaza cu un alt modul, asigurați-vă că tester, dezvoltator și produsul ovner la fel de bine să înțeleagă modul în care acesta va fi pus în aplicare. Amintiți-vă, mai devreme există bug-uri mai ieftine pentru a le rezolva.
4) Paradoxul pesticidului. Dacă scrieți cazuri de testare, executați-le de multe ori, apoi eventual aceste cazuri nu ne vor ajuta să găsim noi erori. Prin urmare, există o practică de testare atunci când revizuirea și modernizarea cazurilor de testare pentru a prinde unele bug-uri noi. Cazurile de testare pot fi complicate, pot fi versatile pentru a acoperi toate componentele, modulele produsului nostru, care la rândul nostru ne vor ajuta să găsim mai multe bug-uri interesante și noi.
5) Testarea depinde de produsul nostru. Există multe programe, produse și fiecare dintre ele ar trebui să fie abordată individual în ceea ce privește testarea. În unele mai multe eforturi de testare, aveți nevoie de securitate, într-un fel de utilizare. Prin urmare, nu ar trebui să introduceți toate produsele sub același pieptene și să le testați pe orice șablon.
6) Testarea arată prezența bug-urilor în produs, dar nu și absența lor. Mulți oameni cred că dacă noul funcțional a trecut etapa de testare, atunci totul este un bug. Aceasta este eroarea de judecată. Testarea reduce numai probabilitatea de bug-uri în produs. Prin urmare, în procesul de testare, multe bug-uri pot fi sărite și nu înseamnă că dacă produsul a fost testat, acum acest produs este 100% funcționează corect.
7) Produsul este bine testat și se pare că nu există erori evidente, atunci acesta este un produs bun. Uneori, când testează și caută bug-uri funcționale, uităm să ne uităm la cealaltă parte și să întrebăm dacă utilizatorul are nevoie de ea. Dacă această fitchă nu corespunde așteptărilor utilizatorului și nevoilor sale, indiferent de calitatea produsului nostru - nu este atât de important.