Testarea software e disciplina care verifică dacă un produs funcționează cum trebuie și caută activ locurile unde nu funcționează. Nu e „să dai click prin aplicație” — e o activitate structurată, cu tehnici și principii proprii. Acest curs urmează syllabus-ul oficial ISTQB Foundation (CTFL v4.0), standardul internațional al meseriei.

testarea e mai mult decât „execuția de teste”

O concepție greșită frecventă: testarea = rularea aplicației. De fapt, executarea testelor e doar o parte. Testarea include și activități statice (review-ul cerințelor, al codului — fără a rula nimic) și multă muncă de analiză, proiectare și planificare. Un tester bun gândește înainte și în jurul execuției, nu doar în timpul ei.

obiectivele testării

• Prevenirea defectelor — implicarea timpurie (la cerințe, design) previne defecte, nu doar le găsește târziu.
• Găsirea defectelor (failures) — descoperirea locurilor unde produsul se comportă greșit.
• Verificarea cerințelor — produsul face ce s-a cerut? (build the product right).
• Validarea — produsul răspunde nevoilor reale ale utilizatorului? (build the right product).
• Creșterea încrederii în nivelul de calitate.
• Furnizarea de informații pentru decizii (părțile interesate decid pe baza rezultatelor testării).
• Reducerea riscului și conformarea cu cerințe legale/contractuale/standarde.

testarea nu e „controlul calității” singur — QA vs QC

• Quality Assurance (QA) — orientată pe proces: asigură că procesele corecte sunt urmate ca să prevină defectele. Preventiv.
• Quality Control (QC) — orientat pe produs: activități (inclusiv testarea) care verifică produsul. Corectiv/detectiv.
• Testarea e o formă de quality control, care contribuie la calitate — dar calitatea se construiește de întreaga echipă, nu doar de testeri.

lanțul cauzal: eroare → defect → eșec

Trei termeni pe care ISTQB îi separă strict — confuzia lor e semn de amator:

Lanțul: un om greșește (error) → introduce un defect în cod → care, când e executat, produce un eșec. Atenție: nu orice defect produce un eșec (poate în cod care nu se execută niciodată), iar eșecurile pot avea și alte cauze (condiții de mediu, radiație etc.). Testerul observă eșecuri și, prin ele, deduce defecte.

cele 7 principii ale testării

1. Testarea arată prezența defectelor, nu absența lor. Poți dovedi că există bug-uri, niciodată că nu mai există niciunul. Testarea reduce probabilitatea, nu o anulează.
2. Testarea exhaustivă e imposibilă. Nu poți testa toate combinațiile de intrări și precondiții (ar fi infinite). De aceea folosești tehnici și prioritizare pe risc ca să testezi inteligent, nu tot.
3. Testarea timpurie economisește timp și bani (shift-left). Cu cât găsești un defect mai devreme (la cerințe, nu în producție), cu atât e mai ieftin de reparat. Un defect scăpat în producție costă de zeci de ori mai mult.
4. Defectele se grupează (defect clustering). Un număr mic de module conține majoritatea defectelor. Principiul Pareto: concentrezi efortul unde e istoric mai buggy.
5. Testele „obosesc” (pesticide paradox). Rulând aceleași teste la nesfârșit, nu mai găsești defecte noi (ca insectele care devin rezistente la pesticid). Trebuie să revizuiești și adaugi teste noi.
6. Testarea depinde de context. Testezi altfel o aplicație bancară față de un joc. Contextul (risc, domeniu) dictează abordarea.
7. Absența erorilor e o iluzie (absence-of-defects fallacy). Un produs fără bug-uri detectate poate fi tot inutilizabil dacă nu răspunde nevoilor reale. Corectitudinea tehnică nu garantează un produs bun.

Testarea nu e o singură activitate, ci un proces cu mai multe etape. ISTQB descrie un set de activități principale — nu neapărat secvențiale (multe se suprapun sau se repetă, mai ales în Agile).

activitățile principale ale testării

testware — produsele muncii de testare

Testware = tot ce se produce în timpul testării: planuri de test, condiții și cazuri de testare, date de test, proceduri, rapoarte de defecte, rapoarte de progres. E la fel de important ca produsul — se întreține și se refolosește.

trasabilitatea

