7.

Testarea depinde de context, ceea ce înseamnă practic că modul în care

testam un site de comerț electronic va fi diferit de modul în care testam o
reclamă publicitară .

-testarea unui sistem POS dintr-un magazin cu amănuntul va fi diferit de

testarea unui bancomat ., modul în care testăm un magazin online este diferit de
testarea unei aplicații Window.

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

6. Testarea timpurie - Testarea ar trebui să înceapă cât mai curând posibil în

ciclul de viață al dezvoltării software-ului.

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

5, Este posibil ca software-ul care este 99% fără erori să fie încă inutilizabil .

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

4. 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.-  Există anumite tehnici de testare în care
programatorii fac intenționat unele erori în software. De exemplu 5. Dacă testerii găsesc
4, putem spune că software-ul este 80% OK.

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

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

2. 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.- modulul de
facturare cu un link către sistemul contabil. Aceste tipuri de module prezintă cel mai
mare risc de erori.

-Chiarși atunci când toate testele noastre trec, nu putem dovedi că

software-ul are 0 defecte

1. Testarea exhaustivă nu este posibilă. În schimb, avem nevoie de cantitatea

optimă de testare bazată pe evaluarea riscului aplicației.

-defectele să se regăsească în activitatea multi-tasking și să fie testate cu

atenție, 10 utilizatori diferiți să deschidă aplicațiile în același timp.

-înloc de >100 Test Case-uri vom avea maxim 10 Test Case-uri.

Timpul și efortul s-au redus considerabil.
-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.)