What Interviewers Look for in a Fresher Software Tester

CURIOUS FRESHER — FIRST 90 SECONDS:

Interviewer: "Tell me about your testing
experience."

Candidate: "Sure. I don't have professional
experience yet, but I've been testing my own
projects — let me tell you about a bug I
found, because that's the most honest answer.

I built a small e-commerce cart as a learning
project. The spec said 'the cart shows the
total with a coupon applied.' I tried the
normal case — one coupon, works.

Then I got curious: what if I stack two
coupons? The cart only applied one and showed
the full price — no error, just wrong. I
tried a third case: apply a coupon, then
empty the cart. The total went to minus $5.

I wrote two bug reports — steps to reproduce,
expected vs. actual, a screenshot, and the
browser version. I fixed both in the code and
added a test for each.

I've also been learning Selenium and Postman,
but I wanted to lead with the bugs because
that's what I'd actually be doing."

What the interviewer thinks in 90 seconds:
- "They led with a bug, not a tool." ✅
- "They explored edge cases: stacking,
  emptying." ✅
- "They wrote real bug reports." ✅
- "They fixed and tested the bugs." ✅
- "They know their tool learning is
  secondary." ✅

Signal: strong. The rest of the interview
confirms it.

TOOL-LIST FRESHER — FIRST 90 SECONDS:

Interviewer: "Tell me about your testing
experience."

Candidate: "I've completed a software testing
course. I know manual testing, Selenium
WebDriver, TestNG, the Page Object Model,
Postman, and Jira. I've written 200 test
cases in my course project. I'm familiar with
the SDLC and STLC, and I know how to write a
test plan."

What the interviewer thinks in 90 seconds:
- "No bug found." ❌
- "No edge case explored." ❌
- "200 test cases — but did any of them
  catch anything?" ❌
- "This is a course syllabus read aloud." ❌
- "I'll ask a follow-up and see if there's
  curiosity underneath." ⚠️

What happens next:
- The interviewer asks "Tell me about a bug
  you found."
- The candidate says "I found bugs in my
  project."
- The interviewer asks "Which bugs — can you
  describe one?"
- The candidate pauses.

Signal: weak. The tool list is a course
completion; there's no curiosity behind it.

Why it failed:
❌ Tools before bugs
❌ No edge case
❌ 200 test cases with no bugs caught
❌ No bug report
❌ The first 90 seconds signaled "I
  completed a course," not "I test"

EDGE CASE ANSWER — WHAT DECIDES:

Interviewer: "What edge cases did you try?"

WHAT THE CANDIDATE SAYS:
"Three, and each one taught me something
different.

Case one: an empty cart. The spec said 'the
cart shows the total as zero.' I tried it —
zero. Fine.

Case two: a coupon on an empty cart. The spec
didn't cover this. I applied a 10% coupon to
an empty cart and the total went to minus $5.
The code subtracted the discount from zero.
That's the bug I filed — high severity,
because a negative total is a visible wrong
number.

Case three: two coupons stacked. The spec
said 'the cart applies a coupon.' I tried two
and it applied only one — no error, just the
wrong total. Medium severity, because it's
wrong but not obviously wrong.

Case four: an expired coupon. The code
accepted it. The spec didn't say what to do,
so I flagged it as a question for the product
owner rather than a bug — that's a design
decision, not a defect.

The lesson: the spec covers the happy path.
The bugs live in the cases the spec doesn't
mention. I now write those cases down before
I test, so I don't forget them.

I can show you the bug reports and the test
notes."

What the interviewer thinks:
- "They named four edge cases." ✅
- "Each has a distinct severity." ✅
- "They distinguished a bug from a design
  question." ✅
- "They named the lesson." ✅
- "They have the reports." ✅

Signal: confirmed curiosity.

Why it decides:
✅ Four edge cases, each distinct
✅ Severity judgment is named
✅ Bug vs. design question is
  distinguished
✅ The lesson is reusable
✅ Evidence is available

BUG REPORT ANSWER — WHAT DECIDES:

Interviewer: "Walk me through a bug report you
wrote."

WHAT THE CANDIDATE SAYS:
"Sure. This is the negative-total bug — the
one I'm most proud of, because the report is
why it got fixed.

The title: 'Cart total goes negative when a
coupon is applied to an empty cart.'

The steps: add an item, apply a 10% coupon,
remove the item. The total shows -$5.00.

The expected: the total should be $0.00 — a
coupon on an empty cart should do nothing, or
show an error.

The actual: -$5.00.

The severity: high. It's a visible wrong
number on the checkout page — a customer
would screenshot it.

The environment: Chrome 120, Windows 11.

The evidence: a screenshot and a 15-second
video showing the steps.

The note: 'The discount is subtracted from
the subtotal before checking if the subtotal
is zero.'

The result: the developer fixed it in a day.
They said the note saved them 30 minutes of
debugging — they knew where to look.

The lesson: a bug report is a communication,
not a complaint. The clearer the report, the
faster the fix."

What the interviewer thinks:
- "The title states the bug in one line." ✅
- "The steps are exact." ✅
- "Expected vs. actual is explicit." ✅
- "The severity has a reason." ✅
- "The note points to the cause." ✅

Signal: confirmed curiosity.

Why it decides:
✅ Title states the bug
✅ Steps are reproducible
✅ Expected vs. actual
✅ Severity has a reason
✅ The note points to the cause

TAKE-HOME REVIEW — CURIOUS VS. TOOL-LIST:

Scenario: "Review this take-home. Both
freshers wrote a test plan for a login page."

TOOL-LIST TAKE-HOME:
- A 40-case test plan copied from a template
- Cases: "valid login," "invalid login,"
  "forgot password," "empty field"
- No edge cases
- No severity
- No expected vs. actual
- No README

