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.

	Test case	Lightweight checklist
Detail	steps + expected result	"what to check" items
When	audit, compliance, complex flows	regression on stable, exploratory
Cost	high	low
Reproducibility	exact	depends on the engineer

⚠️ 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.

Browser	Audience share	Priority
Chrome (Win)	58%	P0
Safari (iOS)	22%	P0
Chrome (Android)	12%	P1
Firefox / Edge	6%	P2
IE / others	2%	not tested

⚠️ 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: SELECT retrieves rows from tables. The logical execution order does NOT match the written order: first FROM, then WHERE, GROUP BY, HAVING, SELECT, DISTINCT, ORDER BY, LIMIT.

In depth:

Written (syntactic) order:

SELECT   DISTINCT col1, agg(col2)
FROM     t
WHERE    cond
GROUP BY col1
HAVING   agg_cond
ORDER BY col1
LIMIT    10 OFFSET 20;

Logical execution order:

1. FROM / JOIN      -- which tables, how to join
2. WHERE            -- row filter BEFORE grouping
3. GROUP BY         -- grouping
4. HAVING           -- group filter AFTER aggregation
5. SELECT           -- evaluate expressions, aliases
6. DISTINCT         -- remove duplicates
7. ORDER BY         -- sorting
8. LIMIT / OFFSET   -- slice

⚠️ Gotcha: an alias from SELECT cannot be used in WHERE (since WHERE runs before SELECT), but it can be used in ORDER BY and often in GROUP BY (depends on the DBMS). Example of the error:

SELECT salary * 12 AS annual FROM emp WHERE annual > 100000; -- ERROR
SELECT salary * 12 AS annual FROM emp ORDER BY annual;        -- OK