Several years ago, Andrew was working in tech support.
No computer science degree. No formal engineering background. No traditional “developer” path.
Today, he works in QA automation and AI-driven testing practices at LoopQA.
But the part of his story that stood out most to me wasn’t the tools.
It was how he got his first shot.
At the time, Andrew was working at a company where the QA automation role had reportedly been sitting open for more than six months.
The hiring manager wanted someone with strong automation experience. The business didn’t necessarily want to pay for senior-level talent. The recruiter was stuck somewhere in the middle trying to bridge a difficult conversation.
Meanwhile, Andrew was sitting in customer support.
And technically? He met almost none of the listed requirements.
The 50-Click Problem
Part of Andrew’s support role involved helping customers set up websites using a site builder.
Every call required manual clicks while the customer sat on the phone waiting.
Slow. Repetitive. Easy to mess up.
So instead of just tolerating the process, Andrew decided to experiment.
He taught himself enough Selenium automation to build a script that could take a customer’s account number, execute the setup flow in the background, generate the website, and email the finished URL to the customer automatically.
What used to take an extended live support interaction now took less than 1 minute.
Then he showed it to the hiring manager.
That project ultimately helped him land the QA automation role.
Not because he suddenly became a senior engineer overnight.
But because he demonstrated curiosity, initiative, and the ability to solve a real operational problem. The engineering team already had automation infrastructure and two SDETs in place: they didn’t necessarily need a “perfect” engineer. They needed someone capable of learning quickly and contributing.
The req had sat open for months. Andrew ended up solving the stalemate.
What Stood Out To Me
There are a few reasons this story stuck with me.
First, it’s a reminder that some of the strongest candidates don’t always come from traditional pipelines.
Andrew came from support.
But I believe that support work gave him a surprisingly useful foundation for QA:
- troubleshooting
- understanding user behavior
- navigating ambiguity
- identifying friction points
- thinking through edge cases
- communicating clearly under pressure
Those skills translate into quality engineering more than people sometimes realize.
Second, the story reflects a hiring challenge I still see today.
Companies often want candidates who already have everything:
- automation experience
- coding ability
- framework knowledge
- tooling familiarity
- product intuition
- communication skills
- domain expertise
But many people capable of growing into those roles are filtered out before they ever get the chance.
In Andrew’s case, the thing that separated him wasn’t a perfect resume.
It was proof.
A Better Way To Think About Transitioning Into QA Automation
One thing Andrew said during our conversation really stood out:
“The current QA automation work I’m doing now is actually closer to manual testing than general software development. Same mindset, just scripted instead of clicked.”
That’s interesting.
Based off what I’ve seen, a lot of manual testers or adjacent tech professionals assume they need to completely reinvent themselves to move into automation.
But the reality is that many already possess the most important starting point:
They know how to think about quality.
They know how systems break.
They know how users behave.
They know how to reproduce issues.
The technical layer matters, of course.
But Andrew’s path wasn’t built by disappearing for a year to become a computer science expert.
It started with automating a real-world problem directly in front of him.
AI Is Lowering The Barrier To Experimentation
Another major part of our conversation centered around AI-assisted development and testing.
Andrew openly admitted he wasn’t an early AI adopter.
In fact, some of the early tooling was almost unusable for the older scripting language he was learning at the time.
But over time, his workflow evolved heavily toward AI-assisted development.
One idea from the conversation that I think is particularly important for testers trying to transition:
You do not need to start by building complex applications from scratch.
Andrew’s recommendation was much more practical.
Take an existing manual test.
Open VS Code.
Open an AI coding assistant.
Paste the test steps in.
Ask the AI to help automate the workflow using Playwright or Cypress.
Then iterate.
That advice feels far more approachable for a lot of people than the traditional:
“Go spend six months building calculator apps.”
And it aligns with where the industry is heading.
The people succeeding in modern QA aren’t the people memorizing the most syntax.
They’re the people learning how to:
- think critically
- validate behavior
- understand systems
- identify risk
- collaborate with AI effectively
- and continuously adapt
Drive The AI: Don’t Let The AI Drive You
One phrase Andrew repeated from his mentor, Ben, stuck with me:
“Drive the AI. Don’t let the AI drive you.”
AI can absolutely accelerate learning and implementation.
But blindly accepting generated output without understanding what’s happening underneath is still dangerous.
Andrew and I talked about how easy it is right now for people to generate large amounts of code they don’t fully understand.
And in QA specifically, that can create a different kind of problem:
A massive pile of automated tests with very little signal.
Green checks everywhere.
But not necessarily better quality.
The people who stand out are still the ones capable of asking:
- What did the AI miss?
- What assumptions are being made?
- What edge cases matter?
- What actually provides value?
Final Thought
What I appreciated most about Andrew’s story is that it wasn’t framed as some overnight transformation.
He wasn’t trying to become a “10x engineer.”
He identified a painful workflow.
He got curious.
He learned enough to improve it.
And he used that work to create an opportunity for himself.
I think a lot of people trying to either get back to work or transition into QA automation/AI-assisted testing underestimate how powerful that approach still is.
Not everyone will have the perfect resume.
But there’s still enormous value in demonstrating initiative, solving real problems, and showing people how you think.
Sometimes that matters more than checking every box on the job description.
Special thanks to Andrew Rogers for taking the time to share his story and perspective. He currently works at LoopQA, where he continues exploring modern testing workflows, AI-assisted development, and automation strategy.