What the interviewer thinks:
- "It's a template."
- "No edge cases — no account lockout, no
  SQL injection attempt, no session expiry."
- "No expected vs. actual — how would a
  developer use this?"
- Signal: tool-list.

CURIOUS TAKE-HOME:
- A 24-case test plan, each with expected vs.
  actual and a severity
- Edge cases: account lockout after 5
  attempts, expired session, a password with
  emoji, SQL injection in the email field,
  and a logout in one tab with an active
  session in another
- A note on the logout case: "The spec
  doesn't cover this — I flagged it as a
  question for the product owner, not a bug."
- A README: "The case I'd test first is the
  lockout — if it's not implemented, that's a
  security issue, not a UX issue."
- A "what I'd test next" section: password
  reset flow, MFA

What the interviewer thinks:
- "Expected vs. actual on every case." ✅
- "Edge cases beyond the template." ✅
- "A design question flagged separately." ✅
- "The first case to test is named." ✅
- "A next-step section." ✅
- Signal: curious.

Why it decides:
✅ Expected vs. actual on every case
✅ Real edge cases
✅ Design question distinguished from bug
✅ Priority is named
✅ A next step is named

INTERVIEW FOLLOW-UP — CURIOUS VS.
TOOL-LIST:

Scenario: "You found the negative-total bug.
How did you decide the severity?"

TOOL-LIST SIGNAL:
"I marked it high because it seemed
important. I always mark bugs high if they're
on the checkout page."
What the interviewer thinks:
- "No reasoning — 'seems important' is not
  severity."
- "Every checkout bug marked high means the
  developer can't prioritize."
- Signal: tool-list.

CURIOUS SIGNAL:
"I used three factors, and one of them is
the reason it's high, not medium.

Factor one: visibility. A wrong number on
the checkout page is visible to every
customer — a customer would screenshot it.
That alone pushes it above cosmetic bugs.

Factor two: business impact. A negative total
might confuse a customer into abandoning the
cart, or worse, into thinking they'll get
paid. Either way, it costs revenue.

Factor three: reproducibility. It reproduces
100% of the time with three steps — no flaky
conditions, no specific browser. A bug that
reproduces reliably is easier to fix, which
usually means faster.

The reason it's high and not medium: the
negative total is visible AND reproducible.
A bug that's visible but flaky is medium; a
bug that's reproducible but hidden is low.
This one is both visible and reliable, so high.

The trade-off: marking it high does jump the
queue over other bugs. I chose that because
the alternative — a customer seeing -$5.00 on
checkout — is worse than a two-day delay on a
cosmetic fix.

The lesson: severity isn't 'how bad it feels.'
It's visibility times business impact times
reproducibility. I've used that framework on
every bug since."

What the interviewer thinks:
- "Three factors, each named." ✅
- "The high-vs-medium distinction is
  reasoned." ✅
- "The trade-off is named." ✅
- "The framework is reusable." ✅
- "This is a fresher who thinks like a
  tester." ✅
- Signal: curious.

Why it decides:
✅ Three factors are named
✅ High vs. medium is reasoned
✅ The trade-off is named
✅ The framework is reusable
✅ Tester judgment is visible

Fresher Tester Checklist:

FIRST 90 SECONDS:
☐ Lead with a bug you found, not a tool
  you used
☐ Name an edge case beyond the spec
☐ Name a bug report you wrote
☐ Avoid "I know Selenium, TestNG, and the
  Page Object Model" as the whole answer

WHAT DECIDES:
☐ Severity is reasoned: visibility ×
  business impact × reproducibility
☐ Bug vs. design question is
  distinguished
☐ The report has expected vs. actual and
  a note pointing to the cause
☐ The note is what saves the developer
  time

WHAT CONFIRMS:
☐ A reusable framework or lesson
☐ The report or test notes are available
☐ What you'd test next is named
☐ You can walk through the report without
  pausing
☐ You can explain why a bug is high vs.
  medium

RED FLAGS:
❌ Tools before bugs
❌ "200 test cases" with no bugs caught
❌ No edge cases
❌ Severity marked high for everything
❌ No expected vs. actual
❌ "I logged it in Jira" with no detail
❌ No lesson or framework

Why this works:
- The first 90 seconds set the signal
- The rest of the interview confirms or
  overturns it
- Edge cases, reasoned severity, and a
  structured bug report are the three
  things a course can't fake

30-DAY PRACTICE PLAN (FOR FRESHERS):

Week 1 — Find real bugs
☐ Pick a site or app you use daily
☐ Test it against its own spec or help
  pages
☐ Try 10 edge cases: empty, max, special
  characters, double-click, back button
☐ Write down every case where the result
  surprised you
☐ Pick the 3 most interesting

Week 2 — Write bug reports
☐ For each of the 3, write a report:
  title, steps, expected vs. actual,
  severity, note
☐ The note should point to a likely cause
☐ Add a screenshot or a short video
☐ Read each aloud — could a developer
  fix it from this?

Week 3 — Severity framework
☐ For each bug, score visibility ×
  business impact × reproducibility
☐ Write why it's high, medium, or low
☐ Compare with how you'd have marked it
  before
☐ Write the framework in one sentence

Week 4 — Mock interviews
☐ Run 2 mock interviews with a peer
☐ Ask them to challenge: "Tell me about a
  bug you found" and "Why is that high
  severity?"
☐ Re-run with stronger bug reports and
  severity reasoning
☐ Compare the two recordings

Signs it's working:
✅ You lead with a bug, not a tool
✅ You have 3 real bug reports
✅ Your severity has a reason
✅ Your report has a note pointing to the
  cause
✅ You have a framework you can explain
✅ The interviewer asks "what else?"
  instead of "what tools do you know?"