Tools Don’t Test. Testers Do.

A POC Journey from Frustration to Flow (Without Being a Programmer)

Jul 30, 2025

“I’m not a programmer. I’m a tester. But I still built a small, useful automation flow that replicates real user behavior — because no one else was doing it.”

🚀 Where It All Started

This wasn’t some grand strategy. No one assigned this work.
I just saw a problem, and I thought: “Can I automate this?”

There were some scenarios we had to test all the time, and they were time consuming.

Manual back-and-forth testing flow — our goal was to automate this repetitive setup and verification.

They were also required as preconditions for our UI end-to-end automation.

The tricky part?
It wasn’t like regular UI or API automation.
We needed a solution that could go back and forth:

Do system-level activities on a Windows machine
Then switch back to the dashboard
Verify results via API and sometimes via the browser UI

In practice, it looked like this:

Provisioning a Windows VM
Installing an agent
Checking services on Windows Machine
Finally validating its behavior on our dashboard UI

This back-and-forth flow was tedious to test manually, but I knew if I could automate it, our testing would become faster, consistent, and closer to real user workflows.

[Provision VM] → [Install Agent] → [Check Services on VM]
        ↘                                      ↗
         → [Validate on Dashboard via API/UI]

A Proof of Concept (and a Test of Myself)

This wasn’t a standard project. It was a POC, a Technical Opportunity Checkpoint.

I wasn’t sure if it could be done.
I wasn’t sure if I could do it.

I’m a software tester. I don’t write code all day. I’m not an SDET.
But I know how systems behave. I know how users install and use our product.
And I knew I could break this problem into pieces and explore.

So that’s what I did.

🔨 The Steps That Became the Framework

I started small. Just one step at a time:

Provision a Windows VM — Automated the process using Python scripts.
SSH into it — Used Python’s paramiko for secure remote access.
Copy the installer — Transferred the agent executable to the VM.
Execute PowerShell commands — Installed the software just like a user would.
Validate services — Parsed output from sc and PowerShell to confirm it was running.
Open the dashboard (UI) — Used Playwright (Python bindings) to verify the agent status, response, etc.

What started as a small test script became a complete system-level test framework that supported our UI automation.

🤯 Why Not Just Use TypeScript + Playwright?

We already use Playwright with TypeScript for our main E2E UI tests.
So why go off-path?

Because this wasn’t just a browser test.
It was a system flow — and Python made everything easier:

SSH, file transfers, service validation, error handling — all simpler with Python
No need for extra npm dependencies or complex orchestration
One script could handle system setup + UI verification
And yes, I was more comfortable in Python, which meant faster POC and feedback

Could this have been done in TypeScript? Probably.
But would it have been this simple and testable for our use case? Not really.

I’m Not a Coder. But I Had Help

I won’t lie — some of this was frustrating.
I had to learn things on the fly. I didn’t always know the right syntax. Sometimes I felt stuck.

But I wasn’t alone:

I leveraged GitHub Copilot to explore possible, concepts, solutions, and more.
I modeled the flow like a tester, always asking “What could go wrong?” and “What matters to the user?”

And guess what? That mindset made all the difference.

I didn’t just automate a flow. I explored a system.
And I built something my team can understand, extend, and use to test real risks.

🧠 What Made This Testing (Not Just Scripting)

This wasn’t automation for the sake of speed.

I didn’t:

Fake any steps
Short-circuit the system
Assume “if the service starts, it works”

I tested like a user:

Install like they install
Validate like they validate
Observe what they would observe

It was automation as exploration, not just execution.

🔄 What I Learned

You don’t need to be a programmer to build useful automation. You need clarity, curiosity, and courage.
Python is an incredibly versatile tool for system-level test automation, especially when your scenarios go beyond the browser.
Copilot or any GenAI tools are great partners. They don’t replace thinking, they accelerate exploration.
The best automation is born from test thinking, not just code execution.

Final Words

This experiment wasn’t about Python, Playwright, or Copilot.

It was about proving to myself that as a tester, I can explore, learn, and create value, without waiting for a perfect tool or a perfect plan.

So next time you hit a “we can’t automate this” scenario, ask yourself:
Is that the tool talking, or the tester in you hesitating?

Because at the end of the day… tools don’t test. Testers do.

If you found this helpful, stay connected with Life of QA for more real-world testing experiences, tips, and lessons from the journey!