Sample questions
Qa Api TestingDifficulty 3
A test sends
POST /accounts with an invalid email format and receives:
{"status": 200, "body": {"id": null, "error": "invalid email"}}
Why is this response poorly designed from an API testing point of view?
- aA 200 status signals success to any client checking status first, hiding the failure inside the body✓
- bThe response body should never contain the word "error" in it, regardless of what actually went wrong
- cThe
id field should contain a randomly generated placeholder value instead of null when creation fails - dJSON responses are not allowed to describe validation failures; only HTTP headers may carry error information
Explanation:Many clients (and simple monitoring) branch on the status code first; a 200 says "this worked", so a client that doesn't dig into the body will treat a rejected, invalid request as a success. The fix is a 4xx status (e.g. 400/422) that matches what actually happened, with the body detail on top. Avoiding the word "error" (b) is cosmetic and irrelevant, a fake placeholder id (c) would make a failure look even more like success, and error detail belongs naturally in the body regardless of headers (d).
Qa Api TestingDifficulty 3
A test needs to confirm not just that a notification service returns success, but that it was actually invoked exactly once with the correct recipient. Which kind of test double is the right fit, and why?
- aA stub, because stubs record every call automatically as a side effect of returning a response
- bThe real service, because only the real dependency can prove that the recipient value was correct
- cA mock, because a mock lets the test assert on the interaction itself — that it was called once, with the expected recipient✓
- dNo test double is suitable here; this kind of check can only be performed by manual inspection of production logs
Explanation:This requirement is about behavior verification (was the call made, how many times, with what arguments) rather than just supplying a canned result — that's precisely what a mock is for. A plain stub (a) returns a response but isn't designed to make call-count and argument checks part of the test's assertions. The real service (b) isn't needed to verify what arguments your own code passed to it, and a manual log check (d) is unnecessary when the same thing can be asserted automatically and repeatably.
Qa Api TestingDifficulty 3
A test creates a resource, checks it, and never deletes it. Run a hundred times in the shared test environment, the resource list grows to thousands of entries, and an unrelated GET /resources test starts timing out. What is the underlying problem?
- aThe
GET /resources endpoint has a bug and should be rewritten to ignore how many resources actually exist - bThe test environment's server needs more memory, since any endpoint will eventually slow down as data grows
- cNothing is wrong; a growing resource count is a normal and expected side effect of running tests repeatedly
- dThe creating test leaves data behind with no cleanup, polluting the shared environment for other tests✓
Explanation:A test that creates data but never removes it leaves permanent residue in a shared environment; over many runs that residue accumulates and starts affecting tests that have nothing to do with the original one — a symptom of tests not being properly isolated and self-cleaning. The fix is to tear down what was created (or use dedicated, disposable data) after each run. The listing endpoint isn't necessarily buggy for slowing down under a genuinely larger dataset (a), more memory (b) only delays the same underlying accumulation, and letting this continue unchecked (c) is exactly the practice to avoid.
Qa Api TestingDifficulty 3
A response is expected to satisfy:
id is an integer,
name is a non-empty string,
price is a number greater than zero. Given this response:
{"id": "7", "name": "", "price": 12.5}
Which statement about schema validation of this response is correct?
- aThe response passes, because
"7" can be automatically converted to the integer 7 in every schema validator - bThe response passes, because
price being positive is the only rule schema validation is able to check - cThe response fails, because
id is a string rather than an integer and name is empty rather than non-empty✓ - dThe response fails only because of
id's type; an empty string still counts as a valid non-empty string
Explanation:Against the stated rules, two things are wrong at once: id arrives as the string "7" instead of an integer, and name is an empty string, which does not satisfy "non-empty". A schema validator does not silently coerce types by default (a) — that would hide a real type mismatch — and schema validation checks structure and type constraints generally, not only numeric ranges (b); both listed violations are real, not just one of them (d).
Qa Api TestingDifficulty 3
A backend adds a new optional field discountCode to an existing response. The consumer's tests were written with a schema that marks unknown fields as invalid (additionalProperties: false, or equivalent). What happens, and what does this reveal?
- aThe consumer's tests fail on a purely additive change, revealing the schema is stricter than intended✓
- bNothing happens, because schema validation only ever checks for fields that are missing, never for fields that are unexpectedly present
- cThe provider's own tests fail immediately, since adding any field to a response is always a breaking API change
- dThe consumer automatically starts using
discountCode in its own logic, since schemas propagate new fields to consumers directly
Explanation:A schema that rejects any field it doesn't already know about treats a harmless, additive change as a break — the version compatibility problem here is in the test's own strictness, not in the API change. Loosening the schema to allow (and simply ignore) unknown additional fields lets genuinely compatible changes pass while still catching real contract violations like a missing or mistyped required field. Schema validation absolutely can flag unexpected extra fields when configured to (b), adding an optional field is additive, not inherently breaking (c), and a schema doesn't make a consumer start consuming a field on its own (d).
Qa Automation FundamentalsDifficulty 3
A test suite passes when tests run in a fixed alphabetical order but fails when run in a randomized order, which many CI tools use to surface flaky tests. Each test passes fine on its own. What does this most strongly indicate?
- aThe CI tool's randomization feature itself is malfunctioning
- bThe tests are flaky purely due to network timing, unrelated to order
- cSome tests depend on state left by tests run earlier alphabetically✓
- dThe suite simply contains too many tests to run safely at all
Explanation:Passing in one fixed order but failing under randomization, while each test is fine alone, is the signature of an order-dependency bug rather than a tooling defect. a assumes the tool is broken, which is far less likely than a real dependency; b and d don't explain why order specifically matters.