Legătura dintre baza de testare (cerințe, riscuri) și testware: fiecare cerință e acoperită de teste, fiecare test se leagă înapoi de o cerință. Trasabilitatea îți spune acoperirea (ce s-a testat din ce trebuia) și impactul unei schimbări (dacă se modifică o cerință, ce teste trebuie revizuite).

contextul contează

Cum și cât testezi depinde de: modelul de dezvoltare (Agile vs secvențial), nivelul de risc (aplicație medicală vs blog), domeniu, constrângeri de timp/buget, contract și reglementări. Nu există „o singură rețetă” — al 6-lea principiu în acțiune.

Testarea are o dimensiune umană puternică. A căuta defecte în munca altcuiva atinge ego-uri; a face asta constructiv e o competență în sine.

mentalitatea testerului vs a dezvoltatorului

• Dezvoltatorul construiește: mentalitate de creație, „să funcționeze”. Are un bias natural spre a-și vedea munca funcțională (blindness to own errors).
• Testerul pune la îndoială: mentalitate de curiozitate critică, „unde se strică?”. Caută activ ce nu e în regulă — o formă de scepticism profesional constructiv.
• De aceea e greu să-ți testezi propriul cod obiectiv: e greu să găsești propriile greșeli. Un alt ochi găsește ce autorul nu vede.

niveluri de independență

Mai multă independență = mai puțin bias, dar și risc de izolare de echipă. Nivelul potrivit depinde de context și risc.

comunicarea defectelor — cu tact

• Un defect raportat prost sună ca o acuzație și naște defensivă. Raportează faptele, nu vina: „X se întâmplă când fac Y”, nu „ai stricat asta”.
• Colaborare, nu confruntare: scopul comun e un produs bun, nu „cine are dreptate”.
• Începe cu neutralitate, obiectivitate; comunică ce ai observat, cu dovezi (pași, capturi), calm.
• Empatie: dezvoltatorul a muncit la acel cod. Feedback-ul constructiv păstrează relația și eficiența echipei.

Testarea nu trăiește izolat — se integrează în ciclul de dezvoltare software (SDLC). Modul în care echipa dezvoltă dictează cum și când se testează.

modele secvențiale vs iterative

• Secvențiale (ex: Waterfall, V-model) — fazele urmează una după alta; testarea vine, clasic, la final. În V-model, fiecare fază de dezvoltare are o fază de testare corespondentă (planificată din start), aducând testarea „mai devreme” prin planificare.
• Iterative/incrementale (Agile, Scrum) — produsul crește în bucăți mici, la fiecare iterație se dezvoltă ȘI se testează. Testarea e continuă, integrată în fiecare sprint.

testarea în Agile

• Testerii sunt parte din echipă, implicați de la refinement-ul cerințelor.
• Feedback rapid și des; multă automatizare (regression) ca să țină pasul cu iterațiile.
• Practici precum TDD (test-driven), BDD, ATDD — testele scrise înainte/împreună cu codul.

shift-left: testează cât mai devreme

Shift-left = mutarea activităților de testare mai devreme în ciclu. În loc să testezi doar la final, implici testarea la cerințe și design: review-uri, criterii de acceptanță clare, teste scrise devreme. Prinde defectele când sunt ieftine (al 3-lea principiu) și previne, nu doar detectează.

testarea & DevOps / CI

În DevOps cu integrare continuă (CI), fiecare modificare de cod declanșează automat build + teste. Testarea automată devine o poartă: dacă testele pică, codul nu avansează. Feedback în minute, nu în zile.

nivelurile de testare — de la mic la mare

Testarea se organizează pe niveluri, fiecare cu obiect și responsabil diferit:

Ca Manual QA, lucrezi cel mai mult la nivel de sistem și acceptanță — verifici comportamentul aplicației complete din perspectiva utilizatorului.

tipurile de testare — ce aspect verifici

testarea de confirmare & de regresie

• Testare de confirmare (re-test) — după ce un defect e reparat, verifici că acel defect chiar a dispărut.
• Testare de regresie — verifici că modificarea (fix sau funcție nouă) nu a stricat ceva ce mergea. Candidatul #1 pentru automatizare, fiindcă se repetă des.

testarea de mentenanță

