5 exercises — practise writing daily async updates, sprint test summaries, QA sign-off statements, showstopper escalations, and known gap communications.
0 / 10 completed
1 / 10
A QA engineer needs to post an asynchronous daily status update in the team Slack channel. Which message is the most professional?
An asynchronous QA status update must identify completed items, blockers with owners, and next steps.
Options A and D share the same flaw: they say nothing actionable. "Will update later" and "no major issues" give stakeholders zero information. Option B is slightly better in tone but still vague — "a couple of issues" without IDs or ownership is not actionable. Option C is the professional standard: it specifies the date, names each story, gives execution results, links the blocker to a Jira ID and owner, and announces the next planned item — all without requiring a meeting to extract the information.
Key vocabulary:
• Asynchronous update — a status message posted to a shared channel without requiring real-time presence
• ETA (Estimated Time of Arrival) — the expected time a blocked item or fix will be resolved
• Blocker — an impediment preventing progress on a task or test case
• TC execution — running test cases against the feature under test
2 / 10
At the end of Sprint 18, the QA lead presents the sprint test summary to stakeholders. Which summary provides the most complete and actionable information?
Sprint test summaries must deliver quantified data, defect IDs by priority, and an explicit recommendation — in the message itself.
Options A and B use relative language ("most", "productive", "pretty low") that is meaningless without a baseline. Option C redirects stakeholders to another tool, providing no value in the summary itself. Option D gives everything a decision-maker needs: sprint number, total TCs, status breakdown with percentages, defect count and priority split, the specific P1 Jira ID, and a concrete recommendation to hold one story — enabling an immediate go/no-go discussion.
Key vocabulary:
• Sprint summary — a structured end-of-sprint QA report with metrics and recommendations
• P1 defect — high-priority defect requiring resolution before release
• P3 defect — low-priority defect suitable for deferral to a future sprint
• Hold from release — a recommendation to exclude a story or feature from the current deployment
3 / 10
A QA lead needs to formally sign off on a feature for a production release. Which sign-off statement is the most professional?
A formal QA sign-off must reference the specific feature scope, list deferred items with their approvals, and state acceptance criteria status.
Options A and D are informal one-liners that provide no audit trail and leave stakeholders unable to determine what was tested or deferred. Option B states approval but gives no evidence — who approved what, for which scope? Option C is the professional standard: it names the feature and story IDs, confirms acceptance criteria were met, documents the deferred defect with its ID and workaround, confirms PM approval of the deferral, and delivers a clear release recommendation — creating an auditable record.
Key vocabulary:
• QA sign-off — a formal written approval confirming a feature meets quality standards for release
• Acceptance criteria — the defined conditions a feature must meet to be approved by the product owner
• Deferred defect — a known issue approved for postponement to a future sprint
• Workaround — a temporary alternative procedure that allows users to avoid a known defect
4 / 10
Ten minutes before a sprint demo, a QA engineer discovers that the core feature to be demonstrated is returning a 500 error on staging. How should they communicate this to the Scrum team?
A showstopper requires urgent, precise communication with a clear decision request — not minimisation or false assurance.
Option A downplays the issue ("small issue", "just wanted to mention it") when there is no time to minimise. Option B suggests concealment — a serious professional and ethical failure. Option C is factually false. Option D is the correct approach: it flags urgency, identifies the defect precisely (500 error, Jira ID), gives two concrete options for the team, names who has been notified, and explicitly requests a decision — all in a format that can be quickly read in under 10 seconds during a crisis.
Key vocabulary:
• Showstopper — a critical defect that prevents a demo, release, or key process from proceeding
• 500 error — an HTTP Internal Server Error indicating server-side failure
• SM (Scrum Master) — the team facilitator responsible for removing impediments
• PO (Product Owner) — the stakeholder responsible for sprint scope and release decisions
• Recorded walkthrough — a pre-recorded video of the feature used as a fallback for live demos
5 / 10
A team is releasing a feature where one edge case — bulk export with over 10,000 items — was intentionally not tested due to a data pipeline dependency. How should the QA engineer communicate this in the release notes?
Known testing gaps at release must be named precisely with their risk level and a monitoring plan — not hidden or vaguely mentioned.
Option A is a false statement and a risk — claiming full coverage when a gap exists creates liability. Option B is too vague and alarmist: "some scenarios might cause issues" without specifics is not useful. Option D is suitably honest but provides no detail about which scenario, why it was skipped, or what risk management is in place. Option C is the professional standard: it names the exact untested scenario, explains the specific technical reason for the gap, assigns a risk level, and documents the observability mitigation (Datadog alerts) — showing the team has thought through the risk responsibly.
Key vocabulary:
• Out of scope — explicitly excluded from the current test cycle with a documented reason
• Risk assessed as Low/Medium/High — a formal evaluation of the likelihood and impact of the untested gap
• Observability — the ability to monitor, detect, and diagnose system behaviour in production
• Datadog alert — a production monitoring notification triggered when a metric crosses a threshold
6 / 10
Liam, a QA engineer, is writing a comment on a code review for a new user registration endpoint. The developer has implemented basic validation but hasn't added error handling for invalid email formats. Which of the following comments would be most effective and professional?
Option 1 provides specific, actionable feedback focused on improving the code. It avoids vague statements and clearly outlines the necessary change. Options 2 & 3 are too general, while option 4 is overly assertive and potentially unproductive – a code review comment should be collaborative, not directive. It's important to suggest solutions rather than simply pointing out problems.
7 / 10
Sarah, the QA Lead, is drafting a Slack message to the development team regarding a critical bug found during regression testing. The bug impacts core functionality and requires immediate attention. Which of the following messages best conveys urgency and clarity?
Option 1 clearly communicates the severity of the bug using 'URGENT' and specifies the affected module. It directs the team to take immediate action. Options 2 & 3 are too informal or lack urgency. Option 4 is misleading as it suggests everything is fine when a critical issue has been found.
8 / 10
David, the QA engineer, is writing the description for a Pull Request introducing a new API endpoint. The API returns JSON data with detailed information about product inventory. Which of the following descriptions best summarizes the API's purpose and structure?
Option 1 is too brief. Option 2 explicitly states the purpose of the API (accessing inventory data) and describes the key fields included in the JSON response. This provides developers with immediate context on how to use the API effectively. Options 3 & 4 lack detail and don't explain the structure of the returned data.
9 / 10
Maria, a QA Lead, is preparing to sign off on a feature for release. The team has been working with a complex data model and a dependency on a third-party service. During the final review, she discovers that the documentation doesn't fully detail how to handle potential timeouts from this external service. Which of the following statements would be most appropriate for her sign-off?
Option 1 is incomplete and doesn't address potential risks. Option 2 correctly identifies the missing information (timeout handling) and requests a necessary update to the documentation before final sign-off. Options 3 & 4 are too hasty and don't allow for proper risk assessment or mitigation.
10 / 10
Ben, a QA engineer, is updating the release notes for a new version of an application. The team intentionally skipped testing a specific edge case – importing large CSV files (over 10,000 rows) – due to dependency on a data pipeline that wasn't yet ready. Which sentence best explains this decision in the release notes?
Option 2 is a neutral statement that doesn't mislead users about the feature set. Option 1 would be misleading as it implies full functionality. Option 3 clearly and honestly explains why the edge case wasn't tested, providing context for potential limitations. It's crucial to be transparent about what *wasn't* tested, rather than trying to hide it.
This exercise, "QA Status Reporting", 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.