Test Results & Quality Vocabulary Collocations

Fail — the standard verb for a test that does not pass:

Tests fail — this is the fundamental, universal collocation in software testing. A test "fails" when the actual result does not match the expected result, or when the test itself throws an unexpected error.

The pass/fail binary:

• A test passes (✓) — the assertion holds, behaviour is as expected
• A test fails (✗) — the assertion does not hold, or an exception was thrown

Additional test result states:

• A test is skipped — marked with @skip, @ignore, or similar; not run
• A test errors — the test code itself threw an exception (different from a logical assertion failure)
• A test times out — exceeded its maximum allowed duration

"Broke" is used differently — "the build broke" or "the feature broke after the refactor." You would not say "3 tests broke." "Crashed" is used for processes and applications, not individual tests. "Stopped" is too vague and not a testing collocation.

Remember: "failing tests" is a compound adjective — "we have 3 failing tests in the auth module."

Passed and succeeded — both correct for a successful pipeline run:

Both passed and succeeded describe a CI pipeline that completed without failures. The choice depends on context and convention:

Passed: The most common and natural choice for tests and pipelines. "All checks passed." "The CI pipeline passed." This mirrors the pass/fail vocabulary used for individual tests. GitHub uses "All checks passed" in its PR status UI.

Succeeded: Used in CI/CD platform language. GitHub Actions shows "succeeded" for individual job steps. GitLab CI uses "pipeline succeeded." More common in automated system messages than in human conversation.

Finished: Describes completion but says nothing about success — "the pipeline finished but 3 tests failed." Always needs a qualifier. Never use "finished" alone to mean "passed."

CI/CD status vocabulary:

• "The build is green." → all tests passing (opposite: "red build" or "broken build")
• "All checks passed." → GitHub PR status message
• "The pipeline failed at the deploy stage."
• "The pipeline is running." → in progress
• "The pipeline was cancelled." → manually stopped

Code coverage and branch coverage — two valid specific types:

When a developer says "87% coverage," the full phrase depends on which type of coverage is being measured. "Code coverage" and "branch coverage" are both precise technical collocations:

Code coverage (also: line coverage, statement coverage): The percentage of source code lines or statements that are executed by the test suite. The most common type reported by tools like Istanbul, pytest-cov, and JaCoCo. "87% code coverage" = 87% of code lines are executed during tests.

Branch coverage (also: decision coverage): Whether every branch of every conditional statement (if/else, switch, ternary) has been tested. More rigorous than line coverage — a line can be covered while one of its branches is not. "87% branch coverage" is a stricter metric.

"Test coverage": The most generic term — it simply means coverage measured by tests. Less precise, often used colloquially when the specific type is not important.

Coverage vocabulary:

• achieve / reach / hit 90% coverage → common goal-setting language
• improve / increase coverage → when coverage is currently low
• measure / track coverage → tool-related language
• "uncovered lines / branches" → code not yet tested
• "coverage gap" → area of code without tests

Identified, found, discovered, caught — all correct with register differences:

All four verbs collocate naturally with "bug" or "issue," but they carry slightly different connotations and register levels:

Identified: The most formal and professional term. Used in bug reports, incident post-mortems, security advisories, and QA test reports. "The QA team identified a critical defect in the payment flow." Conveys systematic, deliberate analysis.

Found: The most neutral and universal term. Works in all registers — written reports, Slack messages, stand-ups. "I found a bug in the auth service." Very common.

Discovered: Slightly more emphatic than "found" — implies the bug was not obvious or expected. "The QA engineer discovered a race condition that only appeared under high load." Used in both formal and informal contexts.

Caught: The metaphor of catching suggests the test or the engineer intercepted the bug before it reached users. Very natural in QA language. "Our regression suite caught the bug before release." "Good catch!" (exclamation used when someone spots a bug in a PR review).

Other bug discovery verbs:

• detect a bug → often used for automated tools ("the scanner detected a vulnerability")
• spot a bug → informal, quick visual identification ("I spotted a bug in the UI")
• expose a bug → a test reveals a hidden bug
• reproduce a bug → confirm the bug occurs consistently

Found, detected, and flagged — all collocate with "vulnerability":

Security scanner output uses several verbs, and all three are natural and correct. The choice depends on the tool, the context, and what aspect you want to emphasise:

Detected: The most technical and automated-sounding verb. Used in security tool output and documentation. "Snyk detected 3 high-severity vulnerabilities." Implies the scanner performed active analysis and identified a specific condition.

Found: The most general and neutral term. Used in all contexts — security reports, Slack messages, stand-ups. "The scanner found 3 vulnerabilities." Natural and widely understood.

Flagged: Implies the tool raised a warning or alert about the item, drawing attention to it. Common in tools that produce a list of flagged items for human review. "Dependabot flagged 3 vulnerabilities in the package.json." The tool "flags" the issue; a human then decides what to do about it.

Vulnerability lifecycle vocabulary:

• identify / detect / find / flag a vulnerability → discovery phase
• assess / evaluate the severity → triage phase (CVSS score)
• patch / fix / remediate the vulnerability → resolution phase
• disclose a vulnerability → responsible disclosure to vendors
• exploit a vulnerability → an attacker takes advantage of it

Common tools: Snyk, Dependabot, OWASP Dependency-Check, Trivy, Grype.