Interview Insights · QA Tester
Why Most QA Tester Candidates Can't Defend Their Own Numbers
Quick summary — QA metrics
A number you cannot explain does more damage than no number at all, because it makes me doubt the rest of the resume. Hiring guides tell candidates to quantify achievements, so QA resumes fill with test case counts, defect counts and percentages. The problem is that many of these numbers were estimated, copied from a team report or never calculated at all. In the interview I ask where the number came from, what the formula was, over what period, and what your part was. If you can answer those four, any number becomes a strength.
In this guide you will learn:
- The four questions interviewers ask about any QA number
- Correct formulas for defect leakage, DRE and pass rate
- How to defend a time-saved claim with before and after data
- SQL queries to pull your own metrics from a defect table
- How to rewrite weak numbers so they survive follow-ups
SECTION 01The four questions every QA number must survive
When I see a number on a QA resume, I am not checking whether it is big. I am checking whether you understand it. That takes four questions: where did it come from, how was it calculated, over what period, and what was your part. If any of these get a vague answer, the number starts to look decorative.
The examples in this section are illustrations. Your own numbers will be different, and smaller honest numbers are completely fine. A fresher who says 'I logged 23 defects in my capstone project and 19 were accepted' sounds more credible than one who claims hundreds with no detail.
| Resume number | Question I ask | Weak answer | Strong answer |
|---|---|---|---|
| Executed 600 test cases | Over what period, and were they unique? | Around that many, I think | Across 4 regression cycles, about 150 unique cases |
| Logged 140 defects | How many were accepted as valid? | All of them were bugs | Most accepted; about a tenth rejected as duplicates |
| Reduced regression time by 40% | From how long to how long? | It became much faster | From about 2 days manual to about 1.2 days with automation |
| Achieved 90% coverage | Coverage of what? | Of the application | Requirements coverage: test cases mapped to stories |
Me: You wrote 'reduced regression time by 40%'.
How long did regression take before?
Candidate: It was taking a lot of time.
Me: Roughly how many hours or days?
Candidate: I am not exactly sure. Our lead calculated it.
Me: What did you personally automate?
Candidate: Some login and search cases.
(The number may be true for the team, but it is not
defensible as the candidate's own achievement.)Me: You wrote 'reduced regression time by 40%'.
How long did regression take before?
Candidate: Manual regression for the web app took about
two working days per release. I automated the 60 most
repeated cases in Selenium, and the team still ran the
rest manually. After that, a cycle took about a day and
a bit, so roughly 40% less. I measured it over three
releases, using the time logged in our test management
tool. The automation itself took me most of a sprint.The strong answer even mentions the cost: building the automation took most of a sprint. Mentioning the cost makes the saving more believable, not less, because real improvements always have one.
SECTION 02QA metric formulas you must be able to explain
Some numbers come up again and again in QA interviews: pass rate, defect leakage, defect removal efficiency, defect rejection rate and requirements coverage. If you put one of these on your resume, or even mention it in an answer, expect to be asked for the formula. Knowing the denominator is what most people forget.
The formulas below are the commonly used definitions. Some teams tweak them, for example by counting only high-severity production defects for leakage. If your team did that, say so; it shows you actually worked with the metric.
| Metric | Formula | Example (illustrative) | What it tells you |
|---|---|---|---|
| Test pass rate | Passed tests ÷ executed tests × 100 | 171 of 180 passed = 95% | Health of a build, not quality of testing |
| Defect leakage | Production defects ÷ (pre-release + production defects) × 100 | 6 ÷ (114 + 6) = 5% | How many bugs escaped testing |
| Defect removal efficiency | Pre-release defects ÷ (pre-release + production defects) × 100 | 114 ÷ 120 = 95% | How much testing caught before release |
| Defect rejection rate | Rejected defects ÷ total defects logged × 100 | 8 of 80 rejected = 10% | Quality of your bug reports |
RELEASE 3.2 (illustrative data)
Defects found in system + UAT testing: 114
Defects reported in production (30 days): 6
Total defects: 120
Defect leakage = 6 / 120 x 100 = 5.0 %
DRE = 114 / 120 x 100 = 95.0 %
(Leakage + DRE always add up to 100 % with this definition.)
Test cases executed in final cycle: 180
Passed: 171 Failed: 6 Blocked: 3
Pass rate = 171 / 180 x 100 = 95.0 %
Blocked tests are executed? Decide and state it.
Here: blocked counted as executed but not passed."For leakage I used production defects divided by all
defects for that release, counting production issues
reported in the first 30 days after go-live. That window
was our team's choice.
I would not use pass rate to claim good testing, though.
A 95% pass rate just means the build was fairly stable.
Leakage tells you more about how well testing worked,
because it measures what we missed."The comment about pass rate is worth practising. Many candidates present a high pass rate as proof of good testing. It is actually more about the build. A tester who points that out shows they understand what metrics mean, not just how to compute them.
SECTION 03Pulling your own numbers with SQL and tool reports
The best way to defend a number is to have calculated it yourself. Most defect trackers can export to a spreadsheet, and many teams also have defect data in a database or reporting tool. If you can write a simple SQL query to count defects by status, severity and phase, you can produce honest numbers for your resume and explain them confidently.
Build a small defect table from your own project and query it, so your resume numbers come from real data rather than memory. Then book a mock interview with an Uncodemy trainer and defend those numbers out loud; it is the fastest way to find the weak ones.
| Number you want | Where it lives | How to get it | Watch out for |
|---|---|---|---|
| Defects you logged | Defect tracker filter by reporter | Filter or GROUP BY reporter | Duplicates and rejected bugs |
| Accepted vs rejected | Status or resolution field | COUNT by resolution | Bugs still open at release |
| Leakage per release | Phase found field | Production vs pre-release counts | Agree the production time window |
| Regression time | Test tool cycle logs or timesheets | Compare cycle durations | Different scope across cycles |
-- defects(id, release, reporter, severity, status,
-- resolution, found_in) found_in: 'SIT','UAT','PROD'
-- 1. My defects and how many were accepted
SELECT resolution, COUNT(*) AS total
FROM defects
WHERE reporter = 'priya.qa'
GROUP BY resolution;
-- 2. Leakage and DRE per release
SELECT release,
SUM(CASE WHEN found_in = 'PROD' THEN 1 ELSE 0 END) AS prod_defects,
COUNT(*) AS all_defects,
ROUND(100.0 * SUM(CASE WHEN found_in = 'PROD' THEN 1 ELSE 0 END)
/ COUNT(*), 1) AS leakage_pct,
ROUND(100.0 * SUM(CASE WHEN found_in <> 'PROD' THEN 1 ELSE 0 END)
/ COUNT(*), 1) AS dre_pct
FROM defects
GROUP BY release
ORDER BY release;If you only have an export, a spreadsheet works too.
Columns: A=ID B=Release C=Reporter D=Status
E=Resolution F=FoundIn
Defects I logged:
=COUNTIF(C:C, "priya.qa")
Accepted (resolution Fixed or Done) that I logged:
=COUNTIFS(C:C,"priya.qa",E:E,"Fixed")
+COUNTIFS(C:C,"priya.qa",E:E,"Done")
Production defects for release 3.2:
=COUNTIFS(B:B,"3.2",F:F,"PROD")
Leakage % for 3.2 (put total in H2, prod in H3):
=ROUND(H3/H2*100, 1)Using 100.0 instead of 100 in the SQL matters. In many databases, dividing two integers gives an integer, so a leakage of 5% would show as 0. Mentioning that detail in an interview shows you have actually run the query.
SECTION 04Worksheet: make every resume number defensible
Run each number on your resume through this worksheet. If you cannot complete it, change the number to one you can defend, or describe the achievement without a number.
RESUME NUMBER: ________________________________
Source (tool, report, own count): ________________
Formula (numerator / denominator): ________________
Time period (sprint, release, months): _______________
My share vs team share: ________________
What it changed for the project: ________________
What it cost (time, effort): ________________
Can I explain all six in 45 seconds? Y / N
If N -> rewrite the bullet.BEFORE: Logged 140+ critical defects.
AFTER: Logged 48 defects in the payments module across two
releases; 43 accepted, including 5 high-severity
issues in refund calculation.
BEFORE: Achieved 100% test coverage.
AFTER: Mapped test cases to all 32 user stories in the
sprint scope (requirements coverage).
BEFORE: Improved quality by 50%.
AFTER: (Remove. 'Quality' has no formula here.)
All AFTER figures are examples - use your own.ASK YOURSELF THESE FOR EVERY NUMBER
1. Where exactly did this number come from?
2. What was the denominator?
3. Over what period?
4. Was it mine or the team's?
5. What would make this number misleading?
6. What did we do differently because of it?
Question 5 is the one strong candidates answer well.SECTION 05Habits for using numbers without getting caught out
Numbers are powerful when they are honest, specific and explained.
- Prefer small and exact — '43 of 48 defects accepted' is more convincing than '140+ defects', because it invites trust rather than doubt.
- Always know the denominator — Every percentage hides a 'percent of what'. Say it before the interviewer asks.
- Separate yours from the team's — Credit the team for team numbers and describe your own contribution clearly.
- Know a metric's weakness — Being able to say why pass rate can mislead shows deeper understanding than the number itself.
- Remove numbers you cannot source — A bullet without a number is better than a number that collapses under one question.
SECTION 06Interview Q&A — QA metrics
Q1What is defect leakage and how do you calculate it?
Defect leakage is the share of defects that escaped testing and were found in production. A common formula is production defects divided by the total of pre-release and production defects for that release, times 100. Teams should agree the production time window, for example the first month after release.
Q2What is defect removal efficiency?
Defect removal efficiency measures how many defects testing caught before release. It is pre-release defects divided by total defects, including those found later in production, times 100. With that definition, DRE and defect leakage add up to 100%.
Q3Is a high test pass rate a sign of good testing?
Not by itself. A high pass rate mainly shows the build is stable for the tests that were run. If the tests are shallow, the pass rate can be high while serious bugs remain. Leakage and the quality of defects found tell you more about testing effectiveness.
Q4How would you prove a claim that you reduced regression time?
I would give the before and after durations, how they were measured, over how many cycles, and what I changed, such as automating the most repeated cases. I would also mention what remained manual and what the automation effort cost, so the claim is realistic.
Q5What is defect rejection rate and why does it matter?
It is rejected defects divided by total defects logged, times 100. Rejections include duplicates, not-a-bug and cannot-reproduce cases. A high rate suggests unclear bug reports or misunderstood requirements, so a tester should track and reduce it.
SECTION 07Test yourself — QA metrics quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
Should I put numbers on a QA tester resume?
Yes, if you can explain them. Good numbers include defects logged and accepted, modules covered, cases automated and time saved, each with a source and period. Remove any number you cannot calculate or defend in an interview.
What QA metrics are asked in interviews?
Common ones are pass rate, defect leakage, defect removal efficiency, defect rejection rate, defect density, requirements coverage and automation coverage. Interviewers usually ask for the formula and what the metric actually tells the team.
How do I calculate defect density?
Defect density is the number of confirmed defects divided by the size of the software, often measured in thousand lines of code or in function points or modules. Teams use it to compare modules, so it only makes sense with a consistent size measure.
What if my metrics came from a team report?
Say so honestly and describe your part. For example, 'the team's leakage for that release was around 5%, and I owned testing for the payments module, where no defects leaked'. Honesty about ownership increases trust.
How can a fresher show numbers without job experience?
Use numbers from projects or practice testing: test cases written for a demo app, defects logged in a capstone project and how many were valid, or cases you automated. Small, real numbers are far better than large invented ones.
Where can I practise QA Tester interview answers with expert feedback?
Yes. Uncodemy's Software Testing Training Course in Noida (classroom and online) includes live projects, one-to-one mock interviews and resume reviews, so you practise QA Tester interview answers with trainer feedback before the real interview. You can book a free demo class from this page to see how the sessions work.
SECTION 09Related reads
Classroom & online · Noida
Build numbers you can defend in any interview
Our Software Testing Training Course covers QA metrics, defect tracking and SQL for testers on live projects, so the numbers on your resume come from your own work.
Talk to a counsellor for current fees- QA metrics and reporting
- Defect tracking tools
- SQL for testers
- Resume and mock reviews