5 exercises — practise writing precise bug titles, classifying severity and priority, documenting steps to reproduce, and escalating critical defects professionally.
0 / 10 completed
1 / 10
A QA engineer finds that clicking "Submit" on the checkout form with an empty email field does not show a validation error — the form submits silently. Which bug title is the most professional and useful?
A professional bug title must identify the component, the action, and the observable symptom.
Option A is too vague — "Submit button bug" gives no information about the failure mode. Option B is conversational and imprecise: "doesn't work correctly" is not a specific symptom. Option D identifies the component but not the exact behavior. Option C follows the ideal pattern: Component + Action + Symptom — it names the form (Checkout form), the trigger (submits), and the missing behavior (validation error not displayed), allowing developers to identify and reproduce the issue before even opening it.
Key vocabulary:
• Bug title — a concise, actionable description of the defect visible in issue tracker lists
• Validation error — a user-facing message that appears when input fails a business rule check
• Silent failure — when a system fails without providing any feedback or error message
• Symptom — the observable behavior that indicates a defect, distinct from the root cause
2 / 10
A defect causes the entire payment flow to crash, preventing any user from completing a purchase. The release is scheduled for tomorrow. Which classification is most accurate?
Severity describes the impact on the system; Priority describes the urgency of the fix.
Option A is wrong — a complete payment crash is never Minor severity. Option B uses Critical/P1 correctly, but Blocker/P0 is the highest tier reserved for defects that halt the entire testing or release process. Option D suggests a workaround exists, which contradicts the scenario. Option C is the most accurate: the payment flow is entirely non-functional (Blocker), and a release is imminent (P0 — fix immediately).
Key vocabulary:
• Blocker — the highest severity level; the application or feature cannot be used at all
• Critical — severe defect with a major impact, but a workaround may exist
• P0 — highest priority; must be fixed before any release proceeds
• P1 — high priority; fix required in the current release
• Severity vs. Priority — severity = how bad the defect is; priority = how urgently it must be fixed
3 / 10
A QA engineer is writing the "Steps to Reproduce" for a defect where a user's profile photo fails to upload in Chrome on Windows. Which description is the most professional format?
Steps to Reproduce must include environment, numbered atomic steps, and clear Expected vs. Actual results.
Option A is a note, not a reproducible set of steps. Option B has the right structure but lacks environment details, specific credentials, and file characteristics. Option D is a single-sentence description, not numbered steps. Option C is complete and professional: it states the environment (Chrome 124, Windows 11), uses specific test data (testuser@example.com, 2 MB PNG), lists numbered steps, and separates Expected from Actual — making the defect fully reproducible by anyone on the team.
Key vocabulary:
• Steps to Reproduce (STR) — numbered, ordered, atomic actions that consistently trigger the defect
• Environment — OS, browser, version, and device context needed to reproduce the issue
• Expected result — what the system should do according to requirements
• Actual result — what the system actually does, including exact error messages
• Toast notification — a brief, non-blocking UI message that appears temporarily on screen
4 / 10
In a defect report, the "Actual Result" field should describe:
The Actual Result field captures what the system did — not why, not what should happen, not how to fix it.
Option A describes root cause analysis, which belongs in a separate investigation field or comment — QA engineers should not speculate about code-level causes in a defect report. Option B describes the Expected Result field. Option D is a recommendation, which belongs in a comments section if at all. Option C is correct: the Actual Result must describe only the observable behavior — exact error text, specific data shown, precise UI state — so that developers and other QA engineers can reproduce and verify the issue.
Key vocabulary:
• Actual result — the observed system behavior during test execution
• Expected result — the behavior specified by requirements or acceptance criteria
• Root cause — the underlying code or design flaw that caused the defect
• Observable behavior — what a tester can see, measure, or record without making assumptions
5 / 10
A QA engineer discovers a data-loss defect in a production-candidate build 2 hours before a scheduled deployment. They need to message the development team in Slack. Which message is the most effective and professional?
Escalating a critical defect requires precision, urgency, and actionable information — without panic or vagueness.
Option A communicates urgency but is alarmist and unprofessional. Option B is far too casual and downplays the severity, risking the issue being ignored. Option C is professional in tone but lacks urgency — "when they get a chance" is inappropriate 2 hours before a deployment. Option D strikes the right balance: it identifies the defect by Jira ID, states the severity classification, describes the specific impact (data loss), proposes a team action (go/no-go discussion), and points to detailed evidence — all without panic or blame.
Key vocabulary:
• Go/no-go decision — a formal team decision on whether to proceed with a release
• Escalation — raising an issue to a higher level of attention or authority
• Blocker defect — a defect that prevents release or continued testing
• Evidence — screenshots, logs, or recordings that demonstrate the defect
• Data loss — a defect category where user data is permanently destroyed or made inaccessible
6 / 10
David, a senior developer, comments on a code review: 'This function seems to be missing proper error handling. It should catch potential exceptions and log them appropriately.' Which of the following best describes David's concern regarding this code snippet?
David's comment highlights a critical aspect of software quality: error handling. The core issue isn't simply documentation (option A), but rather the absence of mechanisms to gracefully manage unexpected situations that could lead to system crashes or data corruption. Option C is incorrect because robust exception handling is fundamental; option D misses the crucial point about stability and reliability.
7 / 10
Sarah, a QA analyst, is drafting the description for a new defect report. The issue involves intermittent failures during API calls related to user authentication. The response from the backend shows '503 Service Unavailable' errors intermittently. Which of the following descriptions best captures the severity and scope of this defect?
The key here is understanding the impact of intermittent failures. While '503' indicates service unavailability (option A), it doesn't fully represent the severity because authentication is a core function. Option C overstates the problem due to the intermittent nature; option D is too strong as it assumes complete unavailability. Option B accurately reflects that intermittent issues impacting authentication need thorough investigation and prioritization.
8 / 10
Mark, a test automation engineer, is preparing the PR description for a bug fix related to a race condition in a multi-threaded application. The original issue caused intermittent data corruption when multiple users simultaneously updated the same resource. Which of the following descriptions best summarizes the changes made?
Mark needs to clearly articulate the technical solution. Option A is too vague – 'basic unit tests' don't explain how the concurrency issue was actually addressed. Option B describes a simplistic approach without specifying the underlying problem. Option D focuses on monitoring rather than solving the race condition directly; option C precisely details the use of atomic operations and improved synchronization, which are crucial for resolving this type of defect.
9 / 10
Elena, a QA engineer, receives an API response indicating '429 Too Many Requests' when attempting to retrieve user data. The application is functioning correctly from the client side, and other users can access the same data without issue. Which of the following statements best describes the most appropriate course of action?
The '429 Too Many Requests' response suggests a server-side issue – likely rate limiting. It's crucial to investigate potential throttling or configuration settings on the backend (option A). Simply documenting the error (option B) isn't sufficient; assuming misconfiguration (option C) is incorrect, and providing user guidance (option D) doesn't address the root cause.
10 / 10
Ben, a project manager, needs to update the team during a daily standup. A critical defect has been discovered: a memory leak in the core application module is causing performance degradation over time. The build currently being tested contains the bug. Which of the following statements would be most effective for Ben to communicate this information?
Ben needs to be direct and prioritize the issue. Option A downplays the severity, while option B accurately describes the critical nature of the memory leak and the immediate need for action. Option C is vague and avoids responsibility; option D delays necessary correction and provides an unrealistic timeline.
This exercise, "Defect Report Language", 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.