QA interview questions for 1–2 years of experience

At this stage, practise explaining a feature you tested from requirement to result. Years of employment alone do not define skill; the questions below help show your actual scope. Any proposed answer should be adapted to real work or explicitly labelled as a hypothetical practice example.

Explain your own work

1. What did you personally do on your project?

Name a feature, the checks you designed, the evidence you collected and who reviewed the result. “I tested checkout” is too broad; explaining how you covered cart changes before payment gives the interviewer a concrete starting point. Distinguish executing an existing suite from designing it, and do not claim ownership of the entire team's work.

2. How do you turn a requirement into test cases?

Identify actors, inputs, states, expected outcomes and unclear rules. For a coupon with a minimum cart value, ask whether the threshold applies before or after tax and shipping, then test below, at and above the agreed boundary. Write a checkable expected total rather than “coupon should work,” and record unanswered questions.

3. How do you decide which tests to run first?

Start with changed behaviour and failures that would prevent useful testing or harm users. For checkout, verify a basic order path before spending time on layout details, then cover the risky pricing boundaries. Tell the reviewer what remains untested; priority is a choice about risk, not permission to mark skipped checks as passed.

4. How would you report a bug that another tester can reproduce?

Include build, environment, fake data prerequisites, exact actions, expected result and observed result. A screenshot of a wrong total is stronger with the cart values and rule used to calculate the expected amount. Do not include secrets or real customer data, and distinguish consistent reproduction from an intermittent observation.

Practical investigation

5. What do you do when a fixed bug is returned to you?

Run the original reproduction on the fixed build and record the result. Then check nearby behaviour that the change could affect, such as a valid coupon after fixing an invalid-code response. Reopening should explain the remaining mismatch; passing direct retest does not prove the entire application has been regressed.

6. How would you investigate a UI error with an API response?

Compare the action with its request and response in an authorized test environment. Check whether the request contains the intended fake data and whether the UI represents the response correctly. Do not conclude “backend bug” from a red message alone: the client might have sent the wrong field or interpreted a valid response incorrectly.

7. What database evidence would you collect after creating an order?

Locate the specific fake order by a stable ID, then compare relevant status and item records with the contract. Use read-only access and avoid broad production queries. Explain any asynchronous delay before declaring a missing row a defect; an immediate UI response may precede a downstream reporting update.

8. How do you explain automation when you only maintained tests?

Describe one change, such as replacing a brittle locator or improving data setup, and explain how you checked it. If you have only personal practice, label it that way. Saying that you used an existing page object is accurate; saying that you designed the framework is not unless you actually did.

Likely follow-up: What if the test passed after rerunning? Keep the initial failure and investigate timing, data and environment differences. A retry pass alone does not establish the cause.

Teamwork and preparation

9. What do you do with an unclear acceptance criterion?

Bring a concrete example to the responsible product or business contact. For an OTP expiry rule, ask about the exact boundary and whether requesting a new code invalidates the old one. Record the agreed behaviour and update tests; do not silently choose the implementation's current behaviour as the expected result.

10. How do you report progress during a sprint?

Say which behaviour was verified, what failed, what is blocked and what decision or help is needed. “Checkout tested except timeout recovery; waiting for a controllable test response” is actionable. A count of cases executed is supporting detail, not a substitute for describing uncovered risk.

11. How do you answer a coding question you have only practised?

State the contract, trace an example and write a small correct solution before optimizing. Test an empty input and one case that breaks the obvious naive approach, such as duplicate maximum values in a second-largest problem. Be clear that interview practice demonstrates the algorithm, not professional framework experience.

12. What should you prepare the day before an interview?

Revisit one feature, one defect and one lesson from actual work; remove confidential details. Practise a basic query and a short coding exercise, then prepare questions about onboarding and review. Avoid spending the whole session memorizing tool definitions you cannot connect to a task.

Practise it

Test one ShopLite flow, record expected and observed outcomes, and explain the result in two minutes. Keep a small evidence sheet for yourself; call it a practice project, not client experience.