În termeni obișnuiți,un Ciclu de viață (Life Cycle) reprezintă succesiunea de modificări

de la o formă la alta.În cadrul testării,acest lucru este exemplificat printr-un proces de

executare al activităților de testare,într-un mod sistematic și planificat.Prin urmare, Ciclul de
viață al Testării Software (Software Testing)se referă la un proces de testare cu pași
specifici,pentru asigurarea faptului că Software-ul îndeplinește criteriile de calitate.

1.Analiza cerințelor Reprezintă prima etapă în cadrul STLC-ui, în care echipa de asigurare a
calității studiază cerințele,cu scopul înțelegerii a ceea ce ar urma să fie testat.Dacă sunt
nelămuriri,echipa de asigurare a calității se va întâlni cu părțile interesate (Analist de
afaceri,Client,Director Tehnic ), având ca scop lămurirea cerințelor.Cerințele pot fi
funcționale (ce trebuie să facă Software-ul) sau nefuncționale (performanța și securitatea
sistemului).Criteriile de intrare sunt: furnizarea SRS-ui ( Specificația cerințelor
Software ),Criteriul de Acceptare (Acceptance Testing);Criteriile de ieșire sunt: completarea
Raportului de fezabilitate al automatizării. (Automation feasibility report).

Activitățile care urmează să fie realizate în etapa de analiză a cerințelor sunt:-

Identificarea tehnicilor și a tipurilor de testare;-Definirea scopului testării,împreună cu
prioritățile;-Dacă este necesar, verificarea fezabilității automatizării și pregătirea
Raportulului de fezabilitate al automatizării;-Identificarea detaliilor privind mediul de testare
(unde vor fi efectuate testările). Rezultatele etapei de analiză a cerințelor sunt: Raportul de
fezabilitate al automatizării (dacă este cazul).

2.Etapa de planificare Se efectuează un plan de testare,ce prezintă strategia care va fi

utilizată pentru testarea unei aplicații, resursele care vor fi utilizate, mediul de testare în care
se va efectua testarea, precum și programul activităților de testare. De obicei, conducerea
echipei de asigurare a calității va fi responsabilă pentru redactarea unui plan de testare.În
aceasta etapă,va fi elaborată,de asemenea și strategia de testare.Criteriile de intrare sunt:
furnizarea de documente de cerință (versiunea actualizată a cerințelor neclare / lipsă /
clarificate) ; Criteriile de ieșire sunt: finalizarea Strategiei de testare / Planului de testare și
Documentul de estimare a efortului de testare.Activitățile care urmează să fie făcute în
etape de planificare a testelor sunt:-Pregătirea planului de testare / documentului de
strategie pentru diferite tipuri de testare;-Selectarea instrumentelor de testare;-Estimarea
eforturilor de testare;-Planificarea resurselor și determinarea rolurilor și a
responsabilităților.Rezultatele etapei de planificare sunt: Planul de testare(Test Plan) /
Documentul de strategie(Test Strategy), Document de estimare a efortului (Testing effort
estimation document).

3.Scrierea cazurilor de testare Etapa de scriere a cazurilor de testare începe odată ce faza de
planificare este finalizată. Este etapa în care echipa de testare scrie cazurile de testare în
detaliu. Alături de cazuri de test, echipa de testare pregătește, de asemenea, datele testului
si scenarii, (Test Data) (Scripts), dacă este necesar pentru testare. Odată ce cazurile de
testare sunt gata, acestea sunt analizate de către echipa de asigurare a calității.De
asemenea, este pregătită Matricea de Urmărire a Cerințelor (RTM). Scopul principal al
Matricii de urmărire a cerințelor este de a valida dacă toate cerințele sunt verificate prin
cazuri de testare, astfel încât nici o funcționalitate nu este ignorată în timpul testării .
 Criteriile de intrare ale fazei curente sunt ca, activitățile din etapa de planificare să fie
