Interview Insights · Software Tester
Why Every Software Tester Should Practice Explaining Their Dashboard Aloud
Quick summary — Tester dashboard
A QA dashboard is only useful when someone can explain what it means for the release. In interviews, testers often share a Jira or Excel dashboard and read it out: so many cases passed, so many bugs open. That proves you can open a tool. What I want is the next step: which numbers worry you, where the defects cluster, what blocked cases mean for coverage, and whether you would release. Practising that explanation aloud turns a screenshot into evidence of judgement.
In this guide you will learn:
- What I mean by a tester's dashboard and which panels matter
- How to explain execution metrics without just reading numbers
- The JQL queries behind common defect charts
- How to read trends like open versus closed defects
- A two-minute script for presenting your dashboard in an interview
SECTION 01What a tester's dashboard is, and what interviewers look for
For a software tester, 'dashboard' usually means one of two things: a test execution view, showing how many planned cases were run, passed, failed or blocked, and a defect view, showing bugs by severity, status, module and age. Teams build these in Jira dashboards, test management tools, Excel or Power BI. The tool does not matter much in an interview.
What matters is that you understand each panel well enough to answer 'so what?'. If I point at a number and ask why it matters, you should be able to connect it to coverage, risk or the release decision in a sentence or two.
| Panel | What it shows | Question I will ask | Strong answer direction |
|---|---|---|---|
| Execution status | Passed, failed, blocked, not run | Why are some cases blocked? | Name the blocker and the coverage it removes |
| Defects by severity | Open bugs split by Critical to Low | Which of these stops a release? | Point to open highs and their areas |
| Defects by module | Where bugs are concentrated | What does the cluster tell you? | Risky area that needs more regression |
| Defect ageing | How long bugs stay open | Why is this bug open so long? | Waiting on decision, dependency or low priority |
Interviewer: Walk me through your dashboard.
Candidate: Here total test cases are 200.
160 passed, 20 failed, 15 blocked, 5 not run.
In defects, 14 are open. 2 high, 8 medium, 4 low.
This chart shows defects by module.
Interviewer: So, would you release?
Candidate: Mostly cases are passed, so yes.Interviewer: Walk me through your dashboard.
Candidate: This is an example sprint view.
Of 200 planned cases, 15 are blocked because the
refund API is not deployed on staging. So refunds
are effectively untested, which matters more than
the pass count.
Both open high bugs are in payment: one double charge
on retry, one wrong GST rounding.
My recommendation would be no-go for payment changes
until those two are fixed and the refund cases run.Notice how the second candidate starts with the blocked cases, not the passed ones. A high pass rate can hide a big untested area. Explaining that is what makes a dashboard answer sound like a tester and not a reporter.
SECTION 02The JQL and formulas behind your QA charts
If you show a Jira dashboard, expect me to ask how a chart is built. Many candidates use a dashboard a lead created and cannot explain the filter behind it. Knowing the JQL shows you could build or fix the view yourself.
The same goes for metrics. If you mention defect leakage or pass rate, be ready to say the formula and what it can hide. Metrics are simple ratios, and their value lies in how you interpret them, not in the calculation itself.
| Metric | Formula | What it tells you | What it can hide |
|---|---|---|---|
| Pass rate | Passed / Executed x 100 | How much of what ran is working | Blocked and not-run cases |
| Execution progress | Executed / Planned x 100 | How far testing has reached | Whether the hardest cases are left |
| Defect leakage | Bugs found after release / Total bugs found x 100 | How many bugs escaped testing | Severity of the escaped bugs |
| Reopen rate | Reopened bugs / Fixed bugs x 100 | Quality of fixes and retests | Whether reopen reasons were unclear steps |
-- Open bugs by severity for the current sprint
project = SHOP AND issuetype = Bug
AND sprint in openSprints()
AND statusCategory != Done
ORDER BY priority DESC
-- High and critical bugs open more than 7 days
project = SHOP AND issuetype = Bug
AND priority in (Highest, High)
AND statusCategory != Done
AND created <= -7d
-- Bugs reopened during the last 30 days
project = SHOP AND issuetype = Bug
AND status CHANGED FROM Done TO Reopened AFTER -30d
Note: replace SHOP, the priority names and the
Reopened status with what your workflow uses.Sheet 'Execution' has a Status column (D2:D201)
with values Passed, Failed, Blocked, Not Run.
Passed =COUNTIF(D2:D201,"Passed")
Failed =COUNTIF(D2:D201,"Failed")
Blocked =COUNTIF(D2:D201,"Blocked")
Executed =COUNTIF(D2:D201,"Passed")+COUNTIF(D2:D201,"Failed")
Planned =COUNTA(D2:D201)
Pass rate =IFERROR(Passed_cell/Executed_cell,0)
Progress =IFERROR(Executed_cell/Planned_cell,0)
Format the last two as percentages.
Use a stacked bar of Passed, Failed, Blocked by module
to show where the blocked work sits.Be careful with how you define 'executed'. Some teams count blocked cases as executed and some do not. In an interview, simply say which definition your sheet uses. That one sentence prevents a confusing argument about percentages.
SECTION 03Explaining defect trends instead of single snapshots
A single day's numbers tell me very little. Trends tell me where the release is heading. The most useful trend chart for testers is open versus closed defects over the sprint, sometimes shown as a created versus resolved chart in Jira. When the open line keeps rising near the end of a sprint, quality is not stabilising.
When you explain a trend aloud, describe the shape, give a likely reason, and say what you would do about it. That three-part habit is what makes you sound like someone who uses dashboards to manage risk.
| Trend pattern | Likely reason | What it means | What I would do |
|---|---|---|---|
| New bugs rising late in sprint | Big feature merged late | Quality not stable yet | Push for a code freeze and focused regression |
| Resolved line flat for days | Developers busy elsewhere | Fix backlog growing | Raise in stand-up with severity data |
| Many bugs in one module | Complex or recently rewritten area | High-risk zone | Add regression and exploratory time there |
| Reopened bugs increasing | Rushed fixes or unclear steps | Retest cycles wasted | Improve repro steps and review fixes earlier |
"This is an example created-versus-resolved chart
for a two-week sprint.
For the first week both lines move together, so
bugs were being fixed about as fast as we found them.
After day eight the created line jumps. That matches
the day the new search filters were merged.
Since then, resolved has stayed flat, so the gap is
growing. I would raise this at stand-up, ask for the
filters to be frozen, and spend the extra test time on
search regression rather than new areas."OPEN DEFECTS BY MODULE AND SEVERITY (example layout)
Module | Critical | High | Medium | Low
----------|----------|------|--------|----
Login | 0 | 0 | 1 | 2
Search | 0 | 1 | 4 | 3
Cart | 0 | 0 | 2 | 1
Payment | 0 | 2 | 1 | 0
Spoken: "Search has the most bugs, but payment
worries me more, because both highs are there
and payment failures lose money directly."The module view is a good reminder that the biggest number is not always the biggest risk. Explaining why you rank payment above search, even with fewer bugs, shows real risk thinking.
SECTION 04Prepare a dashboard walkthrough you can give in two minutes
Build or recreate a small dashboard from a practice project, even in Excel, and use these sheets to prepare a spoken walkthrough. Use clearly labelled sample data if you have no real project data.
DASHBOARD WALKTHROUGH (2 minutes)
1. Context (15s) -> project, sprint or release, tool used
2. Coverage (25s) -> planned vs executed, blocked and why
3. Defects (25s) -> open by severity, where highs sit
4. Trend (25s) -> created vs resolved, what changed
5. Risk (15s) -> the one area that worries you most
6. Call (15s) -> go / no-go / go with listed risks
Rule: every number you say must be followed
by what it means.MINIMUM PANELS FOR A TESTER DASHBOARD
[ ] Execution status (passed, failed, blocked, not run)
[ ] Open defects by severity
[ ] Open defects by module or component
[ ] Created vs resolved trend for the sprint
[ ] Ageing list of high-severity open bugs
[ ] Filter or JQL written down for each panel
[ ] Clear note of how 'executed' is defined
[ ] Date and build number the data refers toQUESTIONS TO PRACTISE ALOUD
1. Why is the pass rate high but you still say no-go?
2. Which number on this dashboard can mislead people?
3. How did you build this chart? Show the filter.
4. What would you add to this dashboard?
5. Who looks at it, and what do they decide from it?
6. How often is it updated, and by whom?
7. What is defect leakage, and how would you track it?
Write a two-line answer for each before the interview.SECTION 05Habits that make a QA dashboard explanation convincing
These habits help whether you present in an interview or at a real release meeting.
- Lead with the conclusion — Start with 'I would not release payment yet' and then show the numbers that support it, so listeners know why they are looking.
- Explain blocked before passed — Untested areas are the hidden risk on any dashboard. Mention them first so they are not lost behind a good pass rate.
- Label sample data clearly — If your dashboard uses practice data, say so. Presenting example numbers as real production figures damages trust.
- Know each filter — Be able to show the JQL or formula behind any chart. It proves the dashboard is yours, not borrowed.
- Name the audience — Say who uses the dashboard, such as the lead at stand-up or the product owner at release, and what decision they make from it.
SECTION 06Interview Q&A — Tester dashboard
Q1Your pass rate is high but you recommend no-go. How do you justify that?
Pass rate only covers executed cases. If key areas are blocked or not run, or if open high-severity bugs sit in critical flows like payment, the release risk is high regardless of the percentage. I would show the blocked cases and the location of the high bugs to support the call.
Q2What is defect leakage and how do you measure it?
Defect leakage is the share of defects found after release compared with all defects found for that release. You divide post-release bugs by total bugs and multiply by 100. It shows how well testing caught issues, but you should also look at the severity of what leaked.
Q3Which metrics would you put on a QA dashboard for a sprint?
Execution status with blocked and not-run cases, open defects by severity and module, a created versus resolved trend, an ageing list of high bugs and possibly the reopen rate. Each panel should help someone decide something, such as where to focus testing or whether to release.
Q4How do you write a JQL query for open high-priority bugs in the current sprint?
Something like: project = KEY AND issuetype = Bug AND priority in (Highest, High) AND sprint in openSprints() AND statusCategory != Done. I would adjust the project key and priority names to match the team's Jira configuration.
Q5What does a rising reopen rate tell you?
It suggests fixes are not holding, often because of rushed changes, unclear reproduction steps or missing test data. I would review a few reopened bugs to find the pattern, then improve bug report detail or ask for developer-side checks before fixes come back to testing.
SECTION 07Test yourself — Tester dashboard quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
What should a QA test execution dashboard include?
At minimum: planned, executed, passed, failed, blocked and not-run cases, open defects by severity and module, a created versus resolved trend and a list of old high-severity bugs. The date and build number should be clearly shown.
How do I create a defect dashboard in Jira?
Create saved filters with JQL for the bugs you want to track, then add gadgets such as Filter Results, Pie Chart by priority, and Created vs Resolved Chart to a dashboard, each pointing at a filter. Share the dashboard with your team.
What are the important QA metrics for interviews?
Commonly discussed ones include pass rate, execution progress, defect density, defect leakage, reopen rate and defect ageing. More important than the formulas is explaining what each metric can hide and how you would act on it.
How do I explain a testing dashboard in an interview?
Start with context, then coverage including blocked cases, then open defects and where the serious ones are, then the trend, and end with a clear release recommendation. Follow every number with what it means.
Can I use Excel for a QA dashboard in my portfolio?
Yes. Excel with COUNTIF formulas and a few charts is enough to show your thinking. Label the data as sample or practice data, and be ready to explain how each number is calculated and what decision it supports.
Does Uncodemy help with Software Tester interview answers?
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 Software 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
Turn test results into clear release decisions
Our Software Testing Training Course covers test execution tracking, defect management in Jira and QA reporting, with practice presenting dashboards the way release meetings expect.
Talk to a counsellor for current fees- Jira and JQL practice
- Test reporting and metrics
- Mock release reviews
- Weekday & weekend batches