Cum am trecut examenul ISTQB Test Automation Engineer cu 72%

TL;DR

– Am revenit la examenul ISTQB TAE după ani de pauză și l-am trecut cu 72%.
– N-a fost despre „încă o certificare”, ci despre a-mi rafina gândirea de architect în automatizare.
– Am folosit ChatGPT și NotebookLM ca să clarific concepte și să structurez informația.
– Am învățat că TAE cere thinking de nivel arhitectural, nu memorare.
– Rezultatele arată clar unde sunt puternică și unde am loc să cresc (mai ales pe partea de verificare și îmbunătățire a soluțiilor existente).
– Universul s-a aliniat perfect: sunt într-un proiect unde pot aplica tot ce am învățat.
– Examenul e trecut. Nivelul următor abia începe.

---

Examenul ISTQB TAE nu este despre tool-uri sau scripturi.
Este despre arhitectură, strategie, mentenanță, risc și despre cum construiești automatizare care chiar rezistă în timp.
Și exact din motivul ăsta am revenit la el, chiar dacă prima mea tentativă a fost 62.67%.

Asta este povestea despre cum m-am pregătit, ce am schimbat și cum am reușit în final să iau 72%.
Am țintit mai sus, recunosc, dar uneori, la modul în care sunt formulate întrebările, și răspunsul corect pare greșit până în ultima secundă.

De ce am ales ISTQB TAE (și de ce chiar a contat pentru mine)

N-am dat certificarea asta pentru o insignă în LinkedIn, nici nu există așa ceva pentru TAE.
Am dat-o pentru că voiam cu adevrat să înțeleg partea de arhitectură din test automation la un nivel mai profund.

În ultimii ani, rolul meu a evoluat natural de la:

• a scrie scripturi,
• la a gândi soluții,
• la a mă uita la mentenanță pe termen lung,
• la a integra automatizarea în CI/CD și în realitățile produsului.

La un moment dat mi-am dat seama că întrebările care mă preocupau nu mai erau „întrebări obișnuite de automation engineer”:

• Cum proiectez ceva care să reziste?
• Cum fac scriptingul mai ușor și mai rapid?
• Cum evit haosul de mentenanță pentru echipă?
• Cum îl integrez corect în CI/CD?

Acestea sunt întrebări de arhitectură.

Și pentru că obiectivul meu pe termen lung este să cresc spre rolul de Automation Solution Architect, aveam nevoie de o fundație teoretică mai solidă pentru lucrurile pe care le aplicam deja intuitiv.

Syllabus-ul TAE acoperă exact asta:

• arhitecturi de automatizare (TAA, TAS, TAF)
• strategii de mentenanță
• testability și design de sistem
• integrarea în CI/CD
• deployment și specificul mediilor
• design patterns pentru automatizare la scară
• thinking orientat pe risc
• logging, packaging și măsuri de siguranță

Conectează ce facem în proiecte cu „gândirea din spate”, partea de arhitectură care de obicei nu e discutată, dar care decide dacă automatizarea supraviețuiește sau moare după câteva luni.

Deci nu, n-am ales TAE pentru examene. Ar fi masochism. 😅
L-am ales pentru direcția în care merg:
să construiesc sisteme de automatizare, nu doar scripturi.

Prima mea tentativă (62.67%)

Am încercat examenul acum câțiva ani și am fost destul de aproape să-l trec.
Așa au arătat rezultatele:

Uitându-mă acum, zonele în care am punctat mai slab sunt fix cele care aveau sens pentru experiența mea de atunci, în special:

• analiza unui TAS existent
• verificarea mediilor și setup-urilor
• înțelegerea riscurilor de deployment în profunzime

La momentul respectiv, lucram mai mult pe construirea de la zero a framework-urilor, nu pe moștenirea sau auditarea celor existente.
Deci capitolele care implicau:

• evaluarea arhitecturii altcuiva
• validarea unui TAS/TAA/TAF deja existent
• lucru cu structuri moștenite

nu erau punctele mele forte încă.

Nu m-am descurajat; doar am pus examenul pe pauză.
Știam că aveam nevoie de mai multă experiență reală și de un mindset diferit înainte să-l reiau.

