Lessons from a QA professional navigating the job market for the first time in 12 years.
When you’ve spent 12 years at the same company, you don’t expect your next challenge to be writing a resume.
But that was the reality for Rebekah.
After spending more than a decade helping build and grow the QA function at a small software company serving government and enterprise customers, her entire department was eliminated during a reduction in force. Suddenly, she found herself navigating a job market she hadn’t experienced in over ten years.
“The market has changed” is something we hear all the time.
Talking with Rebekah reminded me how it’s changed.
The first question she kept hearing
One trend stood out almost immediately.
“Do you have automation experience?”
Although Rebekah had spent years advocating for automation internally, her previous company wasn’t in a position to implement it. Like many organizations running older infrastructure, automation initiatives often took a back seat to supporting existing systems and customer needs.
That created an interesting challenge.
She had years of experience designing test cases, validating complex workflows, and thinking critically about software quality but because much of her work was manual, she often felt recruiters placed her into the “manual tester” bucket before learning everything else she had to offer.
Rather than becoming frustrated, she treated it like any other problem she’d solve in QA.
She started learning.
Closing the automation gap
As she researched the market, one tool kept appearing: Playwright.
Instead of simply completing online courses, she wanted to build something she could actually use.
She began reading the documentation, using Claude to explain concepts from the perspective of an experienced manual tester, and planning a small automation project around her church’s member portal.
What struck me wasn’t the technology.
It was her mindset.
She realized she already knew how to identify risk, design test cases, think through edge cases, and validate expected behaviour. Those skills hadn’t changed.
The gap wasn’t learning how to test.
The gap was learning stuff like the syntax to automate what she already knew how to do.
That’s a much smaller leap than many experienced manual testers think.
Then she challenged her own job title
The biggest takeaway from our conversation had nothing to do with Playwright.
It was how she reframed her experience.
As manual testing opportunities became harder to find, she started asking herself a different question:
What do I actually do every day besides test?
The answers surprised her.
She had coordinated releases.
Worked with support teams.
Partnered with engineering.
Reviewed requirements.
Pushed back on features that didn’t make sense from the customer’s perspective.
Helped educate teams on how real users would interact with the product.
That’s when she realized she’d been doing pieces of Business Analysis and Product work for years.
One analogy she said was:
“You walk every day, but if someone asked what you do every day, you probably wouldn’t think to mention walking because it’s so automatic.”
Experienced manual testers often do the same thing.
The work becomes second nature, so they forget to talk about it.
Yet those “automatic” responsibilities are often some of the most valuable experience they have.
Manual testers don’t just execute test cases.
They understand how products work.
More importantly, they understand how customers use them.
That perspective is valuable whether your title says QA Engineer, Business Analyst, Product Owner, or something else entirely.
What about metrics?
One challenge Rebekah raised is something I hear from experienced QA professionals all the time.
“What if I don’t have numbers?”
Many manual testers don’t own dashboards or individual KPIs. Bug counts, release quality, and production metrics are often tracked at the team level, making it difficult to claim individual accomplishments.
Instead of forcing numbers that don’t exist, focus on the story.
Explain the problems you solved.
Describe the risks you prevented.
Highlight the cross-functional work you contributed to.
Context is often more valuable than an isolated metric.
Advice for other manual testers
Before we wrapped up, I asked what advice she’d give to someone in a similar position.
Her recommendations were refreshingly practical.
- Learn enough automation to understand today’s tools. Build a small project instead of only taking courses.
- Take inventory of everything you actually do, not just the tasks listed in your job description.
- Don’t let your current title define the opportunities you pursue. Your experience may already overlap with Business Analysis, Product, or other customer-focused roles.
- Build your network before you need it. Rebekah had intentionally stayed connected with former colleagues over the years, which made reaching out during her job search much easier.
- And perhaps most importantly, don’t be afraid to ask for help. As someone who spent years helping others, she admitted that becoming the person asking for support was one of the hardest parts of the transition.
Final thoughts
The QA market continues to evolve, and there’s no denying that automation skills have become increasingly important.
But my biggest takeaway from this conversation wasn’t that manual testers need to become automation engineers.
It was that many experienced manual testers have been building product knowledge, customer empathy, business analysis skills, and cross-functional experience for years. Those strengths don’t disappear just because the market changes: they simply need to be recognized, communicated, and paired with a willingness to keep learning.
A sincere thank you to Rebekah H for sharing her journey. I appreciate her willingness to let others learn from her experience, and I hope her story helps other QA professionals recognize the value they’ve already built while continuing to invest in what’s next.
Two local communities she encourages joining: