Capitolul 1 Fundamentele testarii

a. Ce este software tester

Software testing este un proces de executare a unui program sau aplicație cu intenția de a
găsi erorile software.
Poate fi, de asemenea, denumit ca un proces de validare și verificare a faptului că un
program software, o aplicație sau un produs:

 Îndeplinește cerințele tehnice și de afaceri ce au dus la proiectarea și dezvoltarea

acestuia
 Funcționează așa cum era de așteptat

 Poate fi implementat cu aceeași caracteristică.

Să împărțim definiția de bază a testării software în următoarele părți:

1. Proces: Testarea este mai degraba un process decat o singura activitate.
2. Toate activitatile ciclului de viata: Testarea este un proces care are loc pe tot
parcursul ciclului de viață de dezvoltare software (SDLC) .
 Procesul de proiectare a testelor la inceputul ciclui de viata poate ajuta la prevenirea
introducerii defectelor in cod. Uneori este denumita verificarea bazei testului prin
“proiectarea testului.”
 Baza de testare include documente precum cerințele și specificațiile de proiectare.
3. Testare statică :poate testa și găsi defecte fără a executa cod. Testarea statică se face în
timpul procesului de verificare. Această testare include revizuirea documentelor (inclusiv
codul sursă) și analiza statică. Acesta este un mod util și rentabil de testare. De exemplu:
revizuire, parcurs , inspecție etc.
4. Testarea dinamica: în testarea dinamică, codul software este executat pentru a demonstra
rezultatul testelor efectuate. Se face în timpul procesului de validare. De exemplu: testarea
unitară , testarea integrării , testarea sistemului etc.

 5)  Planificare :   trebuie să planificăm ceea ce vrem să facem. Controlăm activitățile de

testare, raportăm progresul testării și starea software-ului testat.

6)  Pregătire:  trebuie să alegem ce testare vom face, selectând condițiile de testare

și proiectând cazuri de testare .

7)  Evaluare:  În timpul evaluării trebuie să verificăm rezultatele și să evaluăm software-ul

testat și criteriile de finalizare, ceea ce ne ajută să decidem dacă am terminat testarea și dacă
produsul software a trecut testele.
8)  Produse software și produse conexe de lucru: Împreună cu testarea codului, testarea
cerințelor și a specificațiilor de proiectare, precum și a documentelor aferente, cum ar fi
funcționarea, utilizatorul și materialul de instruire, sunt la fel de importante.

De ce este nevoie de testarea software-ului?

La un nivel înalt, testarea software-ului este necesară pentru a detecta erorile din software și
pentru a testa dacă software-ul îndeplinește cerințele clienților. Acest lucru ajută echipa de
dezvoltare să remedieze erorile și să livreze un produs de bună calitate.

Există mai multe puncte în procesul de dezvoltare de software în care eroarea

umană poate duce la un software care nu îndeplinește cerințele clienților. Unele
dintre ele sunt enumerate mai jos.

 Clientul / persoana care furnizează cerințele în numele organizației clientului

poate să nu știe exact ce este necesar sau poate să uite să furnizeze unele
detalii, ceea ce poate duce la lipsa caracteristicilor
 Persoana care colectează cerințele poate interpreta greșit sau pierde complet
o cerință atunci când le documentează
 În timpul fazei de proiectare, dacă există probleme în proiectare, aceasta
poate duce la erori în viitor
 Bug-urile pot fi introduse în faza de dezvoltare în timpul unei erori umane,
lipsei de expertiză etc.
 Testatorii pot rata erorile în timpul fazei de testare din cauza erorilor umane,
lipsei de timp, experienței insuficiente etc.
 Este posibil ca clienții să nu aibă lățimea de bandă pentru a testa fiecare
caracteristică a produsului și pot elibera produsul către utilizatorii finali, ceea
ce poate duce la găsirea de erori în aplicație de către utilizatorii finali.

Importanța testării software-ului în ingineria software-ului

Testarea software-ului este o parte importantă a dezvoltării software-ului. Dacă testarea

software-ului nu este efectuată corect, aplicațiile pot avea erori care pot duce la relucrare, eșec
costisitor sau, mai rău, pierderea vieții.

Există multe exemple în care erorile software au dus la pierderi de vieți omenești sau la
pierderi de milioane de dolari. Unele dintre ele sunt enumerate mai jos.

 Knights Capital Group a pierdut 440 de milioane de dolari în 30 de minute din cauza
unei erori în algoritmul lor de tranzacționare la 1 august 2012. Cota companiei a
scăzut cu 75% în două zile după ce software-ul a împins tranzacțiile defecte pentru
peste 150 de acțiuni diferite.
 Mt. Hack Gox Bitcoin - Mt. Gox, care era cel mai mare schimb bitcoin din lume la
acea vreme, a fost piratat în iunie 2011 și a pierdut aproximativ 850.000 de bitcoini,
evaluați la peste o jumătate de miliard de dolari.
 Vehiculul spațial Mariner 1 Spacecraft de 18 milioane de dolari a fost distrus odată ce
a fost sigur că se va prăbuși după decolare. Eșecul a fost urmărit înapoi la o cratimă
lipsă care a lăsat semnale greșite de ghidare să fie trimise rachetei.

b. De ce este necesara testarea software

Testarea software-ului este necesară deoarece toți facem greșeli. Unele dintre

aceste greșeli nu sunt importante, dar unele dintre ele sunt scumpe sau
 periculoase. Trebuie să verificăm tot ceea ce producem, deoarece lucrurile pot
merge întotdeauna prost - oamenii fac greșeli tot timpul.

1. Testarea software-ului este cu adevărat necesară pentru a evidenția defectele și erorile care

au fost făcute în timpul fazelor de dezvoltare .

2. Este esențial, deoarece se asigură că clientul găsește organizația de încredere și că

satisfacția lor în aplicație este menținută.

3. Este foarte important să se asigure Calitatea produsului. Produsul de calitate livrat clienților

ajută la câștigarea încrederii acestora. (Aflați mai multe despre calitatea software-ului )

4. Testarea este necesară pentru a oferi clienților facilități, cum ar fi livrarea de produse de
înaltă calitate sau aplicații software care necesită costuri de întreținere mai mici și, prin
urmare, rezultate în rezultate mai precise, consistente și fiabile.

o Produsul de înaltă calitate are de obicei mai puține defecte și necesită un efort
de întreținere mai mic, ceea ce înseamnă, la rândul său, costuri reduse.

5.Testarea este necesară pentru o performanță eficientă a aplicației software sau a produsului.

6.Este important să vă asigurați că aplicația nu ar trebui să conducă la eșecuri, deoarece poate

