Hiring a functional QA consultant: questions that expose theatre
If you are buying QA help, a tool list tells you very little. These are the five questions I would ask a functional QA consultant, and what good and bad answers sound like.
Most interviews for a QA consultant test the wrong thing. The buyer reads a CV with fifteen tool names, asks about each, and hires whoever has used the most. A few months later there are more test cases and a busier dashboard, and nobody is more confident that Friday’s release is safe. That is coverage theatre: activity that looks like assurance.
I have sat on both sides of this table. As a Test Practice Manager I interviewed QA engineers. As a consultant I am the one being interviewed. The questions below are the ones I would ask if I were buying, and the ones I hope to be asked. Each aims at the same thing: does this person think about users and the release decision, or about test activity?
What a functional QA consultant is for
A functional QA consultant is hired for judgement about whether the product does what its users and the business need, and for the ability to make that judgement visible to the people who decide on a release. Tools serve that, and a competent tester picks up a new one in weeks. The judgement takes years, so the interview should spend its time there.
Before you interview anyone, write down the problem you want solved. “UAT keeps failing” or “we find out after we ship” is a brief a consultant can answer. “We need QA resource” is an invitation to sell you activity.
Five interview questions to ask a QA consultant
| Ask | A strong answer | A weak answer |
|---|---|---|
| How do you agree “done” with Product? | Acceptance in user language, who accepts risk, who owns the release call | Test phases, exit criteria and pass rates, a tool workflow |
| Tell me about a defect or story of yours that changed a user journey | Names the user, what they could not do, what it meant for the business and what changed | A clever technical bug with no user in it, or a count of defects raised |
| What would you refuse to automate first? | Journeys still changing, anything without a clear expected result, and what they would check by hand meanwhile | “Everything can be automated”, or a framework pitch before asking what the product does |
| How do you hand over when you leave? | Artefacts with named internal owners, and a period where your team leads and they review | “I document everything”, or surprise at the question |
| Where does AI fit in your work? | Drafts and scaffolding that a person verifies against the running system | Testing that runs itself, or a refusal to touch AI at all |
What good and bad answers sound like
Done. This question matters most. A consultant who cannot explain how “done” is agreed will test against a private idea of it, and you will find out in UAT. Listen for acceptance criteria Product can sign, for the word “risk”, and for a plain statement that the release decision belongs to Product and Engineering. A tester who wants to own that decision alone is building a gate.
- Weak: “We define entry and exit criteria for each test phase, track execution in the test management tool and report the pass rate daily.”
- Why: it describes activity. It never says who accepts the product or what would stop a release.
- Strong: “Before the sprint I sit with the product owner and rewrite each criterion as something a user can observe. Then I ask whether they would ship if only those passed. If they hesitate, we have not finished defining done.”
- Why: acceptance is in user language, a named person owns it, and the gap is found before any testing starts.
A defect that changed a journey. This is a request for evidence. Listen for empathy and business framing: who was affected, what they were trying to do, what it cost. Tool names without outcomes are decoration. I would follow up by asking what they decided not to raise as a defect, and why. Someone with judgement has an answer, because some findings are better raised as a question or a story.
What they refuse to automate. It is awkward on purpose for anyone selling a framework. Automation earns its keep where behaviour is stable and the expected result is clear. A consultant who leads with it often skips the messy functional work that reduces surprise: reading the story, questioning it, walking the journey on a real device. The result is a green pipeline on top of a broken journey.
Handover. This tells you whether you are buying capability or renting activity. If the practice collapses when the consultant leaves, you rented. A good answer includes what they will need from you: a named person to hand each artefact to.
AI. There are two bad answers. One is enthusiasm with no account of where a human checks the output. The other is blanket refusal. I use AI to draft API checks and performance scenarios, and I verify each one against the running system, as I explain in AI in QA without fake confidence. A good answer keeps judgement about users and business risk with a person.
Ask the consultant for work samples
Answers can be rehearsed. Artefacts are harder to fake. Ask for a defect report and a release readiness note they wrote, with client details removed, and read them as the intended audience would. Can a product owner tell from the defect title what broke and for whom? Can you tell from the note whether to ship?
Then give them a real story from your backlog, with anything sensitive removed, and ask what they would want to know before testing it. Strong candidates ask about users, acceptance, data and environments before they mention a tool.
Mistakes buyers make when interviewing QA consultants
Hiring for fluency. Consultants talk for a living. Being articulate about process is no evidence of judgement, which is why the work samples and the backlog story count for more than the conversation.
Matching the tool stack. A good functional tester moves between JIRA and Azure DevOps, or TestRail and Zephyr, in days. Domain understanding and judgement do not transfer that fast.
“We need automation, not a functional tester.” Sometimes true. But if stories arrive untestable and UAT fails on things nobody agreed, automation will check the wrong behaviour faster. Decide which problem you have before choosing the skill.
Hiring for agreement. A consultant who agrees with everything in the interview will agree with the release date too. Ask about a release they recommended holding and what they put in front of the people deciding.
A consultant chosen this way will sometimes tell you things you would prefer not to hear, in a note short enough that you cannot avoid reading it. That is the service. The other kind produces a larger test count and the same surprises in production.
Questions I get asked
What does a functional QA consultant do?
A functional QA consultant checks whether a product does what its users and the business need, and turns the result into something a release decision can rest on. In practice that means questioning stories before they are built, testing journeys end to end across web, mobile and APIs, writing defects Product can act on, supporting UAT and reporting readiness in plain language. They usually join a team for a fixed period and should leave the practice stronger.
What questions should I ask when hiring a QA consultant?
Ask how they agree “done” with Product, for an example of a defect that changed a user journey, what they would refuse to automate first, how they hand over when they leave and where AI fits in their work. Then ask to see an anonymised defect and readiness note. Strong answers talk about users, risk and who decides. Weak ones list tools and counts.
Should a QA consultant know test automation?
They should understand it well enough to say what is worth automating and what is not, and to work alongside the engineers who maintain it. Whether they need to build frameworks depends on your problem. If releases surprise you because requirements are vague or journeys go untested, functional judgement comes first. Automation then guards behaviour the team already understands.
Filed under Embedded QA and consulting. Terms: Embedded QA, Functional testing.
