QA Engineer Interview Question

A field accepts a quantity from 1 to 100. What test cases would you write?

What the interviewer is probing, how to structure your answer, and a spoken example you can adapt.

Quick answer

Use equivalence partitioning plus boundary value analysis. The partitions are below range, valid range, and above range, so one representative from each. The boundaries are the interesting part: 0, 1, 2, 99, 100, 101. Then add the non numeric cases: empty, negative, decimal, whitespace, very large numbers, and text, plus how the field behaves on paste rather than typing.

Why interviewers ask this

This is a test design fundamentals check, deliberately simple so the interviewer can see whether you are systematic. They want the technique named, the exact boundary values listed, and then the cases beyond the happy numeric path, since off by one errors and unvalidated input are where the real defects sit. Listing values one at a time with no technique behind them reads as guessing.

How to structure your answer

  • Name the two techniques before listing any cases.
  • List the boundary values explicitly, including just outside the range.
  • Add invalid types and formats, not just numbers.
  • Mention input method differences such as paste or the API.

Example answer

Spoken example, first person

I would use equivalence partitioning to cut the space, then boundary value analysis for the interesting bits. The partitions are below one, one through a hundred, and above a hundred, so one value from each covers the classes. Then boundaries, which is where the defects actually live, because off by one is the most common mistake in a range check: 0, 1, 2, 99, 100, and 101. If I can only run six cases, those are the six. Then I go after everything that is not a well behaved integer, because that is where validation gets skipped: empty, a single space, a negative, a decimal like 1.5, a leading zero, a very long number that overflows whatever type sits behind it, scientific notation, and plain text. I also test the input method, because typing, pasting, and the browser's spinner arrows often hit different code paths, and I have found bugs where typing was validated and paste was not. And I check the server, not just the browser, by sending 101 straight to the API, since client side validation is a convenience rather than a control.

Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.

See how it works

Follow-up questions to expect

  • What would you expect to happen at 101, and how would you verify it server side?
  • How would decision table testing help if this field interacts with another one?
  • How does your answer change if the field is a currency amount?

Related qa engineer questions

Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.

Predict my questions

Rehearse the hard questions before they are asked

Practise with a live copilot, then walk in ready. A $29 Session Pass gets you through the interview with no subscription and no lock-in.

Get GhostPilot