5 exercises — practise using the correct English terms for regression, smoke, and sanity tests, discussing test coverage, and communicating go/no-go decisions.
0 / 10 completed
1 / 10
After a major sprint release, the QA team re-runs the entire existing test suite to confirm that previously working features have not been broken by the new changes. This is called:
Regression testing specifically targets the risk that new changes break existing functionality.
A smoke test is fast and shallow — it confirms the build is deployable and basic features work, but does not re-verify the entire suite. A sanity test is a targeted, narrow check on one recently changed area — not the full suite. Exploratory testing is unscripted and session-based. Only regression testing describes the systematic re-execution of existing test cases across the product to catch unintended side effects — making Option C the most accurate answer.
Key vocabulary:
• Regression test — re-execution of existing tests after a change to confirm no breakage
• Smoke test — quick, shallow check that the most critical paths work after a new build
• Sanity test — narrow, targeted re-test of a specific recently changed area
• Side effect — an unintended change in behaviour caused by a modification elsewhere in the code
2 / 10
A developer asks the QA lead during a sprint review: "What is our current test coverage for the payment module?" Which response is the most professional and informative?
Test coverage discussions require specific numbers, named components, and explanations for gaps.
Options A and B use hedge language ("most of it", "good", "around 70%") that signals imprecision and reduces trust. Option D deflects the question without answering it — unhelpful in a sprint review context. Option C provides exact percentages per component, identifies what the uncovered 18% represents (error-handling branches), and explains the mitigation (manual exploratory tests) — demonstrating QA mastery and enabling an informed conversation about release readiness.
Key vocabulary:
• Statement coverage — the percentage of code statements executed during test runs
• Branch coverage — the percentage of conditional branches (if/else paths) exercised by tests
• Error-handling branch — code paths triggered only by infrastructure failures, timeouts, or exceptions
• Exploratory test — an unscripted, experience-based test session that complements scripted automation
3 / 10
During regression testing, the QA team discovers a defect that prevents the order submission flow from completing. How should this be communicated to the sprint team?
A blocking defect in regression must be communicated with its Jira ID, impact scope, and an explicit call for a decision.
Option A is too casual — logging a bug without explaining its downstream impact fails to convey urgency. Option B is dismissive ("something to keep an eye on"). Option C is factually wrong: if the order submission flow is completely broken, it cannot be classified as non-blocking — calling something non-blocking when it is blocking creates serious release risk. Option D is correct: it names the defect (REG-112), specifies the blocking impact (other modules cannot be tested), and requests a formal team decision — giving leadership the information needed to act.
Key vocabulary:
• Blocking defect — a defect that prevents continued testing or release of affected functionality
• Non-blocking defect — a defect that does not prevent release; a workaround or deferral is acceptable
• Go/no-go decision — a formal team decision on whether to proceed with a release
• Dependent module — a feature or component whose testing depends on another module working correctly
4 / 10
At the end of a sprint, the QA engineer presents a test execution summary to the team. Which format is the most professional and actionable?
A sprint test summary must provide quantified metrics, open defect IDs, and an explicit release recommendation.
Options A and B are narrative summaries that lack the data precision stakeholders need to make release decisions. Option D deflects to a tool link without providing the summary itself — unhelpful in a standup or sprint review. Option C includes all the required elements: sprint identifier, total TCs, breakdown by status with percentages, open defect IDs by priority, and a clear recommendation — enabling the PO and SM to make an informed go/no-go decision on the spot.
Key vocabulary:
• Test execution summary — a report of test case results by pass/fail/blocked/not-run status
• P1 defect — a high-priority defect that must be resolved before release
• Conditional release — approval to proceed with deployment under specific conditions (e.g. fix two P1s first)
• Sprint velocity — the number of story points completed in a sprint, used alongside QA metrics
5 / 10
The QA lead must formally communicate the team's readiness for a production release. Which Go/No-Go statement is the most professional?
A professional Go/No-Go statement specifies the defect status by priority, deferred items, approval status, and exit criteria.
Options A and B use hedge language and lack supporting evidence — "I think" and "looks good" are not sufficient for a production release decision. Option D is equally vague — calling a No-go without specifying which defects or what threshold was not met leaves the team without direction. Option C is the professional standard: it confirms P0/P1 resolution, documents deferred P2s with formal sign-off, references exit criteria, and delivers a clear recommendation — creating an auditable release decision record.
Key vocabulary:
• Go/No-Go decision — a formal binary release recommendation based on defined criteria
• Exit criteria — the defined conditions that must be met for testing to be declared complete
• Deferred defect — a known issue acknowledged but intentionally postponed to a future sprint
• Business sign-off — written approval from product ownership to accept a known risk or deferral
6 / 10
Alex, a junior developer, posts in the #devs Slack channel: 'Smoke test failed!'. Ben, the QA lead, replies with: 'Can you provide more detail about the failure? Specifically, what steps did you take before running the test and what was the exact error message?' Which of these responses best exemplifies proactive communication during a smoke test failure?
This scenario tests requesting specific information – a core part of effective communication. Option A is dismissive and doesn't encourage problem-solving. Option B is confrontational and unproductive. Option C focuses on the technical detail needed for debugging, and option D lacks urgency and a clear plan for resolution; Ben's response demonstrates the correct approach by seeking actionable data.
7 / 10
Sarah, a QA engineer, is writing a PR description to explain a regression test result. The test failed due to a change in the API response format for user authentication. Which of the following descriptions is most effective?
The key here is clarity and context. Option A is vague and blames without explanation. Option B precisely identifies the root cause – the API format change – and clearly states the required action. Options C and D are inadequate because they lack technical detail and don't explain the impact of the change.
8 / 10
David, a developer, discovers that a critical feature in his code has not been covered by any automated tests. During a standup meeting, he says: 'I haven't tested this thoroughly.' Which statement is the most professional and constructive way to communicate this?
David's original statement is insufficient and potentially problematic. Option A shifts blame. Option B acknowledges the gap in test coverage and outlines a plan to rectify it – demonstrating ownership and proactive behavior. Options C and D avoid responsibility and rely on others, which isn't professional.
9 / 10
Emily, the QA lead, is preparing a report summarizing test results for a new feature. The report needs to clearly indicate whether the feature is ready for release. Which Go/No-Go statement is most appropriate?
This question assesses understanding of Go/No-Go decisions. Option A is reckless and ignores potential risks. Option B provides a balanced assessment – acknowledging passing smoke tests while highlighting the need for further testing - demonstrating a cautious approach. Options C and D are simply status updates and don't address readiness for release.
10 / 10
Mark, a senior developer, is reviewing a colleague's code that implements a new user registration flow. The colleague has added a smoke test to verify the basic functionality. Mark comments: 'This test only covers the core logic; it doesn't handle edge cases like invalid email formats or rate limiting.' What is the most constructive way for the colleague to respond?
Mark's feedback is valid and highlights a crucial aspect of testing – comprehensive coverage. Option A demonstrates willingness to improve. Option B acknowledges the initial focus but proposes a plan for expansion, demonstrating an understanding of the broader testing strategy. Options C and D are dismissive and fail to address the identified weaknesses in the test suite.
This exercise, "Regression & Smoke Test Communication", tests your understanding of testing & qa lab vocabulary and phrasing through 10 multiple-choice questions drawn from real workplace scenarios.
Is this 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 presents a realistic 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.
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.
Who is this Testing & QA Lab exercise for?
It's designed for IT professionals and learners who want to sound natural discussing testing & qa lab topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
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 Testing & QA Lab exercises?
Browse the full Testing & QA Lab exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.