This year I am celebrating 10 years since I started working as a QA.
Ten years… It sounds like a lot when I say it out loud. But in my head, I can still clearly remember my first days on the job. Sitting in front of the screen, learning the functionalities of my first project, trying to think about some scenarios that I can try, opening a ticket…
Back then, everything was new for me, and it was kind of confusing, scary, interesting, and exciting at the same time. Now, when I think of it, I have only positive and interesting memories.
Where It All Started
Back then, when I started in 2016, my job was simple.
I would open a ticket from the board, read the description, and try to follow it as closely as possible. If something didn’t work, I would report a bug. When the developer fixed it, I would test it again.
That cycle repeated every day. I had a couple of tickets ready for testing every day. I would go through that list, test them manually till the working day ends, and that was mostly it.
At that time, I thought: “This is QA. This is what testing looks like.”
There was no pressure to think outside the box. No expectation to challenge anything. No need to understand the bigger picture. If it worked as expected, it passed.
Now, when I think about it, all I did back then was click buttons based on what was written in the requirements. It was more like checking the tickets, and not like a real testing and QA process.
The First “Upgrade”
At some point, I got introduced to automation. And like many QAs back then, my world suddenly revolved around Selenium. Our software was too complex to test properly only with manual testing, so we decided to find a solution how we can speed up the process. At that time, the obvious choice was Selenium, and I think that we were working with Selenium with C#.
I still remember the first time I ran an automated test and watched it execute steps on its own. It felt powerful, like I was doing something advanced. Something that not everyone could do. It was really interesting for me to watch how the test goes through the screens, making actions on the elements, and doing assertions.
But looking back now, even that had its limits. Because even though I was writing scripts, I was still following the same mindset. I wasn’t designing tests. I was translating manual steps into code.
The Shift
Over the years, things slowly started to change. Not overnight, and not because of one project, but through experience.
I started to be more curious and ask more questions.
Not just “Does this work?”
But “What happens if this goes wrong?”
I started paying attention to things that weren’t written, like edge cases, user behaviors, and unexpected flows. I have started to learn different testing techniques, tools, ways of thinking…
I have become familiar with and worked with tools like Cypress, Playwright, RestAssured, Appium, JMeter, K6, Katalon, Test Rigor, and a lot more.
And more importantly, I started getting involved earlier. Before, I would wait for a ticket to be ready. Now, I wanted to be there when it was still being discussed. Because I realized that the earlier you think about quality, the less you fix later.
The Unexpected Side of the Journey
If you had told me 10 years ago that QA would give me opportunities beyond testing, I probably wouldn’t believe you.
But it did.
During my career, I had an opportunity to make presentations and to teach the end-users how they can use the software. In one project, I was also part of the process where the end-users were using the system in real conditions.
I also had the opportunity to mentor QA students. People who were just starting and who were interested in this role, just like I once was. And I saw myself in them, the same questions, the same confusion, the same curiosity. But also the same potential to grow.
I had the chance to organize and mentor QA workshops in my company, but also in the faculty of computer science and engineering. Standing in front of a group, explaining concepts, sharing experiences… and realizing that teaching actually makes you understand things even better.
And then came moments I never expected, like being part of a podcast, talking about QA, sharing my perspective, and reflecting on the journey.
This blog is also part of my QA journey 🙂
What I want to say is, QA is not just a job and clicking buttons. It’s a field where you can grow, share, and influence others.
A Completely Different World
While all of this was happening, the tools around us were evolving fast.
From Selenium, the ecosystem expanded into something much bigger. New tools like Cypress and Playwright changed how we approach web testing. Mobile testing became more accessible with Appium.
And then… AI entered the picture.
Writing test scenarios, writing tests, making analysis, creating reports… everything started to feel different.
Faster, easier, and assisted. Things that used to take time now happen in seconds. But at the same time, it became clear that tools are evolving faster than people’s thinking.
The Part That Feels Different Today
To be honest, not everything about this evolution feels positive.
One thing I’ve noticed is that the QA role itself is changing in ways that are not always clear.
In some companies, there are fewer dedicated QA roles. Testing responsibilities are being spread across developers, product owners, and business analysts. In other companies, you can see combined roles.
There’s also more pressure now. You’re expected to know more, do more, cover more, and sometimes, that comes at the cost of depth.
Automation and AI
With everything we have today, automation frameworks, AI tools, and smart assistants, it’s easy to think that QA is becoming easier.
But in reality, the QA role is just becoming different.
You can generate tests, reports, and plans, you can run thousands of checks, but if you don’t understand the product, you’ll still miss what matters.
None of these tools can replace your ability to think critically. As a QA, you need to be the most demanding user who will ever use the system. Use the AI tools to speed up the process and make it more efficient, and use your human QA skills to verify the products as an end-user, because at the end of the day, the end-users are the humans. That’s why we need to put ourselves in the position of an end-user and to verify not just if it is working, but also how it is working, how it looks for the end-users, and whether it is achieving their goals.
How I See QA Today
If I compare myself from 10 years ago to now, the biggest difference is not in what I do. It’s in how I see things.
Back then, I was focused on tasks, and now, I’m focused on impact.
Back then, I trusted what was written, and now, I question what’s missing.
Back then, I was testing features, and now, I’m trying to understand the product as a whole.
What Comes Next?
If there’s one thing I’m sure about, it’s that the QA role will keep changing.
AI will become more involved.
Tools will become smarter.
Roles will continue to evolve and change.
Five years ago, we didn’t even have Chat GPT, Copilot, Claude, or Gemini. And we were in the middle of a pandemic… So if you ask me what comes next, and how will the QA role look in 5-10 years… I would just say who knows… The time will show.
Final Thought
When I started, QA felt predictable.
Now, it feels dynamic, more challenging, more demanding, but also more meaningful.
And maybe that’s the biggest change of all. It’s no longer just about testing software. It’s about understanding it, improving it… and sometimes even shaping it. To achieve that, now we have more tools and more opportunities than before.
And looking back at these 10 years… I feel really grateful for all the opportunities that I had, all the people that I met, all the things that I’ve learned, and all the projects that I worked on.
I can say one thing for sure:
I didn’t just grow as a QA. I grew in the way I think.
Cheers for these 10 years, and let the next 10 years be even better 🥂