Când un sistem în producție se modifică (fix, upgrade, migrare, funcție nouă), testarea de mentenanță validează schimbarea și rulează regresie pe restul. Analiza de impact stabilește cât de larg trebuie testat.

Testarea statică examinează artefacte fără a executa codul: cerințe, specificații, cod sursă, modele, cazuri de testare. Se bazează pe examinare manuală (review-uri) și analiză cu unelte (analiză statică a codului). E una dintre cele mai valoroase — și mai subestimate — forme de testare.

de ce e atât de valoroasă

• Cel mai devreme feedback posibil: găsești probleme în cerințe/design înainte să existe măcar cod. Aplicarea supremă a shift-left.
• Ieftin: un defect prins într-o cerință ambiguă la un review costă infinit mai puțin decât dacă ajunge în cod și producție.
• Găsește lucruri pe care testarea dinamică nu le poate: cerințe contradictorii, ambiguități, cod mort, abateri de la standarde, mentenabilitate slabă.
• Previne defecte, nu doar le detectează — un review bun educă și aliniază echipa.

ce se poate examina prin review

Practic orice artefact scris: cerințe, user stories și criterii de acceptanță, arhitectură și design, cod, cazuri de testare, contracte, manuale. Dacă e scris, poate fi revizuit.

beneficiile review-urilor

• Detectarea și corectarea timpurie a defectelor.
• Înțelegere comună în echipă, transfer de cunoștințe.
• Responsabilizare colectivă asupra calității.
• Mai puține defecte care ajung la testarea dinamică (mai ieftin, mai rapid în ansamblu).

procesul de review (formal)

Un review formal urmează pași clari (ISTQB):

1. Planificare — se definește scopul, ce se revizuiește, cine participă, criteriile.
2. Inițiere — se distribuie materialul și se asigură că toți știu ce au de făcut.
3. Examinare individuală — fiecare reviewer parcurge artefactul singur și notează observațiile (defecte potențiale).
4. Comunicare & analiză — se adună observațiile, se discută, se decide ce e defect real, se atribuie corecții.
5. Fixare & raportare — autorul corectează; se verifică criteriile de ieșire.

rolurile într-un review

• Autorul — creatorul artefactului revizuit.
• Managerul / moderatorul (facilitator) — organizează, conduce ședința, medește.
• Scribe (secretar) — notează observațiile și deciziile.
• Reviewer — examinează, identifică defecte potențiale.
• Review leader — răspunde de review în ansamblu.

tipurile de review — de la informal la formal

factori de succes

• Obiective clare și un tip de review potrivit contextului.
• Piese mici (nu revizui 300 de pagini deodată — oboseala ratează defecte).
• Atmosferă constructivă: se critică artefactul, nu autorul (psihologia din modulul 1).
• Sprijinul managementului și integrarea review-urilor în proces, nu ca formalitate.

Aici testarea devine inginerie. Tehnicile black-box (bazate pe specificații) îți spun cum să alegi ce teste să scrii din comportamentul cerut, fără să privești codul. Rezolvă principiul #2: testarea exhaustivă e imposibilă → alegi inteligent un set mic dar reprezentativ.

partiționarea pe clase de echivalență (EP)

Ideea: grupezi intrările în clase care ar trebui tratate identic de sistem. Dacă o valoare din clasă funcționează, toate ar trebui să funcționeze — deci testezi o singură valoare per clasă, nu toate.

analiza valorilor de frontieră (BVA)

Bug-urile se cuibăresc la margini (erori de tip „< vs <=”, off-by-one). BVA testează exact granițele claselor.

de ce funcționează

• Reduci drastic numărul de teste păstrând acoperirea semnificativă.
• Țintești unde defectele apar statistic cel mai des (marginile).
• Sistematizezi: nu „ce-mi vine în minte”, ci o metodă repetabilă și justificabilă.

tabele de decizie — pentru reguli combinate

Când rezultatul depinde de combinații de condiții, EP/BVA nu ajung. Un tabel de decizie enumeră sistematic combinațiile de condiții și acțiunea pentru fiecare — nu ratezi nicio combinație.

Tabelele de decizie sunt esențiale pentru logica de business: prețuri, eligibilitate, permisiuni, validări cu mai multe condiții.

testarea tranzițiilor de stare