fi foarte costisitoare în viitor sau în etapele ulterioare ale dezvoltării.

o Testarea corectă asigură faptul că erorile și problemele sunt detectate la

începutul ciclului de viață al produsului sau al aplicației.
o Dacă defectele legate de cerințe sau de proiectare sunt detectate târziu în ciclul
de viață, poate fi foarte scump să le remediați, deoarece acest lucru ar putea
necesita reproiectarea, reimplementarea și reevaluarea aplicației.

7. Este necesar să rămâneți în afaceri.

o Utilizatorii nu sunt înclinați să utilizeze software care conține erori. Este

posibil să nu adopte un software dacă nu sunt mulțumiți de stabilitatea
aplicației.
o În cazul unei organizări sau demarări a produsului care are un singur produs,
calitatea slabă a software-ului poate duce la lipsa adoptării produsului și acest
lucru poate duce la pierderi din care afacerea nu poate recupera.

c. Care sunt obiectivele si scopul testarii?

Obiective: -Gasire defecte ce pot fi create de programator in timpul dezvoltarii

sofware-ului.

–Castigare incredere si furnizare info despre nivel de calitate

–de prevenire defecte – pt a se asigura ca rezultatul final indeplineste cerintele de

afaceri si ale utilizatorilor
 -pt a se asigura ca indeplineste brs(Specificatia cerintelor de afaceri) si srs (specificatii
cerinte de sistem)

-pt castigare incredere clienti oferindu-le produs de calitate

Testarea software ajută la finalizarea aplicației software sau a produsului în funcție de

cerințele comerciale și ale utilizatorilor. Este foarte important să aveți o acoperire bună a
testului pentru a testa complet aplicația software și a vă asigura că funcționează bine și
conform specificațiilor. Odată ce livrarea este efectuată către utilizatorii finali sau clienții,
aceștia ar trebui să poată opera fără reclamații. Pentru a face acest lucru, testerul ar trebui să
știe cum vor folosi clienții acest produs și, în consecință, ar trebui să noteze scenariile de
testare și să proiecteze cazurile de testare. Acest lucru va ajuta foarte mult la îndeplinirea
tuturor cerințelor clientului. Testarea software-ului asigură faptul că testarea se face corect și,
prin urmare, sistemul este gata de utilizare. O acoperire bună înseamnă că testarea a fost
făcută pentru a acoperi diferitele domenii, cum ar fi funcționalitatea
aplicației, compatibilitatea aplicației cu sistemul de operare, hardware și diferite tipuri de
browsere, testarea performanței pentru a testa performanța aplicației și testarea
încărcării pentru a vă asigura că că sistemul este fiabil și nu trebuie să se blocheze sau nu ar
trebui să existe probleme de blocare.Prin urmare, aplicația este ușor de instalat, învățat și
utilizat.

d. Ce este defectul in software testing?

Atunci când rezultatul real se abate de la rezultatul așteptat în timpul testării unei aplicații
software sau a unui produs, atunci rezultă un defect. 
Atunci când rezultatul aplicației software sau al produsului nu corespunde cu așteptările
utilizatorului final sau cu cerințele software-ului, atunci rezultă o eroare sau un defect.
În timp ce testați o aplicație software sau un produs dacă se constată un număr mare de
defecte, atunci se numește Buggy.

Atunci când un tester găsește o eroare sau un defect, este necesar să

transmită aceleași dezvoltatorilor. Astfel, ei raportează erori cu pașii de
detaliu și sunt numite Rapoarte de erori, raport de probleme, raport de
probleme etc.

Acest raport de defecte sau raport de erori constă din următoarele

informații:

 ID defect - Fiecare eroare sau defect are numărul său unic de

identificare
 Descrierea defectului - Aceasta include rezumatul problemei.
 Versiunea produsului - Aceasta include versiunea produsului
aplicației în care se găsește defectul.
  Pași de detaliu - Aceasta include pașii detaliați ai problemei cu
capturile de ecran atașate, astfel încât dezvoltatorii să o poată
recrea.
 Data ridicată - Aceasta include data la care este raportat eroarea
 Raportat de - Acesta include detaliile testerului care a raportat
eroarea, cum ar fi Nume și ID
 Stare - Acest câmp include starea defectului, cum ar fi Nou,
atribuit, deschis, retestare , verificare , închis, eșuat, amânat etc.
 Remediat de  - Acest câmp include detaliile dezvoltatorului care l-
a remediat, precum Nume și ID
 Data închiderii - Aceasta include Data la care bug-ul este închis
 Severitate - Pe baza severității (critică, majoră sau minoră) ne
spune despre impactul defectului sau al erorii în aplicația software
 Prioritate - Pe baza setului de priorități (înalt / mediu / scăzut) se
poate face ordinea de remediere a defectului. (Aflați mai multe
despre severitate și prioritate )

e. Ce este un esec la testarea software-ului?

Dacă în anumite condiții de mediu și situație se execută defecte ale aplicației sau produsului,
sistemul va produce rezultate greșite provocând o defecțiune.

Nu toate defectele duc la eșecuri, unele pot rămâne inactive în cod și este posibil să nu le

observăm niciodată. Nu doar defectele dau naștere la eșec. Eșecurile pot fi, de asemenea,
cauzate din alte motive, cum ar fi: -Din cauza condițiilor de mediu, precum o explozie de
radiații, un câmp magnetic puternic, câmp electronic sau poluare ar putea provoca defecțiuni
la hardware sau firmware. Aceste defecte pot împiedica sau modifica execuția software-ului.

-Eșecurile pot apărea și din cauza unei erori umane în interacțiunea cu software-ul, poate că
este introdusă o valoare greșită de intrare sau o ieșire este interpretată greșit.

-În cele din urmă, eșecurile pot fi cauzate și de cineva care încearcă în mod deliberat să
provoace o defecțiune în sistem.

Diferenta dintre eroare,defect si esec in testare software:

1. Eroare: greșelile făcute de programator sunt cunoscute ca „Eroare”. Acest lucru se poate

întâmpla din următoarele motive:

 Din cauza unei anumite confuzii în înțelegerea funcționalității software-ului

 Din cauza unor erori de calcul al valorilor
 Din cauza interpretării greșite a oricărei valori

2.Defect: erorile introduse de programator în interiorul codului sunt cunoscute ca

defecte. Acest lucru se poate întâmpla din cauza unor greșeli programatice.
3. Eșec: Dacă în anumite circumstanțe aceste defecte sunt executate de tester în timpul
testării, atunci rezultă o eroare, cunoscută sub numele de eșec al software-ului.

