Sample questions
Qa Api TestingDifficulty 1
Compared to a UI test that clicks through screens, what does an API test primarily check?
- aRequests and responses at the interface layer, without rendering any screen at all✓
- bThat every screen renders correctly across different browsers and window sizes
- cThat visual elements such as buttons and colors match the design file pixel by pixel
- dThat a human tester can complete a full task end to end using only the mouse and keyboard
Explanation:An API test talks directly to the interface underneath the UI: it sends a request and asserts on the status code, response body and side effects, with no screen involved at all. Rendering, layout and pixel-level checks (b, c) belong to UI/visual testing, and manual end-to-end task completion (d) is a different testing activity entirely.
Qa Api TestingDifficulty 2
A team notices their UI test suite takes 40 minutes and often fails for reasons unrelated to the feature being tested. They move the same checks down to API tests. What is the main practical benefit?
- aAPI tests automatically also verify that the screen looks correct, so nothing is lost by removing the UI checks
- bAPI tests skip rendering and UI timing, so they run faster and are less exposed to flakiness from the UI layer✓
- cAPI tests do not need any test data setup, because they talk to the database directly instead of going through the API
- dAPI tests replace the need for manual exploratory testing, since they cover every possible user path automatically
Explanation:Because an API test skips rendering, animations and UI timing, it runs in a fraction of the time and is not exposed to the instability that comes from waiting on screens — that's the layer advantage. It does not check how anything looks (a), it still needs realistic input data (c), and it doesn't replace exploratory testing (d), which targets different kinds of problems.
Qa Api TestingDifficulty 1
What is a contract test in the context of two systems — a consumer that calls an API and a provider that serves it?
- aA test that measures how many requests per second the provider can handle before it slows down
- bA legal document both teams sign before development starts, describing the API in plain language
- cA test checking the consumer's expected shape matches what the provider produces✓
- dA test that runs only after both systems are deployed together in the production environment
Explanation:A contract test captures what the consumer expects from an interaction (fields, types, required values) and checks that expectation against the provider, catching a mismatch before the two are integrated. Throughput measurement (a) is performance testing, a signed document (b) is not an automated test, and waiting until production (d) is exactly what contract testing is meant to avoid.
Qa Api TestingDifficulty 2
A mobile team's app expects the total field in an order response to be a number. A backend team quietly changes total to a string ("49.90") and deploys. Nobody notices until the mobile app crashes in production. What would have caught this earlier?
- aA larger manual QA regression pass covering more screens of the mobile app before each release
- bIncreasing the load test traffic so the backend team notices unusual response patterns sooner
- cAsking the backend team to write more unit tests for their own internal calculation logic
- dA contract test encoding the expected type of
total, run on every backend change✓
Explanation:This is exactly the break a contract test is designed to catch: the mobile team's expectation (total is a number) is encoded as a check that runs whenever the provider changes, failing the build before the field type ever reaches a real device. More manual regression (a) still depends on someone happening to check that field, load testing (b) measures capacity, not shape, and the backend's own unit tests (c) verify its internal logic, not what the consumer actually requires from the response.
Qa Api TestingDifficulty 1
In test design, what is the basic difference between a stub and a mock?
- aA stub returns a canned response when called; a mock also lets the test verify it was called as expected✓
- bA stub can only be used for database calls, while a mock can only be used for calls to external APIs
- cA stub is written by developers, while a mock is written exclusively by testers as part of manual test cases
- dA stub runs slower than the real dependency, while a mock runs exactly as fast as the real dependency
Explanation:A stub's job is to return a prepared answer so the test can proceed without the real dependency. A mock does that too, but also records the interaction so the test can assert on it — e.g. "was this call made exactly once, with these arguments". Neither is tied to a specific kind of dependency (b), both are written by whoever writes the test (c), and speed (d) isn't the distinguishing property between the two — it's the behavior-verification capability.
Qa Api TestingDifficulty 2
A test for POST /orders needs to call a third-party payment provider that charges a real fee per test run and is sometimes unavailable in the test environment. What is the most practical way to test the order logic itself?
- aSkip testing this endpoint entirely until the payment provider guarantees 100% uptime in every environment
- bReplace the payment provider with a test double returning a controlled response, then test the order logic✓
- cRun the test against the real payment provider once a month, since fees are only charged during that single run
- dAsk the payment provider's team to slow down their own service so the test has more time to complete reliably
Explanation:Using a test double for the payment call keeps the order test focused on its own logic (does the order get created, priced and stored correctly for a given payment outcome) without paying real fees or depending on the provider's availability — real-service behavior for the payment provider itself belongs to its own tests, ideally including a smaller number of true end-to-end checks. Skipping the endpoint (a) leaves it untested, monthly real runs (c) still leave most of the time uncovered, and asking a provider to change their service for your test (d) doesn't address the underlying dependency problem.