Fast-forward în prezent, cu mai multă expunere la arhitectură și cu o abordare complet diferită de studiu, totul s-a legat.

Cum m-am pregătit de data asta (versiunea scurtă)

A doua tentativă n-a semănat deloc cu prima.
M-am concentrat mai puțin pe memorare și mai mult pe a înțelege cum funcționează arhitectura de automatizare în viața reală.

Pe scurt, ce a făcut diferența:

ChatGPT pentru claritate

Când un concept era prea academic sau teoretic, ceream exemple:

• scenarii practice
• explicații „de ce contează”
• analogii reale din proiecte

Asta m-a ajutat să trec de la teorie → intuiție.

NotebookLM pentru structură

NotebookLM a devenit locul unde mi-am organizat:

• mind map-uri
• rezumate
• flashcard-uri

L-am descoperit rușinos de târziu, la final, dar chiar și în câteva zile, mind map-urile au făcut minuni pentru memorare.

Practicarea gândirii pe scenarii

Întrebările din TAE sunt intenționat tricky și uneori două răspunsuri par corecte.

Așa că am exersat să identific:

• principiul din spate
• implicațiile arhitecturale
• varianta care se aliniază cu thinking de sistem

Asta a fost decisiv.

Nimic complicat, doar o schimbare de perspectivă și câteva tool-uri care mi-au organizat procesul.

Partea amuzantă e că am ajuns să scriu de mână, să fac liste și să subliniez pe hârtie, fix ca în anii de școală. Se pare că, indiferent câte tool-uri folosesc, rămân un millennial autentic când vine vorba de învățat.

Rezultatele: 72%, nu punctajul maxim, dar al meu

Scor final: 72%.

Mi-aș fi dorit un scor mai mare, evident.
Dar examenul pune accent pe interpretarea arhitecturală, așa că rezultatul reflectă exact cât de bine s-a aliniat modul meu de gândire cu scenariile prezentate.

Este un scor onest.
Reprezintă înțelegere, nu noroc.

Scorurile mai mici la capitolele 6 și 7 au perfectă logică. Încă sunt în etapa în care învăț cum să verific și să îmbunătățesc soluții existente și cum să adaptez raportarea pentru diferiți stakeholderi. Experiența mea reală este în principal în construirea framework-urilor, nu în auditarea sau extinderea celor existente.

Partea bună?
Tabelul arată foarte clar unde sunt puternică și unde am loc să cresc.

Ce m-a învățat cu adevărat TAE (dincolo de examen)

Parcurgerea syllabus-ului TAE nu mi-a schimbat modul de a gândi automatizarea, doar l-a rafinat.
Mi-a pus nume, structură și claritate pe lucruri pe care le aplicam deja intuitiv.

Câteva concluzii puternice:

• Mentenanța este o decizie de design, nu un „vedem noi mai târziu”.
• Automatizarea este atât de bună cât arhitectura din spatele ei.
• CI/CD nu mai este opțional.
• Testability ține de designul produsului.
• Automatizarea bună este invizibilă.

Studiul pentru TAE nu mi-a schimbat întrebările, le-a făcut mai precise.

În loc de:

„Cum automatizez asta?”

Acum mă întreb:

„Cum proiectez asta ca să scaleze, să reziste și să aibă sens și peste șase luni?”

Schimbarea asta singură face tot efortul să merite.

Concluzie

TAE nu a fost niciodată despre „încă o certificare”.
(Deși, recunosc, să mai adaug una în colecție e surprinzător de satisfăcător.)

Pentru mine a fost despre a-mi rafina modul de gândire, a-mi consolida bazele de arhitectură și a mă pregăti pentru următorul nivel în carieră.

Examenul a arătat foarte clar unde sunt puternică și unde trebuie să cresc.
Și culmea, universul s-a aliniat perfect: sunt într-un proiect în care pot aplica tot ce am învățat, pas cu pas, de la zero.

Da, am trecut examenul.
Dar mai important, am făcut un upgrade real în modul în care gândesc și construiesc automatizare.

Și asta e doar începutul.