terminate,iar planul de testare să fie gata.Criteriile de ieșire au în vedere finalizarea
cazurilor de testare ,alături de datele testului,iar scenariile de testare să fie pregătite, dacă
automatizarea este în sfera de aplicare. Activitățile care trebuie realizate în etapa de scriere
a cazurilor de test sunt:- Crearea cazurilor de testare, scenarii de automatizare (dacă este
cazul);- Examinarea și analiza cazurilor de testare,implicit a scenariilor;-Crearea datelor de
test.Rezultatele care trebuie realizate în etapa de scriere a cazurilor de test sunt:- Cazuri de
testare (Test Cases)/Scenarii (Scripts);-Date de test(Test Data).

4.Configurarea mediul de testare Un mediu de testare este o configurare de software și

hardware pentru echipele de testare,astfel încât să execute cazuri de testare. Cu alte
cuvinte, reprezintă baza necesară executării testelor, cu hardware, software și rețea
configurate. Mediul de testare este configurat în funcție de nevoia aplicației aflate în
procesul de testare.Odată ce mediul este configurat și echipa de asigurare a calității are
acces la acesta, ar trebui efectuată o rundă rapidă de testare a funcționalităților de bază
(smoke testing) pentru validarea stabilității construirii mediului de testare. Scopul principal al
testării funcționalităților de bază (smoke testing) este de a detecta din timp, probleme
majore. Criteriile de intrare pentru această fază sunt furnizarea Planului de testare,
pregătirea cazurilor de testare a funcționalităților de bază(smoke testing) și pregătirea
datelor de testare.Criteriile de ieșire pentru această fază sunt ca mediul de testare să fie
gata și testarea funcționalităților de bază(smoke testing) să fie efectuată cu succes, având
rezultatele așteptate.Activitățile care trebuie realizate în această etapă sunt:-Configurarea
mediului de testare;-În conformitate cu documentele Cerințe și Arhitectură, lista de software
și hardware necesare este pregătită;-După configurarea mediului de testare, se realizează
executarea cazurilor de testare a funcționalităților de bază pentru a verifica stabilitatea
sistemului.Rezultatele care trebuie realizate în această etapă sunt:- Configurarea Mediului
de Testare (Test Environment);- Rezultatul cazurilor de testare a funcționalităților de bază
(smoke testing).

5. Rularea Testelor După etapele dezvoltării cazurilor de testare și configurarea mediului de

testare, începe etapa de rulare a testului. Odată ce testul a trecut, atunci poate fi marcat ca
Trecut (Passed). În cazul în care orice caz de testare a eșuat (Failed), atunci defectul
corespunzător poate fi raportat echipei de dezvoltatori prin intermediul sistemului de
urmărire a defectelor, iar defectul poate fi legat pentru cazul de test corespunzător, în
vederea unei analize ulterioare. În mod ideal, fiecare caz de test eșuat ar trebui să fie asociat
cu cel puțin un defect. Odată ce problema a fost remediată de către echipa de dezvoltare,
atunci același caz de test poate fi retestat de către echipa de testare. Un alt avantaj al
raportării unui defect este că ușurează urmărirea stării defectelor. Există multe instrumente
populare precum ALM, JIRA, Bugzilla, care permit raportarea și urmărirea defectelor.Dacă
vreunul dintre cazurile de testare este blocat din cauza vreunui defect, astfel de cazuri de
testare pot fi marcate ca Blocate, (Blocked), astfel încât să putem obține raportul în funcție
de câte cazuri de testare au trecut, au eșuat, au fost blocate sau nu au fost executate . Odată
ce defectele sunt rezolvate, aceleași cazuri de test eșuate sau blocate pot fi executate din
nou pentru a retesta funcționalitatea.Criteriile de intrare pentru această etapă sunt:
finalizarea Planului de testare și a fazei de scriere a cazurilor de testare;Criteriile de ieșire
necesită validarea cu succes a tuturor cazurilor de testare; Defectele trebuie închise sau
amânate; Rularea cazului de testare și raportul sumar al defectelor ar trebui să fie gata.
Activitățile care urmează să fie efectuate în faza de rulare a testelor sunt:-Rularea cazurilor
de testare (Test case execution report); -Raportarea rezultatelor testelor;-Înregistrarea
defectelor pentru cazurile de test eșuate;-Verificarea și reexaminarea defectului;-Închiderea
defectelor.Rezultatele care trebuie realizate în această etapă sunt:- Raport de rulare a
testelor(Test case execution report); -Raport cu defecte(Defect report);-Jurnal de teste și
jurnal de defecte (Test log), (Defect log);- Cazuri de test actualizate cu rezultate.

