QA Engineer (Manual) interview prep

Short answer: A full test case with preconditions, steps, and expected result is needed where reproducibility and traceability matter: audit, compliance, complex multi-step flows. A lightweight checklist is enough for regression on stable features and exploratory sessions, where speed matters more.

In depth:

1. Test case — a formal document anyone can replay step by step; expensive to write and maintain.
2. Checklist — a list of what to verify, without detailed steps; fast to draft, flexible to use.
3. Selection criterion — maintenance cost versus the need for rigor and auditability.

⚠️ Common mistake: dragging heavy formal test cases into places where a checklist suffices and drowning in documentation upkeep instead of actual testing. The interviewer wants to hear you justify the choice under time pressure.

Short answer: New → Assigned → In Progress → Fixed → Retest → Closed. That's the main flow, but it has important branches: Reopened (the bug came back after the fix), Rejected (not a bug), Duplicate (already filed), Deferred (postponed). The key to the answer is naming not just the line but the branches, and who performs each transition.

In depth:

1. New — the tester filed the bug.
2. Assigned → In Progress — the lead assigns a developer, who picks it up.
3. Fixed — the developer fixed it and handed it back for verification.
4. Retest → Closed — the tester re-verifies on the new build and closes it.
5. Branches — Reopened (tester), Rejected/Duplicate (developer or lead), Deferred (PM postpones it).

 New ──► Assigned ──► In Progress ──► Fixed ──► Retest ──► Closed
 (QA)     (lead)        (dev)         (dev)     (QA)       (QA)
           │                                      │ failed
           ▼                                      ▼
 Rejected / Duplicate (dev, lead)          Reopened ──► back into work
 Deferred (postponed by PM)

⚠️ Common mistake: naming only the straight line New→Closed and forgetting the Reopened/Rejected/Duplicate/Deferred branches — those are exactly what show you've worked in a real tracker.

Short answer: The client (browser, mobile app) sends a request, the server processes it and returns a response — the request/response model over HTTP. You can't rely on client-side validation because the client is fully under the user's control: the form can be bypassed via curl, Postman, or DevTools and any data sent to the server. So the server must validate itself, and QA tests both layers independently.

In depth:

1. Client — renders the UI, does first-pass validation for convenience (fast feedback, less traffic), holds the token.
2. Server — the source of truth: checks permissions, validates the body, writes to the DB. It's the only layer you can trust.
3. What QA does — doesn't just click the UI but hits the API directly, bypassing the client: sends empty/invalid fields, someone else's id, injections — and checks the server rejected them (400/403) rather than saving them.

  CLIENT                         SERVER
 ┌────────┐   request  (HTTP)  ┌─────────┐
 │  UI    │ ─────────────────► │  API    │
 │ ✔ UX   │                    │ ✔ manda-│
 │ valid. │ ◄───────────────── │ tory    │──► DB
 └────────┘   response         │ valid.  │
     ▲  can be bypassed:       └─────────┘
     └── curl / Postman / DevTools

⚠️ Common mistake: assuming that because the Submit button is disabled on the form, invalid data never reaches the server. The UI is bypassed in a second — a robust system validates everything server-side.

Short answer: Cross-browser testing verifies that the app works consistently across different browsers, versions, and OSes. You build the matrix not from "all browsers" but from audience traffic analytics and risk: a full browser × OS × resolution sweep is infeasible, so you trim it with prioritization and a pairwise approach.

In depth:

1. Start from data — analytics (GA, etc.) show the real browser/OS/device shares of your actual audience.
2. Prioritize by coverage and risk — the combinations covering most users and critical flows (payment, sign-up) come first.
3. Shrink the sweep — pairwise testing covers all pairs without the combinatorial explosion.

⚠️ Common mistake: being unable to justify the matrix ("I checked whatever was handy"). The interviewer wants the "audience data + risk + pairwise" reasoning, not a list of your favorite browsers.

Short answer: 2 weighings. I split into groups of 3-3-2, not in half, because a balance has three outcomes (left heavier / right heavier / equal), so each step eliminates a full third.

In depth:

1. First weighing — 3 against 3, set 2 coins aside.
   • If one pan rises — the fake is among the 3 on the risen (lighter) side.
   • If balanced — the fake is among the 2 set aside.
2. Second weighing — from the suspect group put 1 coin on each pan.
   • From the group of 3: 1 vs 1; whichever rises is fake, if equal it's the third one held back.
   • From the group of 2: 1 vs 1; the lighter one is the fake.
3. Why not 3 — a balance is ternary: k weighings distinguish up to 3^k cases. 3² = 9 ≥ 8, so two suffice; splitting in half (binary) wastes the "equal" outcome.

         8 coins
     [3] vs [3]   +2 aside
      /    |    \
  rises  equal  rises
   3        2        3
 [1]vs[1] [1]vs[1] [1]vs[1]
  → 2 weighings

⚠️ Common mistake: answering "3" by splitting in half (4-4-2-2-...). That ignores that the balance gives THREE outcomes, not two — and wastes a weighing.