QA & Testing Phrases: Reporting Bugs and Quality Issues
5 exercises on professional QA and bug-reporting phrases. Choose the most natural and professional option.
0 / 5 completed
1 / 5
Which phrase is the most professional way to say you were unable to replicate a reported bug?
I couldn't reproduce this on my machine: This is the standard QA phrase for reporting that a defect was not observed in your environment. It is factual, neutral, and professional — it doesn't dismiss the reporter or blame their setup. Option A is too informal. Option B is dismissive and sounds defensive. Option D is unprofessional as it implicitly blames the reporter. In real testing conversations, this phrase opens a collaborative investigation: you would follow up by asking for steps to reproduce, environment details, and logs.
2 / 5
A feature has been delivered but it doesn't meet the agreed requirements. Which phrase best describes this?
The acceptance criteria weren't met: Acceptance criteria are the agreed conditions a story must satisfy to be considered done. Using this phrase links the issue directly to the Definition of Done — the professional standard for delivery. It is objective and specific, which matters in QA reviews and sprint retrospectives. Option B is vague and informal. Option C assigns blame without evidence. Option D deflects responsibility to requirements, which is counterproductive. Always refer to acceptance criteria rather than vague expectations when raising quality issues.
3 / 5
A bug that was fixed in a previous release has appeared again. Which phrase is the standard way to describe this?
This is a regression from the last release: A regression is a specific testing term for functionality that previously worked correctly but has broken again — usually due to new changes introducing unintended side effects. Using "regression" immediately signals the nature of the defect, helps prioritise it, and tells developers to look at recent changes. Option A is informal and doesn't use the technical term. Option C is vague and non-technical. Option D sounds frustrated and unhelpful for triage. In professional QA, regressions are typically labelled in the bug tracker and assigned high priority.
4 / 5
You want to flag that a module doesn't have enough automated tests. Which phrasing is most appropriate?
The test coverage for this module is low: Test coverage is a measurable metric — typically expressed as a percentage of code lines, branches, or functions exercised by automated tests. Referring to it precisely is the professional approach in code reviews and QA discussions. Option A implies blame without being constructive. Option B introduces emotional language ("risky") without specifics. Option C is a vague personal worry rather than an objective observation. Mentioning test coverage naturally leads to action: checking coverage reports, writing unit tests, and adding the module to a testing backlog.
5 / 5
You want to flag an issue as one that must be fixed before release. Which phrase is correct?
I'd mark this as a blocker: In bug-tracking systems such as Jira, GitHub Issues, and Bugzilla, "blocker" is the highest severity/priority label — it means the release or a specific workflow cannot proceed until the issue is resolved. Using the correct label term is essential for clear communication between QA, developers, and product managers. Option A is emotional and non-specific. Option C is informal and doesn't use established severity terminology. Option D is unprofessional. Saying "I'd mark this" also shows ownership and initiative rather than just complaining.