Scenario practice

"How would you test a login page?" "Test this pen." "Write test cases for a lift." These questions appear at every experience level. There is no single right list. The interviewer is watching how you think: whether you ask questions first, cover more than the happy path (the normal case where everything goes right), and decide what matters most. This article gives you a four-step method that works for any product, then a short worked example.

Step 1: ask before you list

Spend the first minute on questions. Who uses it? What are the rules and limits? What matters most here: money, safety, speed or ease of use? Which platforms? Questions show that you test against requirements, not guesses, and they often lead to the most interesting cases.

For a coupon field you might ask whether the discount is a percentage or a flat amount, whether there is a minimum order or a maximum discount, when coupons expire, how many times one user may use a code, and whether two coupons can be combined. For a lift: how many floors, the weight limit, special modes such as fire service, and the safety rules it must meet.

Step 2: group your cases

A long random list is hard to follow. Say your headings out loud and give two or three strong cases under each:

• Main flows (the normal steps a user takes) with valid input.
• Invalid input: wrong, empty, too long, wrong format, special characters.
• Boundaries: each limit, just inside and just outside (see test design techniques).
• States and sequences: repeating an action, going back, refreshing, timing out, doing steps in the wrong order.
• Integration: other systems that the feature touches, such as payment, email or the database.
• Non-functional: speed, security, usability, accessibility and browsers.
• Failure and recovery: network loss, power cut, a third-party service being down.

Step 3: find the risky edges

A few cases in every scenario separate strong answers from average ones. Look for them on purpose.

• Money and data: can anything be charged twice, lost, or saved half-way? At an ATM, what happens if the network drops after the account is debited but before the cash comes out?
• Two users at once (called concurrency): two buyers press Buy on the last unit in a flash sale at the same moment.
• Security: can one user see another's data by changing an ID (a number in the web address)? Does a login error reveal whether an email address has an account?
• Time: expiry windows, time zones, leap years.
• Units: is "5 MB" 5,000,000 bytes or 5,242,880? Is "30 minutes" counted from the request or from the email?

Step 4: prioritise and close

End by saying which cases you would run first and why, usually the ones about money, data and the main flow. Then say what you would automate. Stable rules that run often, such as limits and calculations, suit automation, ideally at the API level. Look and feel, usability and one-off checks suit manual and exploratory testing.

Worked example: a search box

Ask first: which fields are searched (the product name only, or also the description), whether spelling is corrected, and how results are ordered. Main flows: an exact product name finds it first; part of a word and several words work; upper and lower case give the same results. Invalid input: a query with no matches shows a helpful message; an empty query, only spaces, 500 characters, and script tags that must show as plain text. Results: sorting and filters combine correctly with the query, and paging (splitting results into pages) neither repeats nor skips items. Non-functional: quick answers with a large catalogue, a mobile layout, a label for screen readers (software that reads the screen aloud for people who are blind or have low vision). Priority: relevance and filters first, because they drive sales; automate the query rules through the API.

Physical objects

"Test a pen" uses the same method. Ask who uses it and for what. Then cover function (it writes, the click works), boundaries (writing upside down, on glossy paper), durability (drops, thousands of clicks), comfort and ink life, and safety. The object matters less than the structure you show.

How to answer in an interview

Talk for three to five minutes. Say your questions, then your headings, then the risky edges, then your priorities. If the interviewer interrupts with a new rule, adjust out loud: "then I would add a boundary test at 500".

Common mistakes

• Starting the list without a single question.
• Only happy-path cases.
• Twenty small UI checks and no case about money, data or security.
• No priorities at the end.

Recap

Ask, group, find the risky edges, prioritise. Practise each scenario in this topic aloud with a timer, then compare your answer with its checklist and note what you missed.