Interview Insights · Business Analyst
Why Every Business Analyst Should Practice Explaining Their Test Case Aloud
Quick summary — BA test cases
A test case you can explain aloud proves you understood the requirement, not just the template. When I ask a Business Analyst candidate to walk me through a test case they wrote, most read the steps in order. That tells me they can fill a spreadsheet. What I want to hear is the business rule the case protects, the data they chose and why, the boundary they tested, and what happens to the case when it fails. Saying this aloud before the interview is the only reliable way to find out whether you can.
In this guide you will learn:
- What a BA test case actually is and how it differs from a QA test case
- How to open your explanation with the rule, not the steps
- Why boundary values are the part interviewers probe hardest
- A traceability line that links every case back to a requirement
- A practice script and worksheet you can rehearse in ten minutes
SECTION 01What a Business Analyst means by a test case
In most teams, testers write detailed functional test cases and Business Analysts write or review UAT (user acceptance testing) test cases. A UAT case checks that a feature meets the business need described in the requirement, in language a business user can follow. It is less about clicking every field and more about proving a rule works for a real scenario.
That difference is exactly why interviewers ask about it. If you describe a BA test case the way a tester would, with every click listed, you sound like you have only seen the format. If you describe it as evidence that a requirement was met, you sound like the person the business will trust at sign-off.
| Aspect | QA functional test case | BA / UAT test case | What to stress aloud |
|---|---|---|---|
| Source | Functional spec, design | User story and acceptance criteria | Which story the case comes from |
| Language | Technical, field-level | Business terms the user knows | Why a business user can run it |
| Focus | Does each function work? | Does the rule meet the need? | The rule the case protects |
| Output | Defect for developers | Accept, reject or change request | What sign-off depends on it |
Interviewer: Walk me through a test case you wrote.
Candidate: So step one, user logs in. Step two, goes to
My Orders. Step three, clicks on the order. Step four,
clicks Request Refund. Step five, enters reason...
Expected result is refund is requested successfully.
(The interviewer still does not know what rule was tested.)Interviewer: Walk me through a test case you wrote.
Candidate: This case covers the refund rule from story
REF-12: customers can request a refund within 30 days of
delivery, and after that the button should be disabled.
I tested three orders: delivered 29 days ago, exactly 30
days ago, and 31 days ago. The first two should allow the
refund, the third should show 'Refund window closed'.
The 30-day order was the important one, because the story
did not say whether day 30 was included. I raised that with
the product owner before writing the case.The second answer is not longer because it has more steps. It is longer because it has more reasoning. It names the story, the rule, the data and the ambiguity the candidate resolved. That is four signals in under a minute.
SECTION 02Why boundaries and negative cases get the hardest questions
A happy-path case is easy to explain and easy to write, so it tells the interviewer very little. The follow-up questions almost always go to the edges: what happens on the last valid day, with a zero amount, with a user who has the wrong role, or with two rules that overlap. These are the places where requirements are most often unclear.
When you practise aloud, practise the edges first. If you can explain why you picked a boundary value and what the expected result was, you show that you think about the gaps in a requirement, which is the core of a Business Analyst's job.
| Rule in the story | Boundary to test | Negative case | Question you should have asked |
|---|---|---|---|
| Refund within 30 days | Day 30 exactly | Day 31 shows closed message | Is day 30 inclusive? Calendar or business days? |
| Free delivery over Rs 499 | Cart of exactly Rs 499 | Cart of Rs 498 charges fee | Is the limit before or after discount? |
| Manager approves leave over 3 days | Leave of exactly 3 days | Employee approves own leave | What if the manager is on leave? |
| OTP valid for 5 minutes | OTP used at 4:59 | OTP used at 5:01 rejected | How many retries before lock-out? |
ID | Story | Scenario | Test data | Expected result
-------|--------|--------------------------|-----------------------|-------------------------------
UAT-07 | DEL-04 | Cart just below limit | Cart Rs 498, no coupon| Delivery fee shown at checkout
UAT-08 | DEL-04 | Cart exactly at limit | Cart Rs 499, no coupon| Free delivery applied
UAT-09 | DEL-04 | Discount drops cart below| Cart Rs 520, coupon 50| Fee shown (limit after discount)
UAT-10 | DEL-04 | Cart above limit | Cart Rs 650 | Free delivery appliedFeature: Free delivery threshold
Scenario: Cart total after discount meets the threshold
Given a customer has items worth Rs 520 in the cart
And applies a coupon worth Rs 50
When the customer opens checkout
Then the payable total is Rs 470
And a delivery fee is added
Scenario: Cart total equals the threshold
Given a customer has items worth Rs 499 in the cart
When the customer opens checkout
Then no delivery fee is addedNotice UAT-09. It exists because the candidate asked whether the limit applies before or after the discount. That single case is the best thing to talk about in an interview, because it shows a decision that came from analysis, not from a template.
SECTION 03Traceability: the sentence that makes your test case credible
Every UAT case should trace back to a requirement, and every requirement should have at least one case. This is usually kept in a requirements traceability matrix (RTM). In interviews, a single sentence about traceability makes your answer sound like real project work rather than a classroom exercise.
You do not need a complicated tool to explain it. A spreadsheet with requirement IDs, case IDs and status is enough. What matters is that you can say what you did when a case failed, and how you knew which requirement was affected.
| RTM column | Example value | Why it exists | What to say in the interview |
|---|---|---|---|
| Requirement ID | REF-12 | Links to the user story | Every case I wrote started from a story ID |
| Test case IDs | UAT-21, UAT-22, UAT-23 | Shows coverage of the rule | This rule had three cases: before, at and after the limit |
| Status | 2 passed, 1 failed | Shows readiness for sign-off | We could not sign off REF-12 until UAT-23 passed |
| Defect / CR link | DEF-88 or CR-05 | Separates bugs from new needs | I decided whether it was a defect or a change request |
Req ID | Requirement summary | Cases | Status | Link
-------|--------------------------------|--------------------|---------------|-------
REF-12 | Refund allowed within 30 days | UAT-21, 22, 23 | 2 pass, 1 fail| DEF-88
REF-13 | Refund reason is mandatory | UAT-24, 25 | Pass | -
REF-14 | Refund over Rs 5000 needs check| UAT-26, 27 | Pass | -
DEL-04 | Free delivery over Rs 499 | UAT-07 to UAT-10 | 3 pass, 1 fail| CR-05UAT-10 failed: free delivery was applied before discount.
Question I asked: does the story say 'after discount'?
- If yes -> it is a DEFECT. The build does not match
the agreed rule. Log DEF, assign to dev.
- If no -> it is a CHANGE REQUEST. The build matches
the story, but the business now wants
something different. Log CR, re-estimate.
In our case the story was silent, so it became CR-05
and the story was updated with the clarified rule.The defect-or-change decision is one of the most useful things you can rehearse. Many candidates have never thought about it, and interviewers know it is a daily judgement call for a BA on a live project.
SECTION 04A ten-minute rehearsal kit for your test case
Pick one test case from your project, case study or practice assignment. Use these three tabs in order: the script gives you the structure, the drill makes you say it under time pressure, and the self-check catches the gaps you did not notice.
1. CONTEXT (10 s)
"This case is from story ___, which covers ___."
2. RULE (15 s)
"The business rule is ___. The limit is ___."
3. DATA (20 s)
"I used ___ because it sits just below / at / above
the limit."
4. QUESTION I RAISED (20 s)
"The story did not say ___, so I asked ___."
5. RESULT (15 s)
"It passed / failed. If failed: logged as defect or CR
because ___."
6. LINK (10 s)
"It is traced to ___ in our RTM."Ask a friend to read these after your script.
Answer each in under 30 seconds.
- Why did you choose that test data?
- What would you test if you had five more minutes?
- Who signed off this case?
- How is this different from what QA tested?
- What if the developer says it works as designed?
- Which case would you drop if time ran out, and why?
Mark any question where you paused for more than
five seconds. Rehearse that answer again tomorrow.After recording yourself, tick each item:
[ ] I named the user story or requirement ID
[ ] I stated the rule in one plain sentence
[ ] I explained at least one boundary value
[ ] I mentioned one negative case
[ ] I described a question I raised with the business
[ ] I said what happened when it passed or failed
[ ] I used business words, not only screen names
[ ] I finished in under two minutes
Fewer than six ticks: rewrite the script and record again.SECTION 05Habits that make BA test case answers sound real
These small habits separate a candidate who has written UAT cases from one who has only read about them.
- Start with the story ID — Opening with 'this case is from story REF-12' immediately tells the interviewer you work from requirements, not from screens.
- Say the number out loud — Boundaries are numbers: 30 days, Rs 499, 5 minutes. Saying the exact value shows you tested the edge, not just the middle.
- Keep the user in the sentence — Phrases like 'the customer sees' or 'the manager cannot approve' keep your explanation in business language.
- Admit what you did not cover — Saying 'I did not test partial refunds because they were out of scope for this release' shows you understand scope, not that you missed it.
- Prepare one failed case — A case that failed and led to a defect or change request makes a better interview story than ten that passed quietly.
SECTION 06Interview Q&A — BA test cases
Q1Do Business Analysts write test cases, or is that the tester's job?
Both, but at different levels. Testers usually write detailed functional and regression cases. A BA often writes or reviews UAT cases that prove the business rule is met, and helps business users run them. I explain that I wrote acceptance-level cases from user stories and reviewed QA cases for coverage of the rules.
Q2How do you decide what test data to use in a UAT case?
I look at the rule and pick values just below, exactly at and just above any limit, plus one clearly invalid value. For a 30-day refund rule I would use orders delivered 29, 30 and 31 days ago. Then I add data for roles, such as a customer and an admin, if the rule depends on who is acting.
Q3What do you do when a UAT test case fails?
First I check whether the build is wrong or the requirement was unclear. If the story clearly states the rule and the system does something else, it is a defect, so I log it with steps and evidence. If the story was silent or the business has changed its mind, it is a change request that needs re-estimation and approval.
Q4How do acceptance criteria relate to test cases?
Acceptance criteria are the testable conditions written in the user story, often in Given-When-Then format. Each criterion should produce at least one test case, usually more if there is a boundary. If I cannot write a test case for a criterion, that tells me the criterion is too vague and needs rewording.
Q5What is a requirements traceability matrix and why does it matter?
It is a table that links each requirement to its test cases and their status. It shows coverage, so nothing is shipped untested, and it shows impact, so when a requirement changes we know which cases to update. In UAT it also tells the business exactly which requirements are ready for sign-off.
SECTION 07Test yourself — BA test cases quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
What is a UAT test case for a business analyst?
A UAT test case is a scenario that checks whether a feature meets the business need in the requirement. It is written in business language, includes realistic test data and an expected result, and is usually run by business users with the BA's help before sign-off.
How do I explain a test case in a business analyst interview?
Start with the user story and the rule it covers, then explain the test data you chose and why, especially any boundary values. Mention a question you raised about the requirement, and end with the result and how it was traced back to the requirement.
What is the difference between a test case and a test scenario?
A test scenario is a high-level situation to check, such as 'customer requests a refund after the window closes'. A test case is the detailed version with specific data, steps and an expected result. One scenario usually becomes several test cases.
Should a fresher business analyst know Gherkin?
It helps. Given-When-Then is a common way to write acceptance criteria, and being able to turn a vague rule into a clear Gherkin scenario is a practical skill interviewers like to see. You do not need to know automation tools to use it.
How many test cases should one user story have?
There is no fixed number. It depends on how many rules and boundaries the story contains. A simple story may need two or three cases, while a story with limits, roles and exceptions may need many more. Coverage of each acceptance criterion matters more than the count.
How can I prepare for Business Analyst interview answers with a trainer?
Yes. Uncodemy's Business Analyst Training Course in Noida (classroom and online) includes live projects, one-to-one mock interviews and resume reviews, so you practise Business Analyst 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
Learn to explain your BA work with confidence
Our Business Analyst Training Course covers user stories, acceptance criteria, UAT and traceability through practical case studies, with mock interviews where you explain your own work aloud.
Talk to a counsellor for current fees- User stories & UAT practice
- Real case study projects
- Mock BA interviews
- Weekday & weekend batches