Când sistemul se comportă diferit în funcție de starea în care se află, și evenimentele îl trec dintr-o stare în alta, folosești o diagramă de stări și testezi tranzițiile.

Perfect pentru: fluxuri de autentificare, coșuri de cumpărături, procese de aprobare, playere media, orice „wizard” cu pași — sisteme cu memorie a stării.

când folosești ce

Tehnicile white-box (bazate pe structură) derivă testele din structura internă a codului, nu din specificații. Măsoară acoperirea: cât din cod a fost efectiv executat de teste. Sunt tipic treaba dezvoltatorilor, dar un Manual QA trebuie să înțeleagă conceptele — apar la examen și în discuțiile cu echipa.

acoperirea de instrucțiuni (statement coverage)

Măsoară ce procent din liniile de cod (instrucțiuni) au fost executate de teste.

100% statement coverage = fiecare linie a rulat măcar o dată. Dar atenție: nu garantează că ai testat toate deciziile.

acoperirea de ramuri (branch coverage)

Măsoară ce procent din ramurile de decizie (rezultatele true/false ale fiecărui if, fiecare cale) au fost executate.

ce înseamnă (și ce NU) 100% acoperire

• 100% acoperire = tot codul existent a fost executat de teste.
• NU înseamnă cod fără bug-uri: nu poate găsi funcționalitate lipsă (cod care ar fi trebuit scris dar nu există) sau cerințe greșite. Acoperirea măsoară ce e, nu ce ar trebui să fie.
• E o metrică, nu un scop în sine — 100% acoperire cu aserțiuni slabe e iluzorie.

Tehnicile bazate pe experiență valorifică intuiția, cunoștințele și creativitatea testerului — nu o specificație formală. Sunt complementare celor sistematice (black/white-box): prind defecte pe care metodele formale le ratează, mai ales unde specificațiile sunt incomplete.

error guessing (ghicirea erorilor)

Testerul, pe baza experienței, anticipează unde e probabil să apară defecte și țintește acolo. Vine din cunoașterea greșelilor tipice ale programatorilor și a locurilor fragile.

• Exemple de „suspecte”: câmpuri goale, zero, valori negative, texte foarte lungi, caractere speciale/emoji, divizare la zero, date invalide (30 februarie), input duplicat, dublu-click.
• Se poate sistematiza cu liste de defecte tipice (taxonomii) acumulate în timp.

testarea exploratorie

Testerul explorează aplicația, învățând-o și proiectând-și testele simultan, în timp real. Nu urmezi scenarii pre-scrise — reacționezi la ce descoperi, urmărind fire interesante.

• Eficientă când specificațiile lipsesc/sunt slabe, sau ca „a doua trecere” peste testarea scriptată.
• Se structurează adesea cu session-based testing: sesiuni cronometrate cu un charter (o misiune: „explorează checkout-ul cu focus pe cupoane”) și note.
• Depinde mult de skill-ul testerului — un tester bun găsește enorm; slab, ratează. Reproductibilitatea e mai slabă (de aceea notezi bine ce faci).

testarea bazată pe checklist

Testerul folosește o listă de verificări (aspecte de acoperit) construită din experiență, standarde sau cerințe. Oferă structură fără scenarii detaliate.

• Exemplu: checklist de uzabilitate, de compatibilitate cross-browser, de securitate de bază, de accesibilitate.
• Echilibru bun între rigoarea scriptată și libertatea exploratorie; ușor de întreținut.

Testarea trebuie condusă, nu doar făcută. Managementul testării organizează efortul: ce testăm, cum, cine, când, cu ce resurse și pe baza căror riscuri.

planul de testare

Documentul (sau setul de decizii, în Agile) care descrie ce și cum se testează. Elemente tipice:

• Obiective și scop — ce se testează, ce e în afara scopului.
• Abordarea (strategia) — ce niveluri, tipuri, tehnici; cât manual/automat.
• Criterii de intrare/ieșire — când putem începe; când considerăm „gata” (definition of done).
• Resurse, mediu, planificare temporală — oameni, unelte, date de test, calendar.
• Riscuri și cum le adresăm.

criterii de intrare & de ieșire

