În ultimii ani, rolul de QA a depășit de mult zona clasică de "testare". Un QA modern nu mai validează doar funcționalități, ci navighează constant între requirements, acceptance criteria, buguri, automatizare, raportare și comunicare cross-team. De multe ori, timpul petrecut efectiv testând este mai mic decât timpul petrecut reconstruind contextul din jurul testării.
Provocarea care apare este volumul de context care trebuie urmărit simultan: Jira, Confluence, Slack sau Teams, browser, logs, pipeline-uri CI/CD și frameworkuri de automatizare. Într-o singură zi, aceeași persoană poate ajunge să analizeze/scrie documentație, să investigheze un bug, să execute scenarii manuale, să repare/scrie teste automate și să centralizeze rezultatele pentru restul echipei. Uneori, pe mai multe medii. Toate fac parte din același proces, dar cer moduri diferite de gândire.
Într-un fel, QA-ul funcționează deja ca un sistem orchestrat de roluri separate. Multe companii împart responsabilitățile între QA Manual și QA Automation, iar echipele încearcă permanent să reducă timpul pierdut între pașii unui flux. Pornind de la această realitate, ideea a fost să mut o parte din muncă din zona de execuție manuală repetitivă într-un sistem de agenți specializați. Nu pentru a înlocui rolul de QA Engineer, ci pentru a vedea cât de mult îl poate completa o "echipă" de agenți, atunci când fiecare are un rol bine delimitat: colectarea contextului, validarea flow-urilor, generarea testelor automate sau raportarea rezultatelor într-un mod coerent.
La început, am folosit un singur agent IA strict ca suport pentru partea de automation. Integrat direct în Visual Studio Code, acesta prelua taskuri repetitive precum generarea de teste noi, mentenanța celor existente, refactorizări sau explicații rapide pentru anumite segmente de cod. Impactul s-a simțit rapid, mai ales în activitățile repetitive și consumatoare de timp. După ce am văzut că agentul chiar aduce valoare în zona automation, următorul pas a venit natural: să nu mai fiu eu cel care îi adună mereu contextul. În loc să primească de fiecare dată requirements copiate manual sau explicații lungi despre ce trebuie făcut, ce s-ar întâmpla dacă agentul și-ar putea colecta singur informațiile direct din sursele deja existente în procesul de QA?
Așa a apărut tranziția către un sistem multi-agent. În loc ca un singur agent să încerce să facă totul, responsabilitățile au fost separate pe roluri clare: Mastermind, care coordonează pașii; Explorer, care colectează context din Jira și Confluence; Executor, care execută scenarii în browser; Crafter, care se ocupă de automation; Scribe, care raportează rezultatele; și Healer, care folosește feedbackul pentru a îmbunătăți rutina agenților. Separat de fluxul principal, Architect poate fi folosit pentru refactorizări mai mari, mentenanță structurală și reducerea codului duplicat.
Din acel punct, accentul s-a mutat de la "cât de mult poate face un singur agent?" la "cât de bine pot colabora mai mulți agenți, fiecare pe bucata lui?". Separarea responsabilităților a făcut sistemul mai ușor de urmărit, mai ușor de corectat și, mai ales, mai predictibil în execuție.
Rolul Mastermind nu este să execute efectiv munca, ci să distribuie responsabilitățile și să păstreze firul procesului. Explorer colectează informațiile relevante din story-uri, buguri, acceptance criteria și documentație tehnică. Executor folosește aceste informații pentru a valida flow-uri în browser sau pentru a reproduce comportamente descrise în requirements și bug reports. Crafter poate apoi să genereze, să ajusteze sau să refactorizeze teste automate fără să mai primească pagini întregi de explicații pentru fiecare sarcină nouă.
Pe măsură ce fluxul devine mai complex, Scribe centralizează ce s-a implementat, ce scenarii au fost acoperite, ce probleme au apărut și unde există blocaje. Din raportările lui pot apărea tipare recurente: contexte interpretate greșit, erori repetate sau instrucțiuni care trebuie rafinate. Aici intervine Healer, care nu execută taskuri de testare, ci ajută la îmbunătățirea modului în care ceilalți agenți funcționează.
Un aspect esențial este controlul. Nu fiecare agent are nevoie de acces complet la întregul ecosistem. Explorer are acces read-only la Jira și Confluence. Executor are acces la browser și la acțiunile necesare pentru validare manuală. Crafter lucrează în zona frameworkului și a codului de testare. Healer este un caz mai sensibil, pentru că poate avea nevoie de drepturi de creare, actualizare și ștergere în zona de documentație, pentru a-și menține actualizată pagina și changelogul. Din acest motiv, orice operațiune de create, update sau delete trebuie să ceară aprobare explicită înainte de execuție.
O altă regulă esențială este oprirea fluxului după fiecare etapă majoră: Explorer — STOP. Executor — STOP. Crafter — STOP. Scribe — STOP. Scopul nu este încetinirea sistemului, ci existența unor puncte clare de verificare. Dacă Explorer extrage context greșit, nu are sens ca Executor și Crafter să continue pe o fundație defectă. Dacă Executor validează un flow greșit, automatizarea produsă ulterior va consuma timp fără să aducă valoare.
Prima încercare reală a pornit de la un story recent, cu acceptance criteria bine definite. Story-ul descria un tabel cu anumite coloane, butoane, filtre și informații afișate în interfață. Explorer a extras informațiile relevante, iar Executor a validat manual flow-urile menționate în acceptance criteria, plus câteva cazuri suplimentare care apăreau natural din comportamentul interfeței.
Partea de automation a fost cea mai interesantă. Crafter nu s-a limitat la happy flow-urile evidente. A generat și două teste pe care, sincer, probabil nu le-aș fi scris din proprie inițiativă într-o primă rundă de automation. Nu pentru că erau inutile, ci pentru că erau genul de verificări pe care le treci rapid la categoria "nice to have" atunci când ești prins în flow-ul principal. Primul valida existența unei iconițe și textul din tooltipul acesteia. Nu era un scenariu important, dar era exact genul de edge case care poate fi uitat atunci când te concentrezi doar pe flow-ul principal.
Al doilea test verifica navigarea între pagini, dar nu doar printr-un assertion simplu bazat pe un răspuns 200 OK de la endpoint. Înainte de assertionul final, salva un snapshot cu informațiile de pe pagina anterioară și îl compara cu snapshotul rezultat după navigarea către pagina următoare. Cu alte cuvinte, nu valida doar că navigarea "s-a întâmplat", ci că datele afișate chiar s-au schimbat într-un mod relevant.
Bineînțeles că au existat și eșecuri. Într-un alt run, i-am cerut agentului să se inspire dintr-o suită de teste existentă pentru o secțiune similară de încărcare documente. Agentul a luat indicația prea literal și a generat scenarii pentru butoane care existau în secțiunea veche, dar nu și în cea nouă. Din punct de vedere tehnic, structura testelor era coerentă. Din punct de vedere funcțional, unele scenarii nu aveau ce căuta acolo.
Acesta este riscul: agenții pot lucra foarte bine cu patternuri existente, dar dacă patternul este transferat fără suficientă validare, rezultatul poate deveni convingător și greșit în același timp.
Cele mai vizibile îmbunătățiri au apărut în zona de automation: generarea structurii inițiale pentru teste, refactorizările repetitive și ajustările pe teste existente au devenit semnificativ mai rapide. O altă zonă unde impactul s-a simțit clar a fost validarea bug fixurilor, mai ales când bugurile erau scrise de echipa de QA cu pași bine structurați și diferența dintre expected result și actual result clar evidențiată.
Probabil cea mai mare schimbare a venit din paralelizare. Cât timp Executor rula scenarii manuale pe un story sau un bug, eu puteam lucra în paralel pe alt task. Nu este vorba doar de viteză, ci de felul în care se schimbă distribuția atenției. Sistemul nu elimină nevoia de QA, dar poate prelua suficient din munca operațională încât omul să rămână concentrat pe validare, prioritizare și decizie.
Sistemul funcționează cel mai bine în taskuri repetitive, bine structurate și cu un context clar definit. În schimb, pe măsură ce gradul de ambiguitate crește, rezultatele devin mai greu de controlat. Requirements incomplete, acceptance criteria vagi sau flow-uri instabile introduc probleme pe care nici orchestrarea și nici separarea pe roluri nu le pot rezolva complet.
Un aspect important este că agenții tind să amplifice calitatea proceselor deja existente.
Într-un proiect bine organizat, cu documentație decentă și convenții clare, sistemul devine surprinzător de eficient. Într-un ecosistem haotic, lipsit de consistență sau cu multe excepții informale, agenții accelerează problemele deja existente.
Privind în urmă, sunt câteva lucruri pe care le-aș trata mai atent încă din primele iterații: aș începe cu mai puțini agenți, aș introduce punctele de verificare dintre ei mai devreme și aș trata permisiunile ca parte din arhitectură, nu ca pe un detaliu secundar. Și, poate cel mai important, nu aș mai încerca să rezolv ambiguitatea prin prompturi mai lungi. Dacă un story este neclar sau dacă informațiile se contrazic, un prompt mai mare nu repară problema. Cel mult, o ascunde pentru câteva minute.
La prima vedere, ideea unei "echipe" formate din agenți IA poate părea mai degrabă un experiment interesant decât un mod real de lucru. În practică însă, cele mai importante schimbări nu vin din complexitatea tehnologiei, ci din modul în care responsabilitățile sunt separate, coordonate și organizate în jurul unor roluri clare.
Valoarea reală nu apare în momentul în care omul este scos complet din proces. Din contră, cu cât sistemul devine mai capabil, cu atât rolul uman devine mai important în zone precum validarea, prioritizarea, interpretarea contextului și luarea deciziilor.
Poate tocmai aici apare partea cea mai interesantă: nu într-o încercare de a înlocui echipele existente, ci într-o extensie a lor. O simbioză între capacitatea umană de analiză și coordonare și abilitatea agenților de a executa rapid taskuri repetitive, consumatoare de timp și context.
În final, echipa aceasta nu există pe organigramă, nu apare în ședințe și nu cere concediu. Dar, dacă este bine coordonată, poate prelua suficient din zgomotul operațional încât QA Engineerul să se poată concentra pe ceea ce contează cu adevărat: judecată, calitate și decizie.
I, Robot - Isaac Asimov
de Dragoș-Ștefan Popescu , Andreea-Roxana Cotfas , Denisa-Vasilica Măgurean , Remus-Octavian Cîmpean
de Ovidiu Mățan
