My journey into QA didn't start with a testing course.
It didn't even start with software testing.
It probably started when I was around four years old.
Every summer, I used to spend two or three months at my great-grandmother's house in the Czech Republic. I would spend entire days with my mother's cousin in a small storage room upstairs.
For most people, a storage room probably doesn't sound like the beginning of a career in technology.
For me, somehow, it was.
That was where my fascination with computers started.
I didn't know anything about QA, software development, CI/CD, or automation back then.
I just knew that computers were interesting.
And I wanted to understand them.
My first steps into programming
Later, while I was still in elementary school, I started attending a programming course.
We worked with PMD 85 computers, which were among the more accessible computers in our part of the world at the time.
We learned things like:
- BASIC
- Pascal
- Turbo Pascal
Looking back, those machines were incredibly limited compared to what we have today.
But that almost made them more interesting.
There wasn't an endless ecosystem of frameworks, cloud services, package managers, AI assistants, or Stack Overflow answers waiting for you.
If you wanted the computer to do something, you had to understand what you were telling it to do.
Eventually, I got my first computer of my own: a Didaktik Compact.
That changed things again.
I started learning programming by myself.
There was no clear career plan behind it.
I wasn't thinking:
One day I'm going to become a software engineer.
I was simply curious.
I wanted to know how things worked.
Then came Linux
Somewhere along that journey I discovered Linux.
And Linux stayed with me.
I started experimenting with some of the distributions that were available at the time, trying to understand the operating system and what I could do with it.
That relationship never really disappeared.
Even today, Linux and Bash are still part of the way I work and think about technology.
There was a period, especially during my teenage years, when programming became much less important to me.
Like a lot of teenagers, I spent much more time playing games than writing code.
Programming moved into the background.
Linux didn't.
It was always somewhere nearby.
Technology never completely left my life.
But my professional future ended up taking a very different direction.
A 20-year detour through mechanical engineering
When I reached secondary school, I chose a field that wasn't exactly the future I had imagined for myself.
I studied mechanical engineering.
And that decision ended up defining roughly the next twenty years of my professional life.
I worked as a mechanical designer and technologist.
I worked with manufacturing.
I programmed CNC machines.
I worked on the production of 3D components.
So even though I had moved away from traditional software development, programming never disappeared completely.
It simply changed form.
Instead of writing applications, I was telling machines how to manufacture physical components.
There is actually more overlap between these worlds than it might seem.
You still need to think logically.
You still need to understand a process.
You still need to understand what can go wrong.
You still need precision.
And mistakes can have very real consequences.
But somewhere in the back of my mind, the interest in IT was still there.
For years.
I just never really made the move.
Sometimes another person sees the path before you do
Then my life changed.
I met the woman who later became my wife.
She knew that IT had been something I had dreamed about since childhood.
And at some point she pushed me to finally do something about it.
She encouraged me to take an entry-level IT course.
I agreed, but with one condition:
She had to take the course too.
IT wasn't her field at all, which actually made me respect her even more for doing it with me.
We went through the course together.
I spent a lot of time helping her along the way, especially with the technical parts and the final assignment.
By the end, it sometimes felt like I had completed the course twice.
And strangely enough, I didn't mind.
I still don't.
Because that course became the point where something that had been sitting in the background of my life for years finally became real.
It was the beginning of my QA career.
My first QA job
My first job in IT was at SolarWinds in the Czech Republic.
Getting that job meant another major change.
We moved to Brno because of it.
I had finally entered the industry I had wanted to be part of for so long.
And then reality hit me.
I knew far less than I thought I did.
Almost everything was new.
Processes were new.
Terminology was new.
The way software teams worked was new.
Even something that seems completely normal to me today was confusing at the beginning:
DEV.
QA.
STG.
PROD.
Different environments, different responsibilities, different stages of the delivery process.
Today it sounds almost trivial.
At the time, it wasn't.
I had spent years working in technical environments, programming CNC machines and solving engineering problems.
But software development had its own language and its own mental model.
I had to learn all of it.
And I had to learn it quickly.
The person who helped me survive the beginning
One of the people I still remember very clearly from that period is my buddy, Ventsislav.
I owe him a lot.
Mostly because of his patience.
When you're new to an industry, there are questions you don't even know how to formulate yet.
Sometimes you don't understand a process well enough to know what part of it you're actually confused about.
Having someone who is willing to explain those things without making you feel stupid makes an enormous difference.
Ventsislav did that for me.
He helped me understand how the environment worked.
How the processes connected.
What QA was actually responsible for.
And how software moved through the organization.
At the beginning, I needed that help constantly.
But slowly, things started clicking.
And eventually something happened that meant a lot to me.
I became the buddy.
A new colleague joined, and this time I was the one mentoring and helping someone else understand the systems and processes.
That was probably one of the first moments when I realized just how far I had moved from those first confusing weeks.
At first, automation looked like magic
For a large part of my early QA career, my work was primarily manual.
Automation existed around me, but it was mostly something I admired other people for doing.
I could interact with automated tests.
I could change some parameters.
I could make smaller adjustments.
But building automation myself felt like another level.
Something other people knew how to do.
I think many manual testers know this feeling.
You look at automation engineers writing code and think:
I'd like to be able to do that.
But there is a big difference between wanting to understand something and actually sitting down and learning it.
Eventually, I did.
I took a Python course.
Then I started building my own projects.
And gradually, automation stopped looking like something that belonged to other engineers.
It became something I could do too.
That shift changed my career again.
From manual QA to automation
Today I work at Bata as a QA Automation Engineer.
My work looks very different from my first QA job.
I work with Robot Framework.
I work with Playwright and TypeScript.
I work with automated testing.
I deal with APIs, systems, environments, CI/CD processes, and the wider software delivery lifecycle.
And over time, my curiosity has pushed me even further.
Into DevOps.
Into alerting and observability.
Into what happens before and after testing.
Into understanding not just whether a feature works, but how the whole system behaves.
That curiosity is probably the one thing that connects every part of my career.
The four-year-old kid fascinated by computers.
The student programming a PMD 85.
The teenager experimenting with Linux.
The mechanical engineer programming CNC machines.
The new QA engineer trying to understand the difference between DEV, QA, STG, and PROD.
And the automation engineer I am today.
Different technologies.
Different industries.
Same question:
How does this actually work?
QA changed the way I look at software
When I started in QA, testing was much more concrete in my mind.
There is a requirement.
There is an application.
You test whether it works.
You find bugs.
You report them.
Over time, my view changed.
Quality isn't just about finding bugs.
A perfectly implemented feature can still become part of a risky release.
A test suite can pass while something important remains untested.
A deployment can succeed while the system becomes harder to operate.
A pipeline can be green while the team still doesn't have enough information to confidently release.
The further I went into automation, CI/CD, infrastructure, and release processes, the more I started looking beyond individual test cases.
Instead of only asking:
Does this work?
I started asking:
What could still go wrong?
That question eventually changed the direction of my work again.
But that's another part of the story.
Looking back
I didn't take the shortest path into IT.
Not even close.
There was childhood programming.
Linux.
A long break.
Twenty years in mechanical engineering.
CNC programming.
An IT course.
A move to another city.
A first QA job where almost everything felt unfamiliar.
Manual testing.
Python.
Automation.
Robot Framework.
Playwright.
DevOps.
And I'm still learning.
Maybe that's actually the part I enjoy most.
I don't think reaching a point where you finally "know enough" is the goal.
Every time I understand one part of software delivery better, I discover another layer underneath it.
QA led me to automation.
Automation led me toward CI/CD.
CI/CD made me interested in DevOps and release engineering.
And release engineering made me start asking much bigger questions about how teams decide whether software is actually ready to ship.
So if I had to explain why I stayed in QA, I wouldn't say it's because I enjoy finding bugs.
I stayed because QA gives me a reason to understand systems.
To question assumptions.
To investigate failures.
And to keep asking one of my favorite questions:
What could still go wrong?
This is the first article in my My QA Journey series.
In the next parts, I want to write about the move from manual testing to automation, the mistakes I made along the way, what I learned from developers and DevOps, and why understanding what happens after QA says "passed" completely changed the way I think about software quality.
