1. What do you understand by software testing?

Testarea software-ului este un proces de validare care confirmă că un sistem

funcționează conform cerințelor de afaceri. Califică un sistem pe diverse aspecte
precum uzabilitate, acuratețe, completitudine, eficiență etc. ANSI/IEEE 1059 este
standardul global care definește principiile de bază ale testării.

2. When should you stop the testing process

Activitatea de testare se încheie atunci când echipa de testare finalizează următoarele etape.

Execuția cazului de testare

Finalizarea cu succes a unui ciclu complet de testare după remedierea finală a erorilor marchează
sfârșitul fazei de testare.

Termenul limită de testare

Data de încheiere a etapei de validare declară, de asemenea, închiderea validării dacă în sistem
nu mai rămân defecte critice sau cu prioritate ridicată.

3. What do verification and validation mean in software

testing?

În testarea software-ului, verificarea este un proces pentru a confirma că dezvoltarea produsului

are loc conform specificațiilor și utilizând procedurile standard de dezvoltare. Procesul cuprinde
următoarele activități:
Inspecții
Recenzii
Walk-throughs
Demo-uri
Validarea este un mijloc de a confirma că produsul dezvoltat nu are erori și că funcționează
conform așteptărilor. Acesta cuprinde următoarele activități:
Testare funcțională
Testare nefuncțională

4. What is static testing? When does it start and what

does it cover?

Testarea statică este o tehnică de testare în cutie albă care direcționează dezvoltatorii să-și
verifice codul cu ajutorul unei liste de verificare pentru a găsi erori în acesta. Dezvoltatorii pot
începe testarea statică fără a finaliza efectiv aplicația sau programul. Testarea statică este mai
rentabilă decât testarea dinamică, deoarece are mai multe zone decât testarea dinamică într-un
timp mai scurt.

5. Define Black-box testing.

Este o abordare standard de testare a software-ului care necesită testeri să evalueze
funcționalitatea software-ului conform cerințelor de afaceri. Software-ul este tratat ca o cutie
neagră și validat conform punctului de vedere al utilizatorului final.

6. What is a test plan and what does it include?

A test plan stores all possible testing activities to ensure a quality product. It
gathers data from the product description, requirement, and use case documents.

The test plan document includes the following:

  Testing objectives
 Test scope
 Testing the frame
 Environment
 Reason for testing
 Criteria for entrance and exit
 Deliverables
 Risk factors

7. What is meant by test coverage?

Acoperirea testului este o măsură de calitate care reprezintă cantitatea (în procente)
de testare finalizată pentru un produs. Este relevant atât pentru activitățile de
testare funcționale, cât și pentru cele nefuncționale. Această valoare este utilizată
pentru a adăuga cazuri de testare lipsă.

8. Is it possible to achieve 100% testing coverage? How

would you ensure it?

It’s considered not possible to perform 100% testing of any product. But you can
follow the below steps to come closer.

 Set a hard limit on the following factors:

o Percentage of test cases passed

o Number of bugs found

 Set a red flag if:

o Test budget is depleted

o Deadlines are breached

 Set a green flag if:

o The entire functionality gets covered in test cases
 o All critical and major bugs must have a ‘CLOSED’ status

9. What are unit testing and integration testing?

Testarea unitară are multe denumiri, cum ar fi testarea modulelor sau testarea
componentelor.

De multe ori, dezvoltatorii sunt cei care testează unitățile sau modulele individuale
pentru a verifica dacă funcționează corect.

În timp ce testarea integrării validează cât de bine interacționează două sau mai
multe unități de software.

Există trei moduri de a valida integrarea:

Abordarea Big Bang

Abordare de sus în jos

Abordarea de jos în sus

10. Can we do system testing at any stage?

Nu. Testarea sistemului ar trebui să înceapă numai dacă toate modulele sunt la
locul lor și funcționează corect. Cu toate acestea, ar trebui efectuată înainte de
UAT (testarea de acceptare a utilizatorului).

11. Mention the different types of software testing.

Various types of Software Testing used by manual testers are as follows:

 Unit testing
 Integration testing
 Regression testing
 Shakeout testing
 Smoke testing
 Functional testing
 Performance testing

o Load testing
o Stress testing
o Endurance testing

  White-box and Black-box testing

  Alpha and Beta testing
 System testing

12. What is the difference between a test driver

and a test stub?
Driverul de testare este o secțiune de cod care apelează o componentă software
testată. Este util în testarea care urmează abordarea de jos în sus.
Stub-ul de testare este un program inactiv care se integrează cu o aplicație pentru
a-și completa funcționalitatea. Este relevant pentru testarea care utilizează
abordarea de sus în jos.

De exemplu:

Să presupunem un scenariu în care trebuie să testăm interfața dintre Modulele A și

