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: Selenium supports eight strategies: id, name, className, tagName, linkText, partialLinkText, cssSelector and xpath. CSS is faster and more readable, but XPath can do what CSS cannot: traverse up and backwards through the DOM (ancestor, parent, preceding-sibling) and locate an element by its text. That asymmetry is the whole point.

In depth:

1. CSS selector — the default choice: terse syntax, runs faster (the browser optimizes its CSS engine), covers 90% of cases.
2. XPath upward navigation — only XPath can go from a found element to its parent/ancestor: //span[text()='Total']/ancestor::tr.
3. XPath by text — //button[text()='Pay'] or contains(text(),'...'); CSS has no way to match on text content at all.

⚠️ Common mistake: not knowing the asymmetry and answering "XPath is more powerful." It's only more powerful for upward and text-based navigation — for everything else CSS is the default.