6.Închiderea ciclului de testare Aceasta este ultima etapă a STLC, în care se analizează
procesul de testare.Are loc o întâlnire a echipei de testare,având ca scop o evaluare a
proiectului.Se va avea în vedere ce a fost realizat cu succes,ce este de îmbunătățit,iar
întreaga intenție a acestei discuții este de a învăța lecții din ceea ce a funcționat greșit. Acest
lucru va ajuta în proiectele viitoare. De asemenea,aceasta implică o analiză a defectelor
găsite și a altor valori, cum ar fi: câte cazuri de teste au trecut / au eșuat / au fost omise.
Criteriile de intrare pentru această fază sunt ca rularea cazului de testare să fie completă,
rezultatele testelor să fie disponibile și raportul defectelor să fie gata.Criteriile de ieșire
pentru această fază sunt: furnizarea de rapoarte de închidere a testelor (Test Closure
Report), împreună cu Valorile Testului (Test metrics) Activitățile care trebuie relizate în
această etapă sunt:-Evaluarea criteriilor pentru finalizarea ciclului în funcție de timp,
acoperire de test(Test coverage), costuri, obiective critice de afaceri,calitate, precum
pregătirea Valorilor de Testare(Test metrics),pe baza parametrilor anterior menționați;-
Pregătirea raportului de închidere a testului(Test Closure Report);-Analiza rezultatelor
testului pentru a determina distribuția defectelor în funcție de tip și severitate. Rezultatele
care trebuie realizate în acestă etapă sunt:-Raport de închidere a testului(Test Closure
Report);-Valorile testului(Test metrics).
 Acceptance criteria means the expected behavior of a functionality, module and application
as listed in the requirement documents. It is verification stages/checkpoints to determine
whether or not the software system has met the requirement specifications. The main
purpose of this test is to evaluate the system's compliance with the business requirements
and verify if it has met the required criteria.
 Acceptance Criteria is a set of statements, that mentions clearly about the expected
pass/fail result. Acceptance criteria specifies both functional and non-functional requirements.
These requirements represent “conditions of satisfaction or expected behaviour.” There is no
partial acceptance; either a criterion is met or it is not met.

Test Closure

Test Closure is a document that gives a summary of all the tests conducted during the software

development life cycle, it also gives a detailed analysis of the bugs removed and errors found .

In other words, Test Closure is a memo that is prepared prior to formally completing the testing

process. This memo contains a report of test cases executed, type and number of defects found,

the density of defects, etc.

Automation Feasibility Analysis Back to the above example, the project team decided to develop a
custom tool which can meet project requirements. Suppose they have been given 100 test cases to
automate and they estimated 5 days to develop a tool which can automate all of those test cases.

Here is the result of their work.....As in above scenario, the issue is that the test tool cannot automate
all the test cases of test specification. It means that not all application features can
be thoroughly tested using the test tool.

If the functionality of application under test changes frequently or is too complicated, it is difficult to

create test automation for all the application features, because every tool has its own limitations.

If you don’t want to be in such situation, before selecting the test tool, you must analyze the test cases
and decide which test cases should be automated and which test cases should not. This is
the Automation Feasibility Analysis activity.

Automation Feasibility Analysis is the very significant contributor in testing. In this analysis, you need
to check if the application under test is qualified for automated test.

A build includes all data files, libraries, reusable modules, engineered components that are required
to implement one or more product functions.Smoke Testing is done whenever the new functionalities
of software are developed and integrated with existing build that is deployed in QA/staging
environment. It ensures that all critical functionalities are working correctly or not. Whenever there is a
change in the build, we perform Smoke Testing to ensure the stability.

Example: -New registration button is added in the login window and build is deployed with the new
code. We perform smoke testing on a new build.Software Testing Metric is be defined as a
quantitative measure that helps to estimate the progress, quality, and health of a software testing
effort. A Metric defines in quantitative terms the degree to which a system, system component, or
process possesses a given attribute.Software testing metrics or software test measurement is the
quantitative indication of extent, capacity, dimension, amount or size of some attribute of a process or
product.

Example for software test measurement: Total number of defects