B. Am dezvoltat doar Modulul A. Aici, putem testa Modulul A dacă avem
Modulul B real sau un modul inactiv pentru acesta. În acest caz, numim Modulul B
drept stub de testare.
Acum, Modulul B nu poate trimite sau primi date direct de la Modulul A. Într-un
astfel de scenariu, trebuie să mutăm datele de la un modul la altul folosind unele
caracteristici externe numite driver de testare.

13. What is agile testing and why is it important?

Testarea agilă este un proces de testare a software-ului care evaluează software-ul
din punctul de vedere al clienților. Este favorabil deoarece nu necesită ca echipa de
dezvoltare să finalizeze codificarea pentru pornirea QA. În schimb, atât codarea,
cât și testarea merg mână în mână. Cu toate acestea, poate necesita interacțiune
continuă cu clientul.

14. What do you know about data flow testing?

Este una dintre tehnicile de testare cutie albă.

Testarea fluxului de date este un tip de testare

structurală. Este o metodă care este folosită pentru a
găsi căile de testare ale unui program în funcție de
locațiile definițiilor și utilizărilor variabilelor din
program.

Testarea fluxului de date pune accent pe proiectarea cazurilor de testare care

acoperă căile fluxului de control în jurul definițiilor variabilelor și utilizările
acestora în module. Se așteaptă ca cazurile de testare să aibă următoarele atribute:

Intrarea în modul
Calea fluxului de control pentru testare
O pereche de definiție adecvată a variabilei și utilizarea acesteia
Rezultatul așteptat al cazului de testare

15. What is the purpose of the end-to-end testing?

Testarea end-to-end este o strategie de testare pentru a executa teste care acoperă
fiecare flux posibil al unei aplicații de la început până la sfârșit. Obiectivul
efectuării testelor end-to-end este de a descoperi dependențe de software și de a
afirma că intrarea corectă este transmisă între diferite module și subsisteme
software.

16. The probability that a server-class application

hosted on the cloud is up and running for six long
months without crashing is 99.99 percentage. To
analyze this type of a scenario, what test you will
perform?

Reliability testing
 17. What will you do when a bug turns up during
testing?
Când apare o eroare, putem urma pașii de mai jos.

Putem rula mai multe teste pentru a ne asigura că problema are o descriere clară.
De asemenea, putem rula câteva teste pentru a ne asigura că aceeași problemă nu
există cu intrări diferite.
Odată ce suntem siguri de amploarea completă a erorii, putem adăuga detalii și îl
putem raporta.

18. Why is it impossible to test a program

thoroughly?
Iată cele două motive principale care fac imposibilă testarea completă a unui
program.

Specificațiile software pot fi subiective și pot duce la interpretări diferite.

Un program software poate necesita prea multe intrări, ieșiri și combinații de căi.

19. How do you test a product if the requirements

are yet to be freezed?
Dacă specificațiile necesare nu sunt disponibile pentru un produs, atunci un plan de
testare poate fi creat pe baza ipotezelor făcute despre produs. Dar ar trebui să
obținem toate ipotezele bine documentate în planul de testare.

20. Is there any difference between retesting and

regression testing?
Diferențele posibile dintre retestarea și testarea de regresie sunt următoarele:

Efectuăm retestarea pentru a verifica remedierea defectelor. Dar, testarea de

regresie asigură că remedierea erorilor nu distruge alte părți ale aplicației.
Cazurile de testare de regresie verifică funcționalitatea unora sau a tuturor
modulelor.
Testarea de regresie asigură reexecuția cazurilor de testare trecute. Întrucât,
retestarea implică executarea cazurilor de testare care sunt într-o stare eșuată.
Retestarea are o prioritate mai mare față de regresie. Dar, în unele cazuri, ambele
sunt executate în paralel.

21. As per your understanding, list down the key

challenges of software testing.

Iată câteva dintre provocările cheie ale testării software:

Lipsa disponibilității documentelor standard pentru înțelegerea aplicației

Lipsa unor testeri calificați
Înțelegerea cerințelor: Testerii necesită capacități bune de ascultare și înțelegere
pentru a putea comunica cu clienții cerințele aplicației.
Capacitatea de luare a deciziilor de a analiza când să se oprească testarea
Abilitatea de a lucra în constrângeri de timp
Capacitatea de a decide ce teste să execute mai întâi
Testarea întregii aplicații folosind un număr optimizat de cazuri de testare
 22. What are the different types of functional
testing?

Testarea funcțională acoperă următoarele tipuri de tehnici de validare:

Testarea unitară
Testarea fumului
UAT
Teste de sanitate
Testarea interfeței
Testare de integrare
Testarea sistemului
Testare de regresie

23. What are functional test cases and non-

functional test cases?

Testare funcțională: este testarea „funcționalității” unui software sau a unei

aplicații testate. Acesta testează comportamentul software-ului testat. Pe baza
cerințelor clientului, un document numit specificație software sau specificație de
cerințe este folosit ca ghid pentru testarea aplicației.
Testare nefuncțională: în termeni de software, atunci când o aplicație funcționează
conform așteptărilor utilizatorului, fără probleme și în mod eficient în orice
condiție, atunci este declarată ca o aplicație de încredere. Pe baza calității, este
foarte important să se testeze acești parametri. Acest tip de testare se numește
testare nefuncțională.
 24. What do you understand by STLC?
