Senior Manual QA — Manual QA interview questions

You join a team with no test process at all. What do you do in the first month?

First find out where quality actually hurts: talk to support, read the last three months of incidents, ask developers what they are afraid to touch. Then fix the cheapest thing with the biggest effect, usually a smoke suite on the critical path plus a bug workflow people follow. Writing a test strategy document in week one is the classic mistake — nobody reads it, and you have not earned the credibility for it yet.

How do you justify QA headcount to a manager who sees testing as a cost?

You stop arguing about coverage and start showing what escaped. Track defects found after release, what they cost in support time, hotfixes, and lost customers, and compare with what it costs to catch them earlier. The argument that wins is not "we need more testers", it is "here is what shipping broken cost us last quarter, and here is what we would spend to prevent most of it".

What would make you argue against automating a test?

When the feature is still changing, because you would maintain the test more than it protects you. When the check is cheap for a human and expensive for a machine, like visual judgement or usability. When the test is inherently flaky — timing, third parties, real payments — since a red build nobody trusts is worse than no build. Automation pays off on stable, repetitive, high-value paths, not on everything.

A critical bug reached production. How do you run the follow-up?

Blameless, and about the mechanism rather than the person. Establish the timeline, separate the trigger from the reason it got through, and ask why every layer missed it — requirements, review, tests, environment. The output is a small number of owned changes, not a resolution to "be more careful". If the same class of bug escaped twice, the process is the defect, not the tester.

How do you decide what quality metrics to report, and which ones lie?

Useful metrics answer a question someone will act on: escaped defects, time to detect, flakiness rate, coverage of critical flows. Number of test cases and number of bugs found are the classic misleading ones, because both reward writing more of something rather than finding what matters — and both go up when quality gets worse. Any metric you report will be optimised, so only report ones you would be happy to see gamed.

Product wants to cut QA from the sprint to hit a date. How do you respond?

Not with a refusal, with a trade. Name what specifically will not be checked and what could reach users as a result, in their terms — revenue, support load, reputation. Offer a smaller scope you can genuinely cover instead of pretending the full one fits. The goal is that the decision is made with the risk visible; if they still ship, that is a legitimate business call and it is now documented.