5 exercises — core testing terms: unit vs integration tests, E2E tests, mocks vs stubs, test coverage, and flaky tests. Essential for QA engineers and developers who write tests.
Key testing vocabulary clusters
Test types: unit · integration · E2E · smoke · regression · acceptance · performance · load · mutation
Test doubles: mock (records calls) · stub (returns preset values) · fake (working lightweight impl) · spy (wraps real impl)
Metrics: test coverage · line coverage · branch coverage · flakiness · pass rate · build time
What is the difference between a unit test and an integration test?
Unit tests test the smallest pieces of logic (a function, a method, a class) in isolation — all dependencies are replaced with mocks/stubs. They run fast (milliseconds) and are the base of the testing pyramid. Integration tests verify that multiple components interact correctly — e.g. a service + database, or two microservices communicating. They are slower and require more infrastructure. The testing pyramid: many unit tests (base) → fewer integration tests → even fewer end-to-end (E2E) tests (top). Related: system tests (full system), acceptance tests (meets business requirements), regression tests (existing behaviour hasn't broken).
2 / 10
Complete with the correct QA term: "The new feature is failing in production but all our tests pass — we need to add a _____ test that exercises the full user flow from login to checkout to catch this kind of issue."
An end-to-end (E2E) test simulates a real user flow through the entire application — browser, frontend, API, database, and any external services. Tools: Playwright, Cypress, Selenium. E2E tests catch integration bugs that unit and integration tests miss because they test the real system, not isolated parts. Trade-offs: slow (seconds to minutes per test), flaky (dependent on timing, network, external services), expensive to maintain. That's why there are fewer of them in the testing pyramid. Smoke tests are a subset of E2E tests — a small set of critical tests run after every deployment to confirm the system is basically working ("is the smoke alarm going off?").
3 / 10
In testing, what is a mock?
A mock is a fake implementation of a dependency (a service, database, or API) that records which methods were called, with which arguments, and how many times — allowing you to assert on interactions. Compare: stub (a simple fake that just returns preset values, no interaction tracking), fake (a lightweight working implementation — e.g. an in-memory database), spy (wraps the real implementation and records calls). The rule of thumb: use stubs when you only care about the return value; use mocks when you want to verify that a specific call happened. Over-mocking leads to brittle tests that pass even when the real integration is broken.
4 / 10
What is test coverage and why is 100% coverage not always a meaningful goal?
Test coverage (usually line or branch coverage) measures what percentage of code is executed when the test suite runs. Types: line coverage (which lines were hit), branch coverage (which if/else branches), path coverage (all execution paths). Why 100% isn't always meaningful: a line can be executed but not tested for the correct behaviour — you can have 100% line coverage with zero assertions. What matters is what you test, not just that you touched every line. High-coverage, low-quality tests give false confidence. Better signals: mutation testing (does changing the code break a test?), meaningful assertions, testing edge cases.
5 / 10
What are flaky tests and why are they a problem?
Flaky tests are non-deterministic — they sometimes pass and sometimes fail for the same codebase, with no code change. Root causes: timing issues (setTimeout, async races), test order dependencies (test A leaves state that breaks test B), external services (real network calls in tests), random data generation, shared mutable state. Why they're a serious problem: they erode trust in the test suite — developers start ignoring red CI builds ("it's probably flaky"). Fix strategies: add proper waits/assertions instead of fixed delays, isolate tests, mock external dependencies, run flaky tests in quarantine. Teams often track a "flakiness score" as an engineering metric.
6 / 10
Sarah (Lead QA) just posted this Slack message: 'Hey team, I'm seeing a high number of failing tests related to the new API endpoint. Initial investigations suggest intermittent network latency is causing timeouts. We need to investigate further and add more robust error handling.' Which term best describes the core issue Sarah is highlighting?
This situation involves unexpected failures due to external factors (network latency). A Performance Test specifically examines how a system behaves under load and identifies bottlenecks. Regression Tests are typically used when code changes cause existing functionality to break; this isn't that scenario. Integration tests focus on interactions between components, not transient network issues.
7 / 10
During a code review of a PR for a new payment gateway integration, David (Senior Developer) comments: 'I'm concerned about the lack of explicit validation on the amount field. We should add an assertion to ensure it's a positive number before processing.' What QA term does David most likely intend to convey with this comment?
Equivalence Partitioning is a technique where you identify sets of inputs that are treated the same way by a system. Ensuring the 'amount' field is positive falls under this category – it's an expected constraint that needs to be enforced. Boundary Value Analysis focuses on values at the edges of input ranges, while Input Validation is a general term for checking data, and State Transition Testing relates to system behavior across defined states.
8 / 10
Mark (Junior Developer) is creating a PR for a new microservice. He's using Postman to test the API endpoint and receives this response:
```json
{
"status": "200",
"data": {
"message": "OK",
"version": "1.2.3"
}
}
```
What does the 'version' field in this JSON response primarily represent from a QA perspective?
The 'version' field in an API response often serves as a way to track changes and manage compatibility. It indicates which version of the service or resource is being referenced. While the status code (200) confirms success, the other options are not typical representations of versioning metadata within an API response.
9 / 10
Elena (Test Automation Engineer) is explaining the concept of 'test doubles' to a new team member. Describe in your own words what a 'mock' object is and why it's used in software testing.
A 'mock' object is an imitation or surrogate for a component or system that a test needs to interact with. It's designed to simulate the behavior of that dependency without actually requiring the real thing to be available. This allows tests to run quickly and reliably, isolating the code being tested from external factors.
10 / 10
During a daily standup meeting, Ben (Developer) says: 'I've just run a test suite and it shows that 85% of the code paths are covered. I'm planning to add more tests to increase this number.' What is a key consideration regarding the interpretation of 85% code coverage from a QA perspective?
While code coverage is a useful metric, 100% isn't always achievable or meaningful. Achieving high coverage simply means that a large portion of the codebase has been executed during testing – it doesn't guarantee that all possible scenarios and edge cases have been adequately addressed. Focusing on critical functionality and potential risks remains more important than blindly chasing a high percentage.
What does the "QA & Testing Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to qa & testing vocabulary through 10 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 1 other vocabulary module. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.