Certificări QA / Testing (2026): ce apare în anunțuri și cum le folosești

În QA/Testing, certificările sunt rar “must-have”, dar pot ajuta în două situații:

• ești la început și vrei un semnal standard (mai ales pentru roluri de manual testing / entry),
• vrei să arăți structură și vocabular comun (test design, defect lifecycle, risk-based testing).

În schimb, pentru roluri de automation/SDET, semnalul cel mai puternic rămâne: ce ai automatizat, cum ai făcut flakiness triage, cum ai gândit test strategy și ce ai îmbunătățit în pipeline.

TL;DR

• Caută mențiuni explicite (ex: “ISTQB”, “CTFL”) în anunțuri, nu presupune.
• Dacă ai timp pentru un singur lucru: fă un mini-proiect cu teste automate + raportare + CI.
• În CV, pune rezultatul (ce ai prevenit/îmbunătățit) și concretul (framework, tipuri de teste, pipeline).

Ce certificări apar în anunțuri (din joburile active)

Lista de mai jos e construită din mențiuni explicite în joburile de QA/Testing din platformă.

Când merită (și când nu)

Merită dacă:

• ești junior / faci tranziție și vrei să arăți că ai bazele (terminologie, proces),
• aplici la companii care folosesc explicit certificări ca filtru (se vede în anunț),
• vrei să structurezi învățarea (test design, risk-based, reporting).

Nu merită ca “singur plan” dacă:

• țintești SDET/automation și nu ai proiecte sau contribuții concrete,
• vrei doar să bifezi keyword-uri (în interviu se vede imediat).

Ce proiecte “validează” cel mai bine (manual vs automation)

Manual QA

Un proiect mic, dar complet, arată bine dacă include:

• o aplicație de test (poate fi un demo public),
• test cases (happy path + edge cases),
• bug reports clare (steps, expected vs actual, environment),
• un mic “test plan” (scope, risc, prioritizare).

Automation / SDET

Un proiect bun (și realist) arată de obicei:

• smoke + regression (ce rulează mereu vs ce rulează nightly),
• flakiness handling (retries, waits, deterministic selectors),
• raportare (junit, screenshots, logs),
• un pipeline CI (GitHub Actions, GitLab CI) care rulează testele și publică rezultatele.

Greșeli frecvente

• Listezi “am testat X” fără rezultat: adaugă impact (“am redus bug-uri în prod”, “am scăzut timpul de release”).
• Te bazezi pe “tool list”: mai important e cum ai ales și cum ai făcut trade-off-uri (coverage vs cost).
• Scrii “automation” fără exemple: include 1–2 linkuri (repo, raport, pipeline).

Checklist rapid (test strategy)

• Ce teste sunt “must run” înainte de release (smoke) și ce intră în regression?
• Care sunt riscurile principale (auth, payments, data loss) și ce acoperi pentru ele?
• Cum tratezi flakiness (retries, waits, selectors, environments)?
• Cum raportezi clar: unde se vede failing test, loguri, screenshot, steps?
• Cum folosești feedback-ul: ce bug classes apar des și ce schimbi în proces?

Exemple de bullet-uri bune (QA/Automation)

• “Am redus flaky tests prin selectors stabili + waits explicite și am scăzut re-run rate-ul pipeline-ului cu X%.”
• “Am introdus smoke suite rulată la fiecare PR și am redus timpul de feedback pentru dev de la X la Y.”
• “Am creat un set de rapoarte (JUnit + artifacts) care a făcut debugging-ul reproducibil pentru echipă.”

Cum e construită lista (pe scurt)

• Scanează titlul + descrierea joburilor QA/Testing din platformă.
• Numără doar mențiuni explicite de certificări, nu tehnologii generale.
• Arată câte anunțuri menționează fiecare certificare, într-o perioadă recentă.

Următorii pași

• Vezi joburi QA/Testing: /ro/cariere-it/rol/qa-engineer
• Model CV QA