• Intrare (entry / definition of ready) — condițiile ca să poți începe testarea (mediu pregătit, build stabil, cerințe clare).
• Ieșire (exit / definition of done) — condițiile ca să declari testarea încheiată (acoperire atinsă, defecte critice rezolvate, criterii de risc satisfăcute). Fără ele, testarea „nu se termină niciodată” sau se oprește arbitrar.

testarea bazată pe risc — inima priorizării

Fiindcă nu poți testa tot (principiul #2), prioritizezi pe risc. Un risc de produs = posibilitatea ca produsul să eșueze într-un mod care contează.

• Zonele cu risc mare (probabile ȘI cu impact serios — plăți, autentificare, date) → testate întâi și cel mai intens.
• Zonele cu risc mic → testate mai superficial sau mai târziu.
• Riscul ghidează ce, cât și în ce ordine testezi — resursa limitată (timpul) merge unde contează.

estimarea efortului de testare

Cât va dura testarea? Tehnici uzuale:

• Bazată pe metrici — folosești date istorice (proiecte similare: câte teste, cât timp per test).
• Bazată pe experți — estimările celor care fac munca (ex: planning poker în Agile, Delphi).
• Factori care influențează: complexitatea produsului, nivelul de risc, calitatea cerințelor, skill-ul echipei, unelte, cât se automatizează.

monitorizare & control

• Monitorizarea — colectezi date despre progres: câte teste rulate/rămase, câte trec/pică, defecte deschise/închise, acoperirea riscurilor. Răspunde la „unde suntem?”.
• Controlul — acțiuni corective când realitatea deviază de la plan: reprioritizezi, realoci, ajustezi scopul, escaladezi. Răspunde la „ce facem în privința asta?”.
• Instrument tipic în Agile: burndown chart, board-uri (Jira), rapoarte zilnice.

raportarea progresului

Comunici părților interesate starea calității, ca ei să poată decide (ex: livrăm sau nu?). Un raport bun spune nu doar „câte teste”, ci ce risc rămâne, ce defecte critice sunt deschise, dacă suntem pe criteriile de ieșire.

metrici uzuale

Găsirea unui defect e doar începutul. Un defect trebuie gestionat printr-un flux clar, de la descoperire până la închidere, ca nimic să nu se piardă și fiecare să știe ce are de făcut.

de ce management structurat al defectelor

• Ca fiecare defect să fie urmărit până la rezolvare (nu uitat într-un chat).
• Ca echipa să vadă starea calității (câte deschise, cât de grave).
• Ca deciziile să fie informate: ce reparăm acum, ce amânăm, ce livrăm.
• Ca să existe istoric și trasabilitate (util și pentru defect clustering — unde se adună).

ciclul de viață tipic (stări)

Fluxul principal: Open → Assigned → Fixed → Retest → Closed. Dacă retestul eșuează → Reopened. Detaliile variază per echipă/unealtă (Jira, Azure DevOps), dar logica e universală.

clasificarea defectelor

• Severitate (severity) — cât de grav e impactul tehnic (blochează sistemul? corupe date? sau e cosmetic?). O stabilește tipic testerul.
• Prioritate (priority) — cât de urgent de reparat din perspectiva business. O stabilește tipic product owner-ul/managerul.
• Nu sunt același lucru: o greșeală de scriere pe pagina principală poate fi severitate mică dar prioritate mare (o vede toată lumea); un crash într-o funcție rar folosită — invers.

Acesta e skill-ul zilnic definitoriu al unui Manual QA. Un bug report prost („nu merge”) irosește timpul tuturor și naște frustrare. Unul excelent duce la reparare rapidă și te face de încredere. Iată anatomia lui.

anatomia unui raport de defect

reproductibilitatea — regula de aur

Dacă developer-ul nu poate reproduce defectul, nu-l poate repara. Pașii tăi trebuie să fie atât de clari încât un străin să reproducă eșecul din prima. Include tot ce e necesar (și nimic în plus). Un defect care „apare uneori” — notează frecvența și orice tipar observat; intermitentele sunt cele mai grele, deci dovezile contează dublu.

calitățile unui raport bun

• Clar & specific — fără ambiguitate; cifre, nume exacte, mesajul de eroare textual.
• Obiectiv — fapte, nu emoții sau acuzații (psihologia din modulul 1).
• Minimal — cei mai puțini pași care reproduc defectul (elimină zgomotul).
• Complet — toate câmpurile de care are nevoie cel care repară; nu-l pune să te întrebe.
• Un defect per raport — nu îngrămădi mai multe într-unul (imposibil de urmărit/închis).

Uneltele susțin și automatizează părți din procesul de testare. Nu înlocuiesc gândirea testerului — o amplifică. Ca Manual QA folosești zilnic un set concret; e util să cunoști și peisajul mai larg.

categoriile de unelte (ISTQB)

ce folosește un Manual QA zilnic

• Un sistem de management al testării/defectelor (Jira + TestRail/Xray/Zephyr) — aici scrii cazuri de testare, execuți run-uri, raportezi și urmărești bug-uri.
• Postman — pentru a testa API-uri (trimiți cereri, verifici răspunsuri/status, fără UI).
• DevTools-ul browserului — consola (erori JS), tab-ul Network (cereri/răspunsuri, coduri HTTP), inspectarea elementelor. Indispensabil pentru dovezi și diagnostic.
• Unelte de captură/înregistrare — pentru dovezi în bug reports.
• BrowserStack/emulatoare — testare pe multe browsere/dispozitive.

beneficiile & riscurile automatizării

• Beneficii: repetiție rapidă și fiabilă (ideal pentru regresie), rulare la fiecare build (CI), acoperire pe multe configurații, elibererarea testerului pentru muncă creativă (exploratorie).
• Riscuri: cost de creare și mentenanță (teste fragile care se strică la orice schimbare de UI), așteptări nerealiste („automatizăm tot” — imposibil), automatizarea unor teste greșite. Automatizarea nu găsește defecte noi neprevăzute — verifică ce i-ai spus să verifice.

Pui tot cursul la lucru. Vei produce un pachet de testare pentru o funcționalitate reală — exact livrabilele muncii de Manual QA. Alege o funcție dintr-o aplicație pe care o folosești (login, un formular de înregistrare, un checkout) și lucrează pe ea.

funcția aleasă (exemplu): formular de înregistrare

Câmpuri: email, parolă (min 8 caractere, o cifră), confirmă parola, vârstă (18–120), checkbox „accept termenii”. Buton „Creează cont”.

livrabilul 1 — mini test plan

• Obiectiv & scop: ce testezi (validările și crearea contului), ce e în afara scopului (ex: emailul de confirmare).
• Abordare: black-box (EP + BVA pe vârstă și parolă; tabel de decizie pentru combinația termeni+câmpuri valide), plus exploratorie.
• Criterii de ieșire: toate cazurile critice trecute, zero defecte de severitate mare deschise.
• Riscuri: prioritizează validarea parolei și a duplicării emailului (impact de securitate/date).

livrabilul 2 — cazuri de testare (aplică tehnicile!)

Scrie un tabel cu: ID, titlu, precondiții, pași, date de test, rezultat așteptat. Derivă-le sistematic:

• EP: email valid vs invalid; parolă validă vs prea scurtă vs fără cifră; vârstă validă vs sub/peste interval.
• BVA pe vârstă (18–120): 17, 18, 120, 121.
• BVA pe parolă (min 8): 7 caractere, 8 caractere.
• Tabel de decizie: combinații termeni bifați/nebifați × câmpuri valide/invalide → cont creat sau eroare.
• Error guessing: email cu spații, parolă = confirmarea diferită, caractere speciale/emoji, câmpuri goale, dublu-click pe „Creează”.

livrabilul 3 — un bug report complet

Presupune că ai găsit un defect (ex: „acceptă vârsta 121 deși maximul e 120”). Scrie raportul cu toate câmpurile din modulul 7: titlu clar, precondiții, pași numerotați, rezultat așteptat vs real, severitate & prioritate, mediu, dovadă. Fă-l reproductibil de un străin.

definiția lui „gata”

• Test plan-ul acoperă obiectiv, abordare, criterii de ieșire și riscuri.
• Cazurile de testare sunt derivate cu tehnici (nu „la ochi”) și acoperă valide + invalide + frontiere + combinații.
• Bug report-ul e clar, minimal, complet și reproductibil, cu severitate/prioritate distincte.
• Bonus: o listă (checklist) de verificări exploratorii și o matrice de trasabilitate cerință → caz de testare.