Defect Report Language

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

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

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

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

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