How I passed the ISTQB Test Automation Engineer exam with 72%

TL;DR

– I returned to the ISTQB TAE exam after years and passed it with 72%.
– For me, it wasn’t about “another certification” - it was about sharpening my automation architecture thinking.
– I used ChatGPT and NotebookLM to simplify concepts and structure my study flow.
– TAE isn’t about memorization; it’s about architectural reasoning.
– My results clearly show both strengths and growth areas (especially around reviewing and improving existing solutions).
– Perfect timing: I’m now in a project where I can apply everything I learned.
– The exam is done. The next level is just beginning.

The ISTQB TAE exam is not about tools or test scripts. It’s about architecture, strategy, maintainability, risk, and building automation that lasts.
And this is exactly why I came back to it after years, even though my first attempt was 62.67%.

This is the story of how I prepared, what changed, and how I finally passed with 72%. I did aim higher, but to be honest, with the way these questions are written, sometimes even the correct answer feels incorrect until the very last second.

Why I chose the ISTQB TAE (and why it actually mattered to me)

I didn’t take this certification for a badge or a shiny label on LinkedIn. There isn’t even a badge for TAE.
I took it because I genuinely wanted to understand the architecture side of test automation on a deeper level.

Over the last years, my work naturally shifted from:

just writing automation,
to designing solutions,
thinking about long-term maintainability,
and aligning automation with CI/CD and real product constraints.

At some point I realized that the things I kept thinking about were not “regular automation engineer questions” anymore:

How do I design something that lasts?
How to make scripting easier and faster?
How do I avoid maintenance chaos for the team?
How does this integrate cleanly into CI/CD?

These are architecture questions.

And because my long-term goal is to grow into an Automation Solution Architect, I knew I needed a more structured, theoretical foundation behind the practices I was already applying intuitively.

The TAE syllabus covers exactly that:

automation architecture layers (TAA, TAS, TAF)
maintainability strategies
testability and system design
CI/CD integration
deployment and environment considerations
design patterns for automation at scale
risk-based thinking
logging, packaging, and safety measures

It connects the dots between what we do in real projects and the architectural thinking behind it. The part that often goes unspoken but decides whether automation survives or collapses after six months.

So no, I didn’t choose TAE for the exam itself. That would be masochistic. 😅 I chose it to support the direction I’m intentionally moving toward:
building automation systems, not just scripts.

My first attempt (62.67%)

I actually attempted this exam a few years ago and came very close to passing.
Here are the results from that attempt:

Looking back at those numbers, my weaker areas were exactly the ones that make sense for my experience at the time — mainly around:

analyzing an existing TAS
verifying automation environments
understanding deployment risks in depth

At that stage in my career, I was mostly building automation from scratch, not reviewing or inheriting existing frameworks.
So naturally, the chapters that involved:

auditing someone else’s architecture
validating existing TAS/TAA/TAF setups
working with inherited automation structures

were not my strengths yet.

I didn’t feel discouraged; I simply paused it.
I knew I needed more real-world experience and a different mindset before coming back to it.

Fast-forward to now, with more architecture exposure and a more intentional study approach, the content finally clicked.

How I Prepared This Time (Short Version)

My second attempt looked nothing like the first.
I focused less on memorizing and more on actually understanding how automation architecture works in real life.

To keep it simple, here’s what made the difference:

Using ChatGPT for clarity

Whenever a concept felt abstract or overly academic, I used ChatGPT to break it into:

real examples
practical scenarios
“why this matters” explanations

It helped me move from theory → intuition.

Using NotebookLM for structure

NotebookLM became my place to organize:

mind maps
summaries
flashcards

I discovered NotebookLM embarrassingly late, basically in the last days before the exam. But even in that short window, the mind maps helped me memorize things much faster. A small miracle at the perfect time.

Practicing scenario thinking

The exam questions are intentionally tricky and often feel like two answers are correct.
So I practiced the skill of identifying:

the principle being tested,
the architectural implication,
and which choice aligns with system-level thinking.

This was easily the most important part of my preparation.

That’s it. No overcomplicated process.
Just a shift toward architectural reasoning and tools that helped me structure my thinking.

The funny part is that I ended up writing things by hand, making lists, and highlighting on paper, just like in school. Turns out that no matter how many digital tools I use, I’m still a true millennial when it comes to learning.

The results: 72% - Not the highest score, but mine

Here are my results for the second attempt:

Overall score: 72%.

Did I want a higher score? Of course.
The exam requires a lot of architectural interpretation, so the score simply reflects how well my thinking aligned with the scenarios presented.

So 72% feels honest.
It reflects understanding, not guessing.

The lower percentages on Chapters 6 and 7 also make sense. I’m still in the phase of learning how to verify and improve existing automation solutions and how to tailor reporting for different stakeholders. Most of my real experience has been in building frameworks from scratch, not reviewing or extending someone else’s architecture.

More importantly, the table makes something very clear: I can see exactly where my strengths are, and exactly where I need to grow next.

What TAE actually taught me (beyond the exam content)

Working through the TAE syllabus didn’t change the way I think about automation, it refined it. It gave names, structure, and clarity to principles I was already applying intuitively.

A few things became very clear to me during this process:

Maintainability is a design decision, not an afterthought.
Every shortcut becomes technical debt for the entire team.
Automation is only as strong as its architecture. Tools don’t save you from a weak structure, they just hide it for a while.
CI/CD integration is not optional anymore. It shapes how we write tests, how fast we get feedback, and how reliable our pipelines are.
Testability is part of product design.
If the SUT(system under test) isn’t built to be tested, automation absorbs the cost.
Good automation is invisible. It doesn’t demand attention, it supports the team quietly and consistently.

Studying for TAE didn’t change the questions I ask in projects. It sharpened them.

Instead of:

“How do I automate this?”

I now think:

“How do I design this so it scales, survives, and makes sense six months from now?”

That shift alone made the entire process worth it.

Conclusion

TAE was never about collecting another certificate. Although I won’t lie, adding one more to the collection is oddly satisfying. For me, it was more about sharpening how I think, building a stronger architectural foundation, and preparing for the next step in my career.

The exam highlighted exactly where I’m strong and where I need to grow. And the timing couldn’t be better, I’m now in a project where I can take everything I learned and apply it directly.