3.3Format 2: "How Would You Test X?" Exercises
This is the most common QA interview format. The interviewer names a system, feature, or physical object, and you are expected to systematically identify test scenarios. The goal is not to list every test case -- it is to demonstrate structured thinking.
The Structured Approach
Use this 5-step framework for any "how would you test" question:
- Clarify requirements: Ask 3-5 questions before you start listing tests
- Identify user personas: Who uses this and how?
- Functional testing: Happy path, edge cases, error handling
- Non-functional testing: Performance, security, accessibility, usability
- Integration and system testing: How does it interact with other systems?
"How would you test a login page?"
Step 1 -- Clarify: "What authentication methods are supported? Is there MFA? Rate limiting? Password complexity requirements? SSO?"
Step 2 -- Personas: New user, returning user, admin, locked-out user, user on mobile
Step 3 -- Functional:
| Category | Test Cases |
|---|---|
| Happy path | Valid username + password, redirect to dashboard |
| Invalid inputs | Wrong password, nonexistent username, empty fields, SQL injection attempts, XSS in username |
| Boundary values | Maximum length username, maximum length password, minimum password length |
| Error handling | Clear error message (does not reveal which field is wrong for security), retry behavior |
| State management | Session creation, cookie handling, concurrent sessions, session expiry |
| Remember me | Cookie persistence, security implications, cross-browser behavior |
| Forgot password | Email delivery, token expiry, link reuse prevention |
Step 4 -- Non-functional:
- Performance: Login under load (1000 concurrent users), response time < 2s
- Security: Brute force protection, account lockout after N attempts, HTTPS enforcement, password not logged in plaintext, CSRF protection
- Accessibility: Screen reader compatibility, keyboard navigation, color contrast on error messages
- Usability: Tab order, autofill behavior, error message clarity
Step 5 -- Integration: OAuth/SSO provider integration, audit log verification, notification system (login from new device)
"How would you test an elevator?"
This classic question tests whether you can apply systematic thinking to a non-software system.
Clarify: How many floors? How many elevators? Is there a weight limit? Are there accessibility requirements?
| Category | Test Cases |
|---|---|
| Basic functionality | Press button, elevator arrives. Select floor, elevator goes there. Doors open and close. |
| Edge cases | Press all floor buttons simultaneously. Press the same floor you are on. Press door-open while doors are closing. |
| Load testing | Maximum weight capacity. One person below minimum. Exactly at weight limit. |
| Safety | Emergency stop button. Door sensor (object in doorway). Power failure behavior. Fire mode. |
| Accessibility | Braille buttons. Audio announcements. Door timing for wheelchair users. Low-mounted buttons. |
| Concurrency | Multiple people pressing buttons on different floors. Two elevators optimizing for efficiency. |
| Environmental | Operation during earthquake. Temperature extremes. Water/flooding. |
| Usability | Button feedback (lights up when pressed). Floor indicator display. Wait time expectations. |
"How would you test a shopping cart?"
Clarify: Web or mobile? What payment methods? Is there a guest checkout? What is the maximum cart size?
| Category | Test Cases |
|---|---|
| Add to cart | Single item, multiple items, same item multiple times, maximum quantity |
| Remove from cart | Remove one item, remove all items, remove during checkout |
| Update quantity | Increase, decrease, set to zero, exceed inventory |
| Pricing | Unit price, bulk discounts, coupon codes, tax calculation by region, currency display |
| Persistence | Cart survives page refresh, cart survives logout/login, cart merges on login (guest + account) |
| Inventory | Out-of-stock handling, item becomes unavailable during browsing, last-item race condition |
| Performance | Cart with 100 items, price recalculation speed, concurrent cart updates |
| Security | Price manipulation via API, coupon code brute force, session hijacking |
| Integration | Payment gateway, inventory system, shipping calculator, tax service |
| Accessibility | Screen reader announces cart updates, keyboard navigation through cart items |
"How would you test an AI-powered feature?"
As of mid-2026, this is a standard question, not a bonus round. QA and SDET job postings at AI-forward companies now explicitly list AI-testing competencies -- they are table stakes there, not optional differentiators. Expect the interviewer to probe:
| Competency | What They Ask About |
|---|---|
| Agent flow testing | Testing MCP (Model Context Protocol) tool integrations and A2A (agent-to-agent) interactions -- "agentic testing" is now mainstream vocabulary |
| LLM eval design | Building evaluation suites with frameworks like Ragas, TruLens, or OpenAI Evals instead of asserting exact string output |
| RAG quality metrics | Precision@K, Recall@K, grounding, and citation accuracy for retrieval-augmented features |
| Orchestration exposure | Familiarity with LangChain/LangGraph pipelines and their failure modes |
| Python + PyTest | The default stack for AI-adjacent test tooling |
Structure the answer like any other "how would you test" question: clarify first (which model and version? what temperature? what does a bad answer cost the business?), then cover functional behavior, eval metrics with explicit thresholds, and non-functional concerns -- latency, cost per call, and prompt-injection resistance.