"How would you test a login page?" (or an ATM, a payment gateway, a booking system) is one of the most common scenario-based testing interview questions. Interviewers aren't looking for a memorised list; they want to see structure: functional checks, negative and boundary cases, security, usability and failure handling. Each scenario below is organised that way so you can answer any variation.
How to Structure Any "How Would You Test…" Answer
- Clarify: ask about requirements, users, platforms and constraints before listing tests.
- Functional: the main flows and the rules behind them.
- Negative and boundary: invalid input, limits and empty states.
- Non-functional: security, performance, usability, accessibility, compatibility.
- Failures: what happens when the network, payment or a dependency fails.
- Automation: which of these you would automate and at which level (UI or API).
Advertisement
1. How would you test a login page?
| Area | What to test |
|---|
| Functional | Valid login; invalid username or password; empty fields; case sensitivity of password; Remember me; logout |
| Security | Account lockout after repeated failures; password masked; no credentials in URL; SQL injection and script input handled safely; session expires; back button after logout doesn't restore the session |
| Usability and others | Tab order and Enter key submit; error messages that don't reveal which field was wrong; works on supported browsers and mobile |
| Area | What to test |
|---|
| Validation | Required fields, email and phone formats, password rules, confirm password match, field length limits, special characters and Unicode names |
| Business rules | Duplicate email or username rejected; age or country restrictions; terms checkbox required |
| After submit | Account created in the database, verification email sent, user can log in, data stored exactly as entered |
3. How would you test a forgot-password feature?
| Area | What to test |
|---|
| Request | Registered and unregistered emails (same neutral message, so attackers can't discover accounts); invalid formats; rate limiting on repeated requests |
| Reset link | Arrives by email; works once; expires after the set time; old links stop working after a new request or a successful reset |
| New password | Password rules enforced; can't reuse old password if that's a rule; old password no longer works; other sessions logged out |
4. How would you test add to cart?
| Area | What to test |
|---|
| Core | Add one and several items; quantity changes; same item twice; remove items; cart count and totals update |
| Rules | Out-of-stock and maximum quantity; price and discount applied correctly; variants such as size and colour kept |
| Persistence | Cart kept after refresh, across tabs, after login (guest cart merges) and after logout as designed |
5. How would you test a payment gateway?
| Area | What to test |
|---|
| Happy path | Successful payment with each supported method (cards, UPI, wallets, net banking) using sandbox data |
| Failures | Declined card, insufficient funds, wrong OTP, timeout, user closes the payment page; order state stays correct and no double charge |
| Integrity | Amount, currency and rounding; refresh or back button during payment; duplicate clicks; refunds; confirmation email and database records |
| Security | HTTPS, card data never stored or logged, 3-D Secure flows |
6. How would you test search?
| Area | What to test |
|---|
| Results | Exact, partial and case-insensitive matches; no results message; relevant ordering |
| Input | Empty search, very long text, special characters, Unicode, leading and trailing spaces, injection-like input |
| Features | Filters, sorting, pagination, suggestions/auto-complete, search history |
| Performance | Response time on large data sets |
7. How would you test file upload and download?
| Area | What to test |
|---|
| Upload | Allowed types and sizes; size limit exceeded; zero-byte and very large files; multiple files; file names with spaces or Unicode; cancel mid-upload |
| Security | Disallowed types renamed with an allowed extension; malicious content; path-traversal names |
| Download | Correct file, name and content; large files; unauthorised users blocked |
8. How would you test an email field?
| Area | What to test |
|---|
| Valid formats | Plus addressing, subdomains, long but valid addresses, upper case |
| Invalid formats | Missing @ or domain, spaces, double dots, trailing dot, very long input |
| Behaviour | Trimming spaces, uniqueness check, error message wording, copy-paste |
| Area | What to test |
|---|
| Dropdown | Default value, all options present and spelled correctly, order, selection saved, dependent dropdowns refresh, keyboard selection |
| Radio buttons | Only one selectable per group, default selection, label click selects, required validation |
10. How would you test an ATM?
| Area | What to test |
|---|
| Card and PIN | Valid and invalid card, expired or blocked card, wrong PIN, card retained after three wrong PINs |
| Transactions | Withdrawal within balance and daily limit, denominations, insufficient funds, balance enquiry, mini statement, deposit |
| Failures | Power loss or network failure mid-transaction (account not debited without cash), cash jam, receipt printer out of paper, timeout returns card |
| Usability and security | Screen readability, language options, card and cash not left in the slot, shoulder-surfing protection |
11. How would you test a calculator app?
| Area | What to test |
|---|
| Operations | Addition, subtraction, multiplication and division with positive, negative and decimal numbers; order of operations |
| Edge cases | Division by zero, very large numbers, many decimals, repeated equals, clear and backspace |
| UI | Keyboard input, display overflow, copy and paste |
12. How would you test a mobile app login screen?
| Area | What to test |
|---|
| Functional | Everything from the web login plus biometric login and OTP login |
| Mobile-specific | Keyboard types for email and password, screen rotation, app backgrounded mid-login, poor or no network, push-notification interruption |
| Devices | Different screen sizes and OS versions, permission prompts |
13. How would you test a booking system (bus, flight, hotel)?
| Area | What to test |
|---|
| Search | Dates, past dates rejected, return before departure rejected, passenger counts, no availability |
| Booking | Seat selection, price breakdown, simultaneous booking of the last seat (only one succeeds), payment and confirmation, ticket and email |
| Changes | Cancellation and refund rules, rescheduling, time zones on flights |
14. How would you test an online exam portal?
| Area | What to test |
|---|
| Before the exam | Login, exam available only in its time window, instructions |
| During | Timer accuracy and auto-submit at time-out, answers saved on refresh or network drop, navigation between questions, no copy or tab switching if that's a rule |
| After | Score calculation, result publishing, attempt limits, reports for the examiner |
15. How would you test an e-commerce checkout end to end?
| Area | What to test |
|---|
| Flow | Cart → address → delivery → payment → confirmation, as guest and logged-in user |
| Calculations | Taxes, shipping, coupons and their combinations, rounding |
| Integrity | Inventory reduced once, order and payment records match, emails sent, order visible in history |
| Failures | Payment failure, address validation errors, session timeout mid-checkout |
For defect and project situations, continue with defect-handling scenario questions and requirement and release scenario questions.
FAQs
How do I answer "how would you test a pen" type questions?
Ask clarifying questions first, then cover functional, negative and boundary, non-functional (usability, durability, safety) and failure scenarios, and say which you would prioritise. The structure matters more than the length of the list.
Should I mention automation in scenario answers?
Yes, briefly: say which checks you would automate (stable, repetitive, data-driven ones) and at which level, for example validating payment rules through the API rather than the UI.