Eroare sunt la dezvoltarea software-ului, defect la nivel de testare și eșec la nivel de produs

Eroare - Când programatorul face orice greșeli în cod (la nivel de

dezvoltare).
Defect - Greșeala găsită de echipa dvs. de testare este un defect. (Nivel
de testare)
Eroare - Defectul acceptat de echipa de dezvoltare software se numește
eroare (Nivel de testare)
Eșec - Incapacitatea de a-și îndeplini funcțiile necesare (Nivel produs

Câteva puncte importante de știut:

Când testerul execută un test, el / ea poate observa o diferență în comportamentul

caracteristicii sau funcționalității, dar nu din cauza eșecului. Acest lucru se poate întâmpla din
cauza datelor de test greșite introduse, testerul poate să nu fie conștient de caracteristică sau
funcționalitate sau din cauza mediului defectuos. Din aceste motive, sunt raportate
incidente. Sunt cunoscute sub numele de raport de incidente. Condiția sau situația care
necesită analize suplimentare sau clarificări este cunoscută sub numele de incident. Pentru a
face față incidentelor, programatorul trebuie să analizeze dacă acest incident a avut loc din
cauza eșecului sau nu.

Nu este necesar ca defectele sau erorile introduse în produs să fie numai de către
software. Pentru a înțelege mai departe să luăm un exemplu. Un bug sau un defect poate fi, de
asemenea, introdus de un analist de afaceri. Defecțiunile prezente în specificații, cum ar fi
specificațiile cerințelor și specificațiile de proiectare, pot fi detectate în
timpul verificărilor . Atunci când defectul sau eroarea este surprinsă în timpul revizuirii nu
poate duce la eșec, deoarece software-ul nu a fost încă executat.

Aceste defecte sau erori sunt raportate nu pentru a învinui dezvoltatorii sau orice alte
persoane, ci pentru a judeca calitatea produsului. Calitatea produsului este extrem de
importantă. Pentru a câștiga încrederea clienților, este foarte important să livrați produsul de
calitate la timp.

f. De unde apar defectele si esecurile in testarea software?

Defectele si esecurile provin practic din:

-Erori in specificatie,design si implementarea software-ului si a sistemului

-Erori in utilizarea sistemului

-Conditii de mediu

-Daune intentionate
-Consecinte potentiale ale erorilor anterioare

Erori in specificatia si proiectarea software-ului:

Specificația este practic un document scris care descrie aspectele funcționale și nefuncționale
ale software-ului prin utilizarea prozei și a imaginilor. Pentru specificațiile de testare nu este
necesar să aveți cod. Fără a avea cod, putem testa specificațiile. Aproximativ 55% din toate
erorile prezente în produs se datorează greșelilor prezente în caietul de sarcini. Prin urmare,
testarea specificațiilor poate economisi mult timp și costuri în viitor sau în etapele ulterioare
ale produsului.

Erori la utilizarea sistemului:

Pot apărea erori în utilizarea sistemului, a produsului sau a aplicației din următoarele motive:

- Cunoașterea inadecvată a produsului sau a software-ului către tester. Este posibil ca testerul

să nu fie conștient de funcționalitățile produsului și, prin urmare, în timpul testării produsului,
ar putea exista unele defecte sau defecțiuni.

- Lipsa înțelegerii funcționalităților de către dezvoltator. De asemenea, se poate întâmpla ca

dezvoltatorii să nu fi înțeles corect funcționalitățile produsului sau aplicației. Pe baza
înțelegerii lor, este posibil ca caracteristica pe care o vor dezvolta să nu se potrivească cu
specificațiile. Prin urmare, acest lucru poate duce la defect sau eșec.

Conditii de mediu:

Din cauza configurării greșite a mediului de testare, testerii pot raporta defectele sau
defecțiunile. Conform sondajelor recente, sa observat că aproximativ 40% din timpul
testerului este consumat din cauza problemelor de mediu și acest lucru are un impact mare
asupra calității și productivității. Prin urmare, sunt necesare medii de testare adecvate pentru
calitate și livrarea la timp a produsului către clienți.

Daune intentionate: Defectele și defecțiunile raportate de testeri în timpul testării produsului

sau aplicației pot apărea din cauza deteriorării intenționate.

Consecințele potențiale ale erorilor anterioare: Erorile constatate în etapele anterioare ale
dezvoltării ne reduc costurile de producție. Prin urmare, este foarte important să găsiți eroarea
în etapa anterioară. Acest lucru se poate face prin revizuirea documentelor de caiet de sarcini
sau printr-o prezentare generală. 

g.Cand apar defectele in testarea sofware-ului?

Din urmatoarele motive apar defectele software:

1. Este posibil ca persoana care utilizeaza aplicatia software sau produsul sa nu aiba
cunostinte suficiente despre produs.

2. Poate că software-ul este utilizat în mod greșit, ceea ce duce la defecte sau eșecuri .

3. Este posibil ca dezvoltatorii să fi codat incorect și pot exista defecte prezente în proiectare.
4. Configurare incorectă a mediilor de testare.

h. Care este costul defectelor la testarea software-ului?

Costul poate fi masurat prin impactul defectelor si atunci cand le gasim. dacă eroarea se
găsește în specificațiile cerințelor în timpul colectării și analizei cerințelor, atunci este
oarecum ieftin să o remediați. Corectarea specificației cerințelor poate fi făcută și apoi poate fi
reemisă. În același mod, când defectul sau eroarea se regăsește în proiectare în timpul
revizuirii proiectului, atunci proiectul poate fi corectat și poate fi re-emis. Dar dacă eroarea nu
este cuprinsă în specificații și nu este găsită până la acceptarea utilizatorului, atunci costul
pentru remedierea acestor erori sau defecte va fi mult prea scump.

Dacă eroarea este comisă și defectul care rezultă este detectat în faza de cerințe, atunci este
relativ ieftin să o remediați. În mod similar, dacă se face o eroare de specificare a cerințelor
și se constată defectul în consecință în faza de proiectare, atunci proiectarea poate fi
corectată și reeditată cu cheltuieli relativ mici. Același lucru este valabil și pentru faza de
construcție . Dacă totuși, un defect este introdus în specificația cerințelor și nu este detectat
până la testarea acceptării sau chiar odată ce sistemul a fost implementat, va fi mult mai
scump de remediat.

i. Ce este un ciclu de viata al defectului sau un ciclu de viata al erorilor in testarea

software-ului?

Ciclul de viata al defectelor este un ciclu prin care trece un defect in timpul vietii sale. Începe
atunci când este găsit defectul și se termină atunci când un defect este închis, după ce se
asigură că nu este reprodus. Ciclul de viață al defectelor este legat de eroarea găsită în
timpul testării.

Ciclul de viață al erorilor sau defectelor include următorii pași sau stare:

1. Nou:  Când un defect este înregistrat și înregistrat pentru prima dată. Starea sa este

dată ca nouă.
2. Atribuit:  după ce testerul a postat eroarea, conducătorul testerului aprobă faptul că
eroarea este autentică și atribuie eroarea dezvoltatorului corespunzător și echipei de
dezvoltatori. 
3. Deschis: în  această situatie dezvoltatorul a început să analizeze și să lucreze la
remedierea defectelor.
4. Remediat:  atunci când dezvoltatorul efectuează modificările necesare ale codului și
verifică modificările, el / ea poate face starea de eroare ca „Remediat”, iar eroarea este
transmisă echipei de testare.
5. Retestare în așteptare:  după remedierea defectului, dezvoltatorul a dat acel cod
special pentru testare din nou către tester. Aici testarea este în așteptare la sfârșitul
testerelor. Prin urmare, statutul său este în așteptarea retestării.
6. Retestare : în  această etapă, testerul face testarea din nou a codului modificat pe care
i l-a dat dezvoltatorul pentru a verifica dacă defectul s-a remediat sau nu.
7. Verificat :  testerul testează din nou eroarea după ce a fost remediată de
dezvoltator. Dacă eroarea nu este prezentă în software, el aprobă faptul că eroarea este
remediată și schimbă starea în „verificat”.
 8. Deschideți din nou:  Dacă bug-ul există încă chiar și după ce bug-ul a fost remediat
de către dezvoltator, testerul schimbă starea în „redeschis”. Bug-ul parcurge din nou
ciclul de viață.
9. Închis:  odată ce bug-ul a fost remediat, acesta este testat de tester. Dacă testerul
consideră că eroarea nu mai există în software, el schimbă starea erorii în
„închis”. Această stare înseamnă că eroarea este remediată, testată și aprobată.
10. Duplicat: Dacă eroarea se repetă de două ori sau cele două erori menționează același
concept al erorii, atunci starea unei erori este schimbată în „duplicat ”.
11. Respins: dacă dezvoltatorul consideră că eroarea nu este autentică, respinge
eroarea. Apoi starea bug-ului este schimbată în „respins”.
12. Amânat: bug-ul, schimbat în stare amânată, înseamnă că bug-ul este de așteptat să fie
remediat în următoarele versiuni. Motivele pentru schimbarea bug-ului în această stare
au mulți factori. Unele dintre ele sunt prioritare pentru bug-ul poate fi scăzut, lipsa de
timp pentru lansare sau bug-ul poate să nu aibă un efect major asupra software-ului.
13. Nu este o eroare:   starea dată ca „Nu este o eroare” dacă nu există nicio modificare
în funcționalitatea aplicației. Pentru un exemplu: dacă clientul solicită o schimbare în
aspectul aplicației, cum ar fi schimbarea culorii unui text, atunci nu este o eroare, ci
doar o schimbare în aspectul aplicației.

j. Care este diferenta dintre severitate si prioritate

Exista 2 lucruri cheie in defectele testarii software-ului:

1.Severitate-Este măsura în care defectul poate afecta software-ul. Cu alte cuvinte, definește

impactul pe care un anumit defect îl are asupra sistemului. De exemplu: Dacă o aplicație sau
o pagină web se blochează atunci când se face clic pe un link la distanță, în acest caz, clicul pe
linkul de la distanță de către un utilizator este rar, dar impactul blocării aplicației este
sever. Deci severitatea este mare, dar prioritatea este scăzută.

Severitatea poate fi de următoarele tipuri:

 Critic: Defectul care are ca rezultat terminarea sistemului complet sau a uneia sau mai
multor componente ale sistemului și cauzează corupția extinsă a datelor. Funcția
eșuată este inutilizabilă și nu există o metodă alternativă acceptabilă pentru a obține
rezultatele necesare, atunci severitatea va fi declarată critică.
 Major: Defectul care duce la terminarea întregului sistem sau a uneia sau mai multor
componente ale sistemului și cauzează corupția extinsă a datelor. Funcția eșuată este
inutilizabilă, dar există o metodă alternativă acceptabilă pentru a obține rezultatele
necesare, atunci severitatea va fi declarată ca fiind majoră.
 Moderat: Defectul care nu are ca rezultat rezilierea, dar face ca sistemul să producă
rezultate incorecte, incomplete sau inconsistente, atunci severitatea va fi declarată ca
fiind moderată.
 Minor: Defectul care nu are ca rezultat rezilierea și nu
dăunează utilizabilității sistemului și rezultatele dorite pot fi ușor obținute prin
rezolvarea defectelor, atunci severitatea este declarată ca fiind minoră.
 Cosmetic: Defectul legat de îmbunătățirea sistemului în care modificările sunt legate
de aspectul și câmpul aplicației, atunci severitatea este declarată ca fiind cosmetică
2.Prioritate-Prioritatea definește ordinea în care ar trebui să rezolvăm un defect. De
exemplu: dacă numele companiei este scris greșit în pagina de pornire a site-ului web, atunci
prioritatea este mare și severitatea este scăzută pentru a remedia problema.

Prioritatea poate fi de următoarele tipuri:

 Scăzut: Defectul este un iritant care ar trebui reparat, dar repararea poate fi amânată
până după remedierea defectelor mai grave.
 Mediu: Defectul trebuie rezolvat în cursul normal al activităților de dezvoltare. Poate
aștepta până când se creează o nouă versiune sau versiune.
 Înalt: Defectul trebuie rezolvat cât mai curând posibil, deoarece defectul afectează
grav aplicația sau produsul. Sistemul nu poate fi utilizat până când nu a fost efectuată
reparația.
o Scenarii:Prioritate ridicată și severitate ridicată : o eroare care apare la
funcționalitatea de bază a aplicației și care nu va permite utilizatorului să
utilizeze sistemul. (De exemplu, un site care păstrează detaliile elevului, dacă
salvează înregistrarea dacă nu permite salvarea înregistrării, atunci acesta este
un bug cu prioritate ridicată și severitate ridicată.)
 Prioritate ridicată și gravitate redusă: greșelile de ortografie care apar pe pagina de
copertă sau pe titlul sau titlul unei aplicații.
 Severitate ridicată și prioritate redusă: o eroare care apare la funcționalitatea
aplicației (pentru care nu există nicio soluție) și care nu va permite utilizatorului să
utilizeze sistemul, ci prin clic pe link, care este rar utilizat de către utilizatorul final.
 Prioritate scăzută și severitate scăzută: Orice problemă cosmetică sau ortografică
care se află într-un paragraf sau în raport.

k. Care sunt cele 7 principii ale testarii?

1. Testarea arata prezenta defectelor-Testarea poate arăta defectele prezente, dar nu poate

dovedi că nu există defecte. Chiar și după testarea temeinică a aplicației sau a produsului, nu
putem spune că produsul este 100% fără defecte. Testarea reduce întotdeauna numărul de
defecte nedescoperite rămase în software, dar chiar dacă nu se găsesc defecte, nu este o
dovadă a corectitudinii.

2. Testarea exhaustiva este imposibila: nu este posibilă testarea tuturor, inclusiv toate

combinațiile de intrări și condiții prealabile. Deci, în loc să facem teste exhaustive, putem
folosi riscurile și prioritățile pentru a concentra eforturile de testare. accesarea și gestionarea
riscului este una dintre cele mai importante activități și motivul testării în orice proiect.

3.Testarea timpurie: În cadrul dezvoltării software - ului, ciclul de viață al activităților de

testare ar trebui să înceapă cât mai curând posibil și ar trebui să se concentreze asupra
obiectivelor definite.

4. Gruparea defectelor un număr mic de module conține majoritatea defectelor descoperite

în timpul prelansarii testarii sau prezintă cele mai multe defecțiuni operaționale.

5. Pesticide paradox: dacă aceleași tipuri de teste sunt repetate din nou și din nou, în cele din
urmă același set de cazuri de testare nu va mai putea găsi noi erori. Pentru a depăși acest
„paradox al pesticidelor”, este cu adevărat foarte important să revizuiți periodic cazurile de
testare și trebuie scrise teste noi și diferite pentru a exercita diferite părți ale software-ului sau
sistemului pentru a găsi potențial mai multe defecte.

6 Testarea este dependenta de context: Diferite tipuri de site-uri sunt testate diferit.

7 Absence of errors fallacy: dacă sistemul construit este inutilizabil și nu îndeplinește

nevoile și așteptările utilizatorului, atunci găsirea și remedierea defectelor nu ajută.

l. Care este procesul fundamental de testare in software testing?

1. Planificare si control – Planificarea testelor are urmatoarele sarcini majore:

-Sa determine riscurile, scop si sa identifice obiectivele testarii.

-Sa determine abordarea de testare.

-Sa implementeze politica de testare si/sau strategia de testare. (Strategia de testare este o
schita ce descrie portiunea de testare a ciclului de dezvoltare software. Este creată pentru a
informa PM, testerii și dezvoltatorii despre unele probleme cheie ale procesului de testare.
Aceasta include obiectivele testării, metoda de testare, timpul total și resursele necesare
pentru proiect și mediile de testare.).

-Pt a determina resursele de testare necesare, cum ar fi persoanele, mediile de testare, PC-
urile.

-Pt a programa teste de analiza si proiectare a sarcinilor, implementarea,executarea si

evaluarea testelor.

-Pt a determina criteriile de iesire trebuie sa stabilim criterii precum Criterii de acoperire.
(Criteriile de acoperire reprezinta procentul de afirmatii din software care trebuie executate in
timpul testarii. Acest lucru ne va ajuta să urmărim dacă finalizăm corect activitățile de testare.
Acestea ne vor arata ce sarcini si verificari trebuie sa finalizam pentru un anumit nivel de
testare inainte de a putea spune ca testarea este terminata)

Controlul testului are următoarele sarcini majore:

i. De a măsura și analiza rezultatele recenziilor și testării.
ii. De a monitoriza progresul, acoperirea testelor și criteriile de ieșire.
iii. De a furniza informații despre testare.
iv. De a iniția acțiuni corective.
v. De a lua decizii.

2. Analiza si proiectare:

Analiza testelor și proiectarea testelor au următoarele sarcini majore:

i. Pentru a revizui baza testului. (Baza testului este informația de care avem nevoie pentru a
începe analiza de testare și pentru a crea propriile noastre cazuri de testare. Practic este o
documentație pe care se bazează cazurile de testare, cum ar fi cerințele, specificațiile de
proiectare, analiza riscurilor de produs, arhitectura și interfețele. Putem utiliza pentru a
înțelege ce ar trebui să facă sistemul odată construit.)
ii. Pentru a identifica condițiile de testare.
iii. Pentru proiectarea testelor.
iv. Pentru a evalua testabilitatea cerințelor și a sistemului.
v. Pentru a proiecta configurarea mediului de testare și pentru a identifica infrastructura și
instrumentele necesare.

3. Implementare si executie

In timpul implementării și execuției testului, luăm condițiile de testare în cazuri și proceduri

de testare și alte testware, cum ar fi scripturi pentru automatizare, mediul de testare și orice
altă infrastructură de testare. (Test cases este un set de condiții în care un tester va determina
dacă o aplicație funcționează corect sau nu.) (Testware este un termen pentru toate utilitățile
care servesc în combinație pentru testarea unui software cum ar fi scripturile, mediul de
testare și orice alt test infrastructură pentru reutilizare ulterioară.)

Implementarea testului are următoarea sarcină majoră:

Implementarea testului are următoarea sarcină majoră:

i.   De a dezvolta și prioritiza cazurile noastre de testare utilizând tehnici și a crea date de
testare pentru aceste teste. (Pentru a testa o aplicație software, trebuie să introduceți unele
date pentru testarea majorității caracteristicilor. Orice astfel de date identificate în mod
specific care sunt utilizate în teste sunt cunoscute sub numele de date de testare.)
De asemenea, scriem câteva instrucțiuni pentru efectuarea testelor, care este cunoscute sub
numele de proceduri de testare.
De asemenea, este posibil să trebuiască să automatizăm unele teste folosind cablajul de
testare (TEST HARNESS = CADRU DE TESTARE AUTOMATIZAT) și scripturile de
teste automate. (Un test harness este o colecție de software și date de testare pentru testarea
unei unități de program, rulând-o în diferite condiții și monitorizând comportamentul și
ieșirile acesteia.)
Ii.Pentru a crea suite de testare( TEST SUITES) din cazurile de testare pentru o execuție
eficientă a testelor.
(Suita de testare este o colecție de cazuri de testare care sunt folosite pentru a testa un
program software pentru a arăta că are un set specific de comportamente. O suită de testare
conține adesea instrucțiuni detaliate și informații pentru fiecare colecție de cazuri de testare pe
configurația sistemului care urmează să fie utilizată în timpul testării. Suitele de testare sunt
utilizate pentru a grupa cazuri de testare similare.)
iii. Pentru a implementa și verifica mediul.

Execuția testului are următoarea sarcină majoră:

i. De a executa suitele de testare și cazurile de testare individuala dupa procedurile de testare.
ii. De a executa din nou testele care au eșuat anterior pentru a confirma o remediere. Acest
lucru este cunoscut sub numele de testarea confirmarii sau re-testare.
iii. De a înregistra rezultatul execuției testului și a înregistra identitățile și versiunile software-
ului supus testelor. Jurnalul de testare(Test log) este utilizat pentru audit trial (Un jurnal de
testare nu este altceva decât, care sunt cazurile de testare pe care le-am executat, în ce ordine
am executat, cine a executat cazurile de testare și care este starea cazului de testare (trecere /
eșuare). Aceste descrieri sunt documentate și numite ca jurnal de testare.).
iv.Pentru a compara rezultatele reale cu rezultatele așteptate.
v. În cazul în care există diferențe între rezultatele reale și cele așteptate, raportează
discrepanțe ca Incidente.
4. Evaluarea criteriilor de iesire si raportare

Pe baza evaluării riscurilor proiectului, vom stabili criteriile pentru fiecare nivel de testare, cu
care vom măsura „testarea suficientă”. Aceste criterii variază de la proiect la proiect și sunt
cunoscute sub numele de criterii de ieșire .(exit criteria)
Criteriile de ieșire intră în imagine, atunci când:
- cazurile maxime de testare sunt executate cu un anumit procentaj de trecere.
- Rata de erori scade sub un anumit nivel.
- Când ați atins termenele limită.

Evaluarea criteriilor de ieșire are următoarele sarcini majore:

i. De a verifica jurnalele de testare în raport cu criteriile de ieșire specificate în planificarea
testului.
ii. De a evalua dacă sunt necesare mai multe teste sau dacă ar trebui modificate criteriile de
ieșire specificate.
iii. De a scrie un raport de sinteză al testului pentru părțile interesate.

5. Activitati de inchidere a testelor (Test closure activities) se fac cand software-ul este
livrat. Testarea poate fi inchisa si din alte motive:

 Cand s-au adunat toate informatiile necesare testarii.

 Cand un proiect este anulat.
 Cand se atinge o anumita tinta
 Cand se face mentenanta sau actualizare.

Activitatile de inchidere a testelor au urmatoarele sarcini majore:

i. Pentru a verifica livrabilele planificate care sunt livrate efectiv și pentru a vă asigura că
toate rapoartele incidentelor au fost rezolvate.
ii. Pentru a finaliza și arhiva programe de testare, cum ar fi scripturi, medii de testare etc.,
pentru reutilizare ulterioară.
iii. Pentru a preda instrumentele de testare către organ*izația de întreținere. Acestea vor oferi
suport software-ului.

iv să evalueze modul în care s-a desfășurat testarea și să învețe lecții pentru lansări și proiecte
viitoare.

m. Ce este psihologia testarii?

*Comparatia mentalitatii testerului si dezvoltatorului:

Testarea si revizuirea aplicatiilor sunt diferite de analiza si dezvoltarea lor. Prin aceasta vrem
să spunem că, dacă construim sau dezvoltăm aplicații, lucrăm pozitiv pentru a rezolva
problemele din timpul procesului de dezvoltare și pentru a realiza produsul în conformitate cu
specificațiile utilizatorului.

Cu toate acestea, în timpul testării sau revizuirii unui produs, căutăm defectele
sau defecțiunile produsului. Astfel, construirea software-ului necesită o mentalitate diferită
de testarea software-ului.
*Echilibrul dintre auto-testare si testarea independenta

Comparația făcută pe mentalitatea testerului și dezvoltatorului din articolul de mai sus este
doar pentru a compara cele două perspective diferite.

Nu înseamnă că testerul nu poate fi programatorul sau că programatorul nu poate fi testerul,

deși adesea sunt roluri separate. De fapt, programatorii sunt testerii.

Ei își testează întotdeauna componenta pe care au construit-o. În timp ce își testează propriul
cod, găsesc multe probleme, astfel încât programatorii, arhitectul și dezvoltatorii își testează
întotdeauna propriul cod înainte de a-l da oricui. Cu toate acestea știm cu toții că este dificil să
ne găsim propriile greșeli.

Deci, programatorii, arhitectul, analistul afacerilor depind de ceilalți pentru a-și testa
activitatea. Această altă persoană ar putea fi un alt dezvoltator din aceeași echipă sau
specialiștii în testări sau testeri profesioniști. Oferirea de aplicații specialiștilor în testare sau
testerilor profesioniști permite o testare independentă a sistemului.

Acest grad de independență evită prejudecata autorului și este adesea mai eficient în
găsirea defectelor și a eșecurilor .

Există mai multe niveluri de independență în testarea software, care este listat aici de la cel
mai scăzut nivel de independență la cel mai înalt:
i. Teste efectuate de persoana care a scris articolul.
ii. Teste de către o altă persoană din cadrul aceleiași echipe, ca un alt programator.
iii. Teste efectuate de persoana dintr-un grup diferit, cum ar fi o echipă de testare
independentă.
iv. Teste efectuate de o persoană dintr-o altă organizație sau companie, cum ar fi testarea
subcontractată sau certificarea de către un organism extern.

*Comunicare clară și politicoasă și feedback cu privire la defectele dintre tester și

dezvoltator: cu
toții comitem greșeli și uneori ne enervăm și ne supărăm sau ne deprimăm când cineva le
arată. Deci, când, în calitate de testeri, efectuăm un test care este un test bun din punctul
nostru de vedere, deoarece am găsit defectele și eșecurile în software.

Dar, în același timp, trebuie să fim foarte atenți la modul în care reacționăm sau raportăm
defectelor și eșecurilor programatorilor. Suntem mulțumiți pentru că am găsit o eroare bună,
dar cum vor reacționa analistul de cerințe, proiectantul, dezvoltatorul, managerul de proiect și
clientul.

 Persoanele care construiesc aplicația pot reacționa defensiv și pot lua acest defect
raportat drept critică personală.
 Managerul de proiect poate fi supărat pe toată lumea pentru că susține proiectul.
 Clientul poate pierde încrederea în produs, deoarece vede defecte.

Deoarece testarea poate fi văzută ca activitate distructivă, trebuie să avem grijă în timp ce
raportăm defectele și eșecurile noastre cât mai obiectiv și politicos posibil.

n. Ce este testarea independenta?

Când ne gândim cât de independentă este echipa de testare? Este cu adevărat foarte important
să înțelegem că independența nu este una sau / sau o condiție, ci o gamă:

 La un capăt al gamei se află absența independenței, unde programatorul efectuează

teste în cadrul echipei de programare.
 Trecând la independență, găsim un tester integrat sau un grup de testeri care lucrează
alături de programatori, dar încă în cadrul și raportează managerului de dezvoltare.
 Apoi, îndreptându-ne puțin mai mult spre independență, s-ar putea să găsim o echipă
de testeri independenți și în afara echipei de dezvoltare, dar care să raporteze la
managementul proiectului.
 Aproape de celălalt capăt al continuumului se află independența completă. S-ar putea
să vedem o echipă de testare separată care raportează în organizație într-un punct egal
cu echipa de dezvoltare sau de proiect. S-ar putea să găsim specialiști în domeniul
afacerii (cum ar fi utilizatorii sistemului), specialiști în tehnologie (cum ar fi experți în
baze de date) și specialiști în testare (cum ar fi testeri de securitate, testeri de
certificare sau experți în automatizarea testelor) într-o echipă de testare separată , ca
parte a unei echipe de testare independente mai mari sau ca parte a unui contract,
echipă de testare externalizată.

Avantajele testării independenței:

 Un tester independent poate afla în mod repetat mai multe defecte, altele și diferite
decât un tester care lucrează în cadrul unei echipe de programare - sau un tester care
este de profesie programator.
 În timp ce analiștii de afaceri, personalul de marketing, proiectanții și programatorii își
aduc propriile ipoteze la specificația și implementarea articolului supus testului, un
tester independent aduce un set diferit de ipoteze la testare și la recenzii, care adesea
ajută la expunerea defectelor ascunse și Probleme
 Un tester independent care raportează conducerii superioare își poate raporta
rezultatele cu onestitate și fără nicio preocupare pentru represalii care ar putea rezulta
din sublinierea problemelor în munca colegilor sau, mai rău, în continuare, a
managerului.
 O echipă independentă de testare are adesea un buget separat, care ajută la asigurarea
unui nivel adecvat de bani cheltuiți pentru instruirea testerului, instrumentele de
testare , echipamentele de testare etc.
 În plus, în unele organizații, testerii dintr-o echipă independentă de testare ar putea fi
mai ușor să aibă o carieră care să ducă la roluri mai în vârstă în testare.

Riscurile independenței și testarea integrată:

 Există posibilitatea ca testerii și echipa de testare să se izoleze. Acest lucru poate lua

forma izolării interpersonale față de programatori, proiectanți și echipa de proiect în
sine, sau poate lua forma izolării din perspectiva mai largă a calității și a obiectivelor
de afaceri (de exemplu, concentrarea obsesivă asupra defectelor, adesea însoțită de un
refuz de a accepta prioritizarea de afaceri a defectelor).
 Acest lucru duce la probleme de comunicare, sentimente de neprietenie și ostilitate.
 Lipsa identificării și sprijinului pentru obiectivele proiectului, festivalurilor de vina
spontană și sprijinirea politică.
  Chiar și echipele de testare bine integrate pot suferi probleme. Alte părți interesate ale
proiectului ar putea să vadă echipa de testare independentă - în mod corect sau în mod
greșit - ca un blocaj și o sursă de întârziere. Unii programatori renunță la
responsabilitatea lor pentru calitate, spunând: „Ei bine, acum avem această echipă de
testare, așa că de ce trebuie să testez codul meu în unitate?

o. Ce este Calitatea Software-ului?

Software-ul de calitate este, în mod rezonabil , gratuit de erori sau defecte , livrat
la timp și în limita bugetului, îndeplinește cerințele și / sau așteptările și este
menținut.

Standardul ISO 8402-1986 definește calitatea ca „totalitatea

caracteristicilor și caracteristicilor unui produs sau serviciu care poartă
capacitatea sa de a satisface nevoile declarate sau implicite”.

Aspectele cheie ale calității pentru client includ:

 Design bun - aspect și stil

 Funcționalitate bună - funcționează bine
 Fiabile - nivel acceptabil de defecțiuni sau eșecuri
 Coerență
 Durabil - durează cât ar trebui
 Bun serviciu post-vânzare
 Raport calitate-preț
 Design bun - aspect și stil:
 Este foarte important să aveți un design bun. Aplicația sau
produsul trebuie să îndeplinească toate specificațiile cerințelor și,
în același timp, ar trebui să fie ușor de utilizat. Clienții sunt, în
principiu, atrași de aspectul și stilul bun al aplicației. Combinațiile
de culori potrivite, dimensiunea fontului și stilul textelor și
butoanelor sunt foarte importante.
 Funcționalitate bună - funcționează bine:
 Împreună cu aspectul bun al aplicației sau al produsului, este
foarte important ca funcționalitatea să fie intactă. Toate
caracteristicile și funcționalitatea acestora ar trebui să funcționeze
conform așteptărilor. Nu ar trebui să existe nicio abatere în
rezultatul real și în rezultatul scontat.
 Fiabile - nivel acceptabil de defecțiuni sau eșecuri:
  După ce am testat toate caracteristicile și funcționalitățile
acestora, este foarte important ca aplicația sau produsul să fie
fiabile. De exemplu: există o aplicație de salvare a înregistrărilor
studenților. Această aplicație ar trebui să salveze toate
înregistrările studenților și nu ar trebui să eșueze după
introducerea a 100 de înregistrări. Aceasta se numește fiabilitate.
 Coerență:
 Software-ul ar trebui să aibă consistență între aplicație sau
produs. Un singur software poate fi multidimensional. Este foarte
important ca toate dimensiunile diferite să se comporte într-un
mod consecvent.
 Durabil - durează cât ar trebui:
 Software-ul ar trebui să fie durabil. De exemplu, dacă software-ul
este utilizat timp de un an și numărul de date depășește 5000 de
înregistrări, atunci nu ar trebui să eșueze dacă numărul de
înregistrări crește. Produsul software sau aplicația ar trebui să
continue să se comporte în același mod, fără pauze funcționale.
 Bun serviciu post-vânzare:
 Odată ce produsul este livrat clienților, întreținerea intră în
imagine. Este foarte important să oferiți servicii de vânzare bune
pentru a menține clienții fericiți și mulțumiți. De exemplu, dacă
după ce utilizează produsul timp de șase luni, clientul își dă seama
să aducă unele modificări aplicației, aceste modificări trebuie
făcute cât mai repede posibil și ar trebui să fie livrate clienților la
timp cu calitate.
 Raport calitate-preț:
 Este întotdeauna important să livrați produsul clienților care au
valoare pentru bani. Produsul trebuie să îndeplinească
specificațiile cerințelor. Ar trebui să funcționeze conform
așteptărilor, să fie ușor de utilizat. Ar trebui să oferim servicii bune
clienților. În afară de caracteristicile menționate în specificațiile
cerințelor, ar putea fi oferite clienților o funcționalitate
suplimentară la care s-ar putea să nu se fi gândit. Aceste
funcționalități suplimentare ar trebui să facă produsul mai ușor de
utilizat și mai ușor de utilizat. Acest lucru adaugă, de asemenea,
valoare pentru bani.

CAPITOLUL 2
a. Ce este verificarea in testarea software-ului? Ce este verificarea software-ului?

Verificarea asigura ca produsul este conceput pt a oferi clientului toate functionalitatile.

-Verificarea se face la inceputul procesului de dezvoltare. Include recenzii și

întâlniri, parcurgeri , inspecții etc. pentru a evalua documente, planuri, cod, cerințe și
specificații.

-Să presupunem că construiești o masă. Aici verificarea se referă la verificarea tuturor părților

tabelului, indiferent dacă toate cele patru picioare sunt sau nu de dimensiuni corecte. Dacă un
picior de masă nu are dimensiunea potrivită, acesta va dezechilibra produsul final. Un
comportament similar este observat și în cazul produsului software sau al aplicației. În cazul
în care orice caracteristică a produsului software sau a aplicației nu este la înălțimea mărcii
sau dacă se constată un defect, atunci va avea ca rezultat eșecul produsului final. Prin
urmare, verificarea este foarte importantă. Are loc la începutul procesului de dezvoltare.

Verificarea software-ului si validarea: *Intrebarea este daca construiesc produsul corect

* Daca am acesat datele corect (la locul potrivit, in modul corect)

* Este o activitate de nivel scazut

* Efectuata pe parcursul dezvoltarii unor pasi cheie cum ar fi parcurgeri (walkthroughs),

recenzii si inspectii, feedback-ul mentorilor, training, liste de verificare.

* Demonstrarea consistenței, completitudinii și corectitudinii software-ului în fiecare etapă și

între fiecare etapă a ciclului de viață al dezvoltării.

Conform Modelului de Maturitate a Capabilității (CMM) putem defini și verificarea ca

fiind procesul de evaluare a software-ului pentru a determina dacă produsele unei faze de
dezvoltare date îndeplinesc condițiile impuse la începutul acelei faze.

Avantajele verificării software-ului:

1. Verificarea ajută la scăderea numărului defectului în etapele urmatoare ale dezvoltării.

2. Verificarea produsului în faza inițială a dezvoltării va ajuta la înțelegerea produsului
într-un mod mai bun.
3. Reduce șansele de eșecuri ale aplicației software sau ale produsului.
4. Ajută la construirea produsului conform specificațiilor și nevoilor clientului.

b. Ce este validarea in testarea software?

Validarea determină dacă sistemul respectă cerințele și îndeplinește funcțiile pentru care

este destinat și îndeplinește obiectivele organizației și nevoile utilizatorilor.

 Validarea se face la sfârșitul procesului de dezvoltare și are loc

după finalizarea verificărilor .
 Răspunde la întrebarea de genul: Construiesc produsul potrivit?
 Accesez datele corecte (în ceea ce privește datele necesare pentru a satisface cerința).
 Este o activitate de nivel înalt.
  Efectuat după ce un produs de lucru este produs conform criteriilor stabilite,
asigurându-se că produsul se integrează corect în mediu.
 Determinarea corectitudinii produsului software final de către un proiect de dezvoltare
în raport cu nevoile și cerințele utilizatorului.

Conform Modelului de Maturitate a Capabilității (CMM) , putem defini și validarea ca

Procesul de evaluare a software-ului în timpul sau la sfârșitul procesului de dezvoltare pentru
a determina dacă acesta îndeplinește cerințele specificate.

Un produs poate trece în timpul verificării, deoarece se face pe hârtie și nu este necesară nicio
aplicație funcțională sau funcțională. Dar, atunci când aceleași puncte care au fost verificate
pe hârtie sunt de fapt dezvoltate, atunci aplicația sau produsul care rulează poate eșua în
timpul validării. Acest lucru se poate întâmpla deoarece atunci când un produs sau o aplicație
este construit conform specificațiilor, dar aceste specificații nu sunt la înălțime, prin urmare
nu reușesc să răspundă cerințelor utilizatorului.

Avantajele validării:

1. Pe parcursul verificării, dacă unele defecte sunt ratate, atunci în timpul procesului de

validare, acesta poate fi surprins ca defecțiuni.
2. Dacă în timpul verificării unele specificații sunt înțelese greșit (misunderstod) și
dezvoltarea s-a întâmplat, atunci în timpul procesului de validare în timp ce executați
acea funcționalitate, diferența dintre rezultatul real și rezultatul așteptat poate fi
înțeleasă.
3. Validarea se face în timpul testării, cum ar fi testarea caracteristicilor, testarea
integrării, testarea sistemului, testarea sarcinii, testarea compatibilității, testarea
stresului etc.
4. Validarea ajută la construirea produsului potrivit conform cerințelor clientului și
contribuie la satisfacerea nevoilor acestora.

Validarea se face practic de testeri în timpul testării. În timp ce validați produsul dacă se
constată o anumită abatere în rezultatul real de la rezultatul așteptat, atunci se raportează o
eroare sau se ridică un incident . Nu toate incidentele sunt erori. Dar toate erorile sunt
incidente. Incidentele pot fi, de asemenea, de tip „Întrebare” în cazul în care funcționalitatea
nu este clară pentru tester.

Prin urmare, validarea ajută la desfășurarea funcționalității exacte a caracteristicilor și ajută

testerii să înțeleagă produsul într-un mod mult mai bun. Ajută la îmbunătățirea ușurinței
produsului dee folosire. (more friendly)

c. Ce este modelul de maturitate a capacitatii (CMM)? Ce sunt nivelurile CMM?

Este un punct de referinta pt masurarea maturitatii procesului software al unei organizatii.

Este o metodologie utilizata pt dezvoltarea si perfectionarea procesului de dezvoltare sofware
al unei organizatii. Este o metodologie utilizată pentru dezvoltarea și
perfecționarea procesului de dezvoltare software a unei organizații . CMM poate fi utilizat
pentru a evalua o organizație în raport cu o scară de cinci niveluri de maturitate a proceselor
pe baza anumitor domenii cheie de proces (KPA). Descrie maturitatea companiei pe baza
proiectului cu care compania are de-a face și a clienților. Fiecare nivel clasifică organizația în
funcție de standardizarea proceselor din subiectul evaluat.