QA Automation Engineer 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: Mutable objects can change in place (list, dict, set); immutable objects cannot (int, str, tuple). Rebinding a variable is different from mutating its object.

items = [1, 2]
alias = items
items.append(3)
assert alias is items and alias == [1, 2, 3]

text = "hello"
original = text
text += " world"
assert original == "hello"  # the original string did not change

In depth:

• id() identifies an object and stays constant during its lifetime. Treating it as a memory address is a CPython implementation detail.
• A tuple cannot replace its elements, but a list stored inside it can still change. Immutability is not automatically deep immutability or thread safety.
• Dictionary keys and set elements must be hashable: their hash stays stable, and equal objects have equal hashes. A tuple containing a list is unhashable. A user-defined mutable instance can be hashable by identity, so hashability is not synonymous with immutability.
• Functions receive references to objects. Mutating an argument can affect the caller; rebinding a local parameter does not rebind the caller's variable.

Sources: Python hashability, object identity.