Urmărești conferințe ca DevTalks sau A4Q Summit și, la un moment dat, îți dai seama că aproape fiecare al doilea speaker menționează low‑code sau no‑code. Pe LinkedIn, tool‑urile se laudă că "oricine poate testa fără o linie de cod". Și tu stai și te gândești: e real sau e doar un pitch de vânzări bine ambalat?
Răspunsul sincer? Puțin din amândouă. Și tocmai de aceea merită o discuție serioasă.
Ce înseamnă, de fapt, low‑code și no‑code în testare?
Înainte să judecăm, hai să definim termenii — pentru că sunt folosiți interschimbabil, ceea ce nu e corect.
No‑code testing înseamnă platforme unde construiești scenarii de test prin interfețe vizuale: drag‑and‑drop, record‑and‑playback, configurare prin meniuri. Zero cod. Exemple populare: Testim, Katalon Studio (în modul recorder), Leapwork.
Low‑code testing înseamnă că poți face 80% din treabă fără să scrii cod, dar ai posibilitatea să extinzi cu scripturi când logica devine complexă. Gândește‑te la Playwright în combinație cu un layer de abstractizare, sau la framework‑uri hibride construite peste Cypress sau Selenium 4.
Diferența contează. Un business analyst din echipa unui client bancar sau retail poate construi test case‑uri funcționale cu no‑code. Un QA engineer cu experiență o să aibă nevoie de low‑code pentru scenarii end‑to‑end complexe, cu apeluri API validate în Postman sau cu date extrase din MySQL.
De ce au prins atât de repede în piața din România?
Piața locală are câteva caracteristici care au accelerat adoptarea. Avem un deficit real de testeri cu experiență în automation — iar companiile din segmentele bancar, automotive, energie și retail au proiecte care nu pot aștepta 6 luni până angajezi un specialist Selenium 4 sau Playwright.
Echipele mixte — unde product owners, business analysts și QA lucrează cot la cot — au nevoie de un limbaj comun. Un tool no‑code devine acel limbaj. Scrie‑un scenariu în Gherkin, rulează-l vizual, arată rezultatul în JIRA — dintr‑o dată, toată echipa înțelege ce se testează și de ce.
Iar costul de onboarding scade semnificativ. Un junior care a absolvit un curs structurat de testare poate deveni productiv în săptămâni, nu luni, dacă tooling‑ul nu‑l blochează cu sintaxe complexe din prima zi.
Unde se termină magia și unde începe realitatea?
Aici e locul în care trebuie să fim onești, și o să fiu direct: low‑code și no‑code nu înlocuiesc gândirea de tester. Niciodată.
Un tool vizual poate înregistra click‑uri și valida texte pe ecran. Nu poate să identifice un risc de regresie ascuns în logica de business. Nu poate să decidă că scenariul X este mai important decât scenariul Y în contextul unui release critic. Nu are mindset‑ul de a pune întrebări incomode: "Dar dacă utilizatorul face asta în ordine inversă?"
La A4Q Summit și în comunitățile ISTQB internaționale se discută același lucru: tool‑urile devin mai accesibile, dar competențele de bază — analiza riscului, design‑ul de test case‑uri, înțelegerea unui pipeline CI/CD, comunicarea cu developerii — rămân la fel de valoroase. Poate chiar mai valoroase, tocmai pentru că sunt mai rare.
Un alt punct sensibil: mentenanța. Record‑and‑playback a existat de zeci de ani și a eșuat de fiecare dată din același motiv — aplicațiile se schimbă, selectoarele se rup, testele devin flaky. Low‑code și no‑code de generație nouă încearcă să rezolve asta prin self‑healing și AI‑assisted selectors, dar nu e o soluție perfectă. Cineva tot trebuie să înțeleagă ce se întâmplă când pipeline‑ul devine roșu la ora 3 dimineața.
Cum arată adoptarea concretă în echipele QA românești?
Din discuțiile noastre cu echipe din industrie — ospitalitate, electrocasnice, fintech — vedem un pattern clar: adoptarea low‑code/no‑code funcționează cel mai bine ca strat complementar, nu ca înlocuitor al automation‑ului tradițional.
Scenariile de smoke testing și regression de bază merg excelent pe platforme low‑code. Testele de integrare complexe, cele care verifică fluxuri end‑to‑end cu validări în baza de date MySQL sau apeluri REST inspectate prin Chrome DevTools, rămân în zona celor care știu să scrie cod.
Echipele care au reușit cel mai bine sunt cele care au investit în educarea întregii echipe — nu doar a testerilor tehnici. Când un business analyst știe să construiască un test case coerent, iar QA engineer‑ul știe să-l transforme într‑un script robust, viteza de livrare crește vizibil. Acesta e, de fapt, cel mai mare câștig real al low‑code testing.
Unde se poziționează testerul român în tot acest peisaj?
#FunFact: profesia de "Analist Testare Software" există oficial în COR din 2021, cu codul 351108. Academia Testarii a contribuit la acest demers. Ceea ce înseamnă că piața recunoaște formal că testarea e o meserie, nu un hobby sau un rol temporar.
Iar această meserie evoluează. Nu dispare. Se transformă.
Testerul de mâine — fie că lucrează în România sau remote pentru o echipă din Europa de Vest — va trebui să fie confortabil cu tool‑uri low‑code, să înțeleagă ce pot și ce nu pot face, și să rămână âncora de calitate în echipă. Va trebui să știe să seteze o strategie de test, să comunice riscurile, să colaboreze cu developerii în jurul unui pipeline și să explice unui product owner de ce un bug aparent minor poate opri un flux de plăți.
Asta nu se învață din record‑and‑playback. Se învață dintr‑un curriculum bine structurat, cu practică reală și mentori care au văzut proiecte reale.
Deci, hype sau revoluție? Revoluție reală — dar una care are nevoie de testeri bine pregătiți ca să livreze valoare. Tool‑urile democratizează accesul, nu elimină expertiza.
Dacă vrei să fii testerul care înțelege atât mindset‑ul, cât și tooling‑ul — cel pe care echipele îl caută — începe cu o bază solidă. Pe academiatestarii.ro găsești cursuri hands‑on care acoperă tot ce ai nevoie: de la fundamente și ISTQB, până la automation și integrare în pipeline‑uri reale.
Primul pas e al tău. Noi suntem aici. 🚀
#DeAziEstiTester #AcademiaTestarii #TestAutomation #SoftwareTesting #TestareSoftware