Every tester remembers where they started.
For me, it started with manual testing—understanding requirements, exploring applications, finding defects, writing test cases, and asking the classic QA question:
“But what happens if I do this?”
At the time, testing meant understanding an application from a user's perspective and trying to uncover everything that could possibly go wrong.
But as my career progressed, so did my curiosity.
From UI to APIs
My journey gradually moved into API testing.
That was when I started looking beyond what was visible on the screen and became more interested in what was happening behind it.
Requests. Responses. Status codes. Payloads. Headers. Data flowing between systems.
It changed the way I looked at testing.
Instead of only asking, “Does the application work?" I started asking, “How does it work?”
And that curiosity eventually led me to automation.
Enter Java & Selenium
My next chapter was Java and Selenium.
This was probably one of the biggest transitions in my QA journey because testing was no longer just about identifying scenarios—I had to translate those scenarios into code.
Locators became part of everyday life.
So did waits, WebDriver, frameworks, debugging, exceptions, failed builds…and occasionally wondering why something worked perfectly yesterday but refused to work today. 😄
Over time, automation stopped feeling like simply writing scripts.
It became about writing tests that were reliable, reusable, and maintainable.
Alongside UI automation, I continued working with REST API testing and automation, which helped me understand applications from multiple layers rather than only through the browser.
And Now—Playwright & TypeScript
Today, I'm working in the banking domain, and my automation journey has taken another turn:
Playwright + TypeScript.
Moving from Java and Selenium to Playwright and TypeScript has meant learning new syntax, new concepts and, sometimes, completely new ways of approaching familiar automation problems.
Some things feel easier.
Some feel different.
And some send you down a debugging rabbit hole before giving you that incredibly satisfying:
“Ohhh… THAT was the problem.”
And that's exactly why I decided to start writing.
Why This Blog?
This isn't going to be a collection of perfect textbook definitions.
I want it to be about the things we actually encounter while working with automation.
The locator that matches five elements when you need one.
The dropdown that disappears the second you open DevTools.
The test that passes locally and mysteriously fails somewhere else.
The XPath that works—but probably shouldn't.
And, most importantly, figuring out why something works instead of simply copying a solution.
I'll be sharing what I'm learning about Playwright, TypeScript, Selenium, API automation, XPath, Cucumber, debugging and test automation in general.
Some posts will be tutorials.
Some will be solutions to specific problems.
And some will simply be lessons I wish I'd known earlier.
Because after moving through:
Manual Testing → API Testing → Java & Selenium → REST API Automation → Playwright & TypeScript
I've realized that technology never really gives you a point where you can say:
“Okay, I know everything now.”
There's always another tool to learn, another problem to solve, and another better way to build something.
So this blog is my place to document that journey.
Learning. Debugging. Building. Sharing.
One problem—and hopefully one useful solution—at a time.
Top comments (0)