Ciclul de viață al testării software (STLC) propune executarea testului într-o
manieră planificată și sistematică. În modelul STLC, au loc multe activități pentru
a îmbunătăți calitatea produsului.
Modelul STLC stabilește următorii pași:

Analiza cerințelor
Planificarea testelor
Dezvoltarea cazului de testare
Configurarea mediului
Executarea testului
Închiderea ciclului de testare

25. In software testing, what does a fault mean?

Defecțiunea este o condiție care face ca software-ul să nu se execute în timp ce

îndeplinește funcția considerată.

26. Difference between Bug, Defect, and Error.

O alunecare în codificare este indicată ca o eroare. Eroarea observată de un tester

manual devine un defect. Defectul pe care echipa de dezvoltare îl admite este
cunoscut sub numele de bug. Dacă un cod construit nu respectă cerințele, atunci
este o defecțiune funcțională.
 27. Is there any difference between quality
assurance, quality control, and software testing. If
so, what is it?

Asigurarea calității (QA) se referă la modul planificat și sistematic de monitorizare

a calității procesului care este urmat pentru a produce un produs de calitate. QA
urmărește rapoartele de testare și modifică procesul pentru a îndeplini așteptările.

Controlul calității (QC) este relevant pentru calitatea produsului. QC nu numai că

găsește defectele, dar sugerează și îmbunătățiri. Astfel, un proces care este stabilit
de QA este implementat de QC. QC este responsabilitatea echipei de testare.

Testarea software-ului este procesul prin care se asigură că produsul dezvoltat de

dezvoltatori îndeplinește cerințele utilizatorilor. Scopul efectuării testării este de a
găsi erori și de a vă asigura că acestea sunt remediate. Astfel, ajută la menținerea
calității produsului care urmează să fie livrat clientului.

28. What is a Silk Test and why should you use it?

Iată câteva fapte despre instrumentul Silk Test:

Instrumentul Skill este dezvoltat pentru a efectua regresia și testarea funcționalității

unei aplicații.
Este folosit atunci când testăm aplicații bazate pe ferestre, Java, web și aplicațiile
tradiționale client/server.
Silk Test ajută la pregătirea planului de testare și la gestionarea acestuia pentru a
oferi acces direct la baza de date și validarea câmpului.
 29. What is the difference between performance
testing and monkey testing?

Testarea performanței verifică viteza, scalabilitatea și/sau caracteristicile de

stabilitate ale unui sistem. Performanța este identificată cu atingerea timpului de
răspuns, a debitului și a nivelurilor de utilizare a resurselor care îndeplinesc
obiectivele de performanță pentru un proiect sau un produs.

Testarea maimuță este o tehnică în testarea software-ului în care utilizatorul

testează aplicația furnizând intrări aleatorii, verificând comportamentul aplicației
(sau încercând să blocheze aplicația).

30. What are the benefits of test reports?

Rapoartele de testare ne vor ajuta să găsim stadiul actual al unui proiect și calitatea
acestuia. Acest lucru poate ajuta părțile interesate și clienții să ia măsurile
necesare. Documentația completă a rapoartelor de testare va ajuta la analiza
diferitelor faze ale proiectului.

31. Explain bug life cycle.

Când un tester găsește o eroare, bug-ul este atribuit NOU sau DESCHIS cu stare.
Bug-ul este fie atribuit managerilor de proiect de dezvoltare, fie este dat
programului Bug Bounty. Ei vor verifica dacă este un defect valid. Dacă nu este
validă, eroarea este respinsă, iar noul său statut este RESPINS.
Acum, testerul verifică dacă un defect similar a fost ridicat mai devreme. Dacă da,
defectului i se atribuie statutul „DUPLICAT”
Odată ce eroarea este remediată, defectului i se atribuie starea „FIXED”
Apoi, testerul va retesta codul. În cazul în care cazul de testare trece, defectul este
ÎNCHIS
Dacă cazul de testare eșuează din nou, bug-ul este REDESCHIS și atribuit
dezvoltatorului.

32. Define Requirements Traceability Matrix.

Matricea de urmărire a cerințelor (RTM) este o matrice bidirecțională care

captează detaliile cerințelor și trasabilitatea acestora. Creat la pașii inițiali ai unui
proiect, RTM urmărește cerința analizând livrabilele și cerințele de afaceri.

33. Acceptance Testing.

Testarea de acceptare este un proces de asigurare a calității (QA) care determină în

ce măsură o aplicație îndeplinește aprobarea utilizatorilor finali. În funcție de
organizație, testarea de acceptare poate lua forma testării beta, testării aplicațiilor,
testării pe teren sau testării utilizatorilor finali.