.svg)
A conversation with Rahul Parwal, Test Specialist at ifm engineering and AI Chapter lead at Ministry of Testing, on why the loudest problem in software testing right now is not AI, it is noise.
The first four entries in Quality People came from inside a product team, a services consultancy, a fundamentals-first QA lead, and an AI governance function: Huy Tieu on harness engineering, Gastón Marichal on adoption, Fariz on fundamentals, and Maryna Didkovska on governance. This entry is a different kind of voice again: not a builder, a consultant, or a governance lead, but a full-time practicing tester whose entire public platform is built on one argument, that testing has a noise problem, and most testers are optimizing for the wrong signal.
Rahul Parwal is a Test Specialist at ifm engineering, where he has spent more than seven years testing industrial automation and IoT systems. He leads the AI Chapter at Ministry of Testing, holds the Jerry Weinberg Testing Excellence Award, and won EuroSTAR's Best Tutorial award in 2025 after several years of conference proposal rejections. He also publishes a "failure resume", an unusual move in an industry that mostly shows its wins.
THE SHORT ANSWER
Rahul Parwal on filtering signal from noise in testing's AI moment, at a glance:
• The loudest, most damaging noise in testing right now is "AI will take your job." The signal underneath runs the other way: AI widens what a tester is allowed to attempt.
• Testers who filter signal well share three habits: high agency, clear thinking, and high disagreeability.
• Coding fell down the skill ranking because AI closes the implementation gap. The scarce resource is the idea and the judgment again, not the scripting.
• Real AI value looks like sharper testing, not faster output. Ask whether you are using AI as a mechanical amplifier or a cognitive one.
• Test case counts hide what exploratory testing reveals. Measure production issues, tester judgment, and what customers actually say instead.
The rest of this conversation covers his path into testing, why he makes his failures public, what he'd tell a tester who over-invested in scripting, and what he thinks separates a tester who survives the next five years from one who does not.
From The Tester Who Once "Had Nothing to Bring"
Asked to introduce himself beyond the LinkedIn headline, Rahul starts with the job itself. "I test industrial automation solutions, IoT, industrial protocols, and so on, at ifm. That's my actual job, and I've been doing it for over seven years now. I still find it interesting and intellectually challenging. Everything else that reads in my public profile came out of my passion for craft, communities, and consistency."
The public profile started from nothing. "During the COVID phase in 2020, I joined The Test Chat WhatsApp group, which was maybe 40 testers arguing about the craft until 1 in the morning. I had nothing to bring. I'd never spoken anywhere, never written anything anyone read. The group kept getting bigger, and it soon had some of the best minds in the testing space. I used to take notes and draft summaries back in the group. From there, I started to write short posts and articles. Then I collaborated with Ajay Balamurugadas on various ebooks and talks. Seven years later, I am still in that loop. Now, I also lead the AI Chapter at Ministry of Testing myself, mostly pushing people onto stages before they think they've earned it."
The detail that surprises people who follow his work closely has nothing to do with testing. "I'm a productivity geek. I taught myself touch typing. I learn the shortcuts for most tools I use, and I get irritable when something forces me back to the mouse. I even use pomodoro timers a lot these days. There's always some new tool I'm trialling or exploring."
Why He Makes His Failures Public
Rahul publishes a public failure resume, listing a live automation demo that failed in front of a customer's VP and years of EuroSTAR proposal rejections before he won Best Tutorial in 2025. In an industry built on polished wins, he treats that as a correction rather than an overshare.
"Fear of failing is what stops people before they start," he says. "Someone looks at a person with a few awards and assumes there was a clean growth trajectory. There usually isn't such a clean trajectory. I wanted to make my journey visible and give a sense of reality to all my readers. Social media runs on virtue signalling. People often ask me how I make everything work. The honest answer is that I don't, you just can't see the parts that didn't. My failure resume corrects that record."
He sees a compounding effect if enough people do the same. "If enough of us do it, people start things instead of waiting until they feel qualified, which is a wait that never ends. Nobody ever feels ready. If we stopped hiding this as a profession, more people would just begin, and we'd get more testers doing interesting work instead of watching other people do it."
Testing's Noise Problem, and the Three Habits That Cut Through It
Rahul's through-line, across his writing and his talks, is that software testing has a noise problem: tool hype, templates, buzzwords. Asked what the loudest source of that noise is right now, he does not hesitate.
The signal underneath, he argues, runs the opposite direction. "AI widens what a tester is allowed to attempt. My own job now includes work that wasn't open to a tester two years ago. I research a lot on Agentic AI and how to fuse it into our product development. I build agentic systems at work. Nobody handed me either of those, I found I could do them and started."
He names three habits that separate a tester who filters signal well from one who is drowning in noise:
Why Coding Fell Down the Skill Ranking
Rahul has argued publicly that coding is no longer the biggest skill for testers, with prompt engineering, test design, and exploring requirements ranking higher. Asked why, he points to what coding used to gate.
"Coding is no more a wall for your creativity. For years I have seen people with genuinely good ideas stall out because they couldn't write the code. Wrong language, unfamiliar framework, a platform they were not aware of. This implementation gap killed those ideas. AI closes that gap. So the scarce thing is back to being the idea, and execution."
To testers who spent years on Selenium or Playwright, he is careful not to write off that experience. "That work taught you how systems break, and nobody can take that. What I'd stop doing is treating the scripting itself as the differentiator."
His recommendation is to build a different layer of skill on top: "Learn agentic engineering instead. Context engineering. Evals and rubrics for grading non-deterministic output. Guardrails against prompt injection and hallucination. System design for putting tools and memory around a model." His read on where this leaves traditional scripting is direct: "Traditional software engineering as we practise it today has a short runway."
This is the same shift Katalon has been tracking across the series, from writing brittle scripts toward designing the systems that let AI agents work reliably, a theme covered in the series' definitional guide to agentic QA.
Managing AI Like a Junior Tester Who's Fast but Directionless
Rahul describes AI as "a partnering force, not a competing force," comparable to a junior tester: fast, eager, but without direction of its own. Asked what good management of that junior tester looks like in a real week, he reframes the usual human-in-the-loop model.
"The framing I like to use is AI in the loop, not human in the loop. The part most testers get wrong is feedback. They correct it in the chat, feel productive, but your correction dies as the session closes. Making it stick and working towards those smart systems is what I feel good management should reward."
He names two specific skills this requires: "Context engineering, keeping the context it works from properly maintained. AI evaluations, writing an eval so the same mistake gets caught by a check instead of by you."
That distinction matters because it is also how he separates real AI value from a good demo. He won an AI efficiency award at ifm, by his own account, but warns that most people use AI "to look good in a demo," optimizing for what he calls temporary dopamine rather than real improvement.
His test: "Ask yourself: are you using AI as a mechanical amplifier or a cognitive one? Mechanical means faster output. More code, more cases, more text, produced quicker. Cognitive means you think better and solve deeper than you could have alone done it a few years back. Most people are doing the first and reporting it as the second."
He proposes measuring the second thing instead of the first. "I'd personally recommend people stop measuring output entirely. Measure whether the testing got sharper. Did your quality gates get harder than the last release? Did testability improve, so the next release is easier to check than the last? Did AI open work that wasn't possible for your team before, or did it just speed up the work you were already doing? If the same team with the same AI finds risk it used to miss, that's real growth."
What Test Case Counts Hide
Rahul has written before about "test case addiction," comparing test case counts to counting cookies. Asked what that metric hides, he does not soften the comparison.
"Counting test cases is like counting cookies. The number goes up. Nobody tasted anything. All metrics come with a distortion problem. Measure test cases and you'll get more test cases, which sounds fine until you see how. One solid case breaks down into five thin ones. Cases appear for areas that never needed them. Effort moves to getting checks approved in review, away from the actual testing. This makes the dashboard climb numbers, but the real focus on quality drops."
What a fixed case cannot do is where exploratory testing earns its place. "A fixed case can only find what you already thought of. Exploratory testing finds the thing you didn't, the behaviour no one wrote down because no one knew to look for it yet."
His preferred replacements for the count: "Are production issues going down over releases? Can the tester tell you what they explored and what they're worried about? And the one I trust most: what are customers actually telling you, because quality is value to someone who matters."
As he puts it, "Software is a complex business. It's hard to figure out real value from counting things." That case for shifting weight toward hands-on, judgment-driven testing runs alongside Katalon's own guidance on where manual and exploratory testing still carry the load AI cannot.
The Ambassador's Job, and Three Questions That Cut Through a Demo
Rahul is an ambassador for six testing tool brands, by his own account, and says the arrangement only works because he tells vendors when a tool is average. Asked how he protects that credibility, he pushes back on the usual definition of the role.
"A lot of people get it wrong. People think that being an ambassador means talking about the tool and promoting it or marketing it to the community. I think being an ambassador means becoming a gateway between the tool and the community. This involves bringing in real community feedback, thoughts, and ideas back to the tool company. I get to tell them what the community really wants, what the real challenges are, and I think that's the real ambassadorship relationship that I have with the companies that have me as their ambassador. When a new tool is average, I can say to them that it's average, and the relationship still holds because honesty was always the deal."
For testers sitting through a vendor demo, he offers a car-buying analogy. "Picking a tool is like buying a car. The showroom model is spotless, the salesperson is lovely, and none of that survives your actual commute." He gives three questions that do most of the work:
- Show me where it breaks. What is it genuinely bad at?
- Hand me the keyboard, on my data, not your prepared example.
- What does it cost at scale, and what does it cost to walk away?
"A good vendor answers all three," he says. "A nervous one will change the subject."
What Community Gave Him That No Job Could
Rahul has grown up in testing communities, from the Test Chat WhatsApp group to Ministry of Testing, The Test Tribe, testing contests, and now one-on-one mentoring. Asked what community gave him that no job ever could, he points to something a title cannot carry.
"A job gives you a title inside one company. The day you leave, the title stays behind. Community gave me something a job could never: an identity that travels. People know my work in rooms I've never worked in, and that came from the community."
His clearest proof of that is EuroSTAR. "I didn't win Best Tutorial twice just on talent. I won it because testers outside my normal circles spent their own evenings tearing my material apart before I ever walked the big stage. People just did it, because that's what these communities do."
His case for the tester who is quietly lurking on the sidelines is direct. "Nobody has the time to sit and study your fears. Everyone is busy with their own. And your biggest fears are the locks sitting on your biggest dreams. The talk you aren't doing. The question you aren't asking. The introduction you aren't making. Show up anyway. Ask the dumb question. Nobody remembers the bad. The good will compound in the long run."
In His Own Words
Asked to finish the sentence "the kind of tester who won't survive the next five years is the one who," Rahul does not point to a missing skill. He points to a missing habit: visibility. Combined with everything else in this conversation, the through-line holds together. Fear of failing, fear of AI, fear of speaking up, all filtered out the same way, by trying the thing, stating the problem plainly, and putting the proof of work somewhere other people can find it.
Asked to finish the sentence "the kind of tester who won't survive the next five years is the one who," Rahul does not point to a missing skill. He points to a missing habit: visibility. Combined with everything else in this conversation, the through-line holds together. Fear of failing, fear of AI, fear of speaking up, all filtered out the same way, by trying the thing, stating the problem plainly, and putting the proof of work somewhere other people can find it.
If you are working through the same questions on your own team, the rest of the Quality People series is a good place to compare notes. You can follow Rahul's work on LinkedIn and at Rahul's Testing Titbits.
|
