Complete English Guide for QA Engineers

Why English Matters for QA Engineers

Quality assurance is fundamentally a communication discipline. A QA engineer who discovers a critical bug but cannot describe it clearly enough for a developer to reproduce it has not fully done the job. A test plan that is ambiguous or incomplete leads to missed edge cases and disputed test results. Acceptance criteria written in vague language become the source of endless "is this a bug or a feature?" debates at the end of a sprint. In QA, English precision is not a soft skill — it is a core engineering competency.

The English required for QA spans multiple formats: the structured, evidence-based language of bug reports; the procedural, step-by-step language of test cases; the collaborative language of sprint planning and acceptance criteria; the technical vocabulary of test automation frameworks; and the persuasive language of advocating for quality standards in conversations with product managers and developers. Each format has its own conventions.

QA engineers also produce some of the most read documentation in a product organisation. A well-written bug report is read by the developer who fixes it, the developer who reviews the fix, the QA engineer who verifies the fix, and anyone who later searches for related issues. Test plans are referenced throughout a release cycle. Runbooks for manual regression testing are used by multiple team members. The investment in writing clearly pays dividends throughout the product lifecycle.

This guide covers the key registers and vocabulary of professional QA communication in English. Whether you are writing your first bug report or preparing for a QA interview at an international tech company, these sections will help you communicate with the precision and professionalism that quality assurance demands.

Section 1: Bug Report Writing

A good bug report is one that a developer can pick up, understand immediately, and reproduce without asking follow-up questions. This requires a specific structure and a specific level of detail — not too vague, not so long that the key information is buried.

Bug Report Structure

A standard bug report includes: Title, Environment, Steps to Reproduce, Expected Result, Actual Result, Severity, Priority, and Attachments (screenshots, logs, video). Each section has its own language conventions.

The title should be a short, factual description of the symptom — not the hypothesised cause. Bad title: "Login is broken." Good title: "Login form submits with empty email field — no validation error displayed." The title should include: what the component is, what action was taken, and what the unexpected result was.

Steps to Reproduce

Steps to reproduce are written as numbered instructions in the imperative mood, with enough detail that someone who has never used the feature can follow them exactly: "1. Navigate to /settings/account. 2. Click 'Change Password'. 3. Enter a new password in the 'New Password' field. 4. Leave the 'Confirm Password' field empty. 5. Click 'Save Changes'." Use present tense imperatives: "Click," "Enter," "Navigate," "Select," "Verify." Do not write "I clicked" (past tense) or "You should click" (second person instruction with "should").

Expected vs. Actual Result

The "Expected Result" and "Actual Result" sections should be parallel in structure — both describe the same moment in time, but one says what should happen and one says what does happen. Write in the present tense: Expected: "An error message 'Passwords do not match' is displayed below the Confirm Password field. The form is not submitted." Actual: "No error is displayed. The form submits successfully. The password is saved without the confirm field being validated." This parallel structure makes the discrepancy obvious at a glance.

Environment and Reproducibility

Specify: browser name and version, operating system and version, application version or build number, any relevant configuration (logged in as which user type, which feature flags are enabled). State reproducibility explicitly: "Reproduced 5/5 times" or "Intermittent — reproduced 3/10 times on page load." If you have identified conditions that affect reproducibility, note them: "Occurs only when logged in as an admin user, not reproducible with a standard user account."

Section 2: Severity & Priority Language

Severity and priority are often confused, but in professional QA they have distinct meanings. Severity describes the technical impact of the bug on the system. Priority describes the business urgency of fixing it. A cosmetic misalignment in the UI is low severity but might be high priority if it is on the homepage of a major product launch. A data corruption bug in an admin-only tool might be high severity but low priority if only five people use that tool and they have a workaround.

Severity Levels

The standard severity scale (most teams use a variation of this): Critical — the application crashes, data is lost or corrupted, or a core user journey is completely blocked with no workaround ("The payment flow throws a 500 error — users cannot complete a purchase."). High — significant functionality is broken, but a workaround exists or the impact is limited to a subset of users. Medium — a feature behaves incorrectly but the impact is minor or the workaround is straightforward. Low — cosmetic issues, minor UX inconsistencies, or issues with negligible user impact.

When assigning severity, justify it: "Severity: Critical — this affects all users attempting to log in. No workaround is available." / "Severity: Medium — the export function produces an incorrectly formatted CSV, but users can manually reformat the output."

Priority Language in Bug Triage

Bug triage meetings use language like: "Let's prioritise this one — it's on the critical path for the release." / "I'd argue this should be P2, not P3 — we're seeing it affect 15% of our active users based on error logs." / "Can we defer this to next sprint? It's a known limitation, not a regression." / "This needs to be fixed before we go live — it violates our GDPR compliance requirements." The vocabulary of triage is negotiation vocabulary — you are advocating for a position using evidence.

Section 3: Test Plan Documentation English

A test plan is a document that describes the scope, approach, resources, and schedule for testing a feature or release. It is read by QA engineers, developers, product managers, and occasionally senior leadership before a major release. It needs to be clear to all of these audiences.

Test Plan Language Conventions

Test plans use formal, third-person language (or passive voice in British convention): "The following test plan covers the user authentication module for release 2.4.0." Scope sections define what is in scope and explicitly what is out of scope — the "out of scope" section is important because it sets expectations: "Out of scope: performance testing under load. This will be covered in a separate performance testing initiative." Approach sections describe the testing methodology: "Manual exploratory testing will be used for edge case discovery. Regression testing will be performed using the existing automated Cypress suite."

Test Case Language

Individual test cases within a test plan or test management tool follow a specific structure: Test Case ID, Title, Preconditions, Steps, Expected Result, and Pass/Fail status. Titles use the format "Verify that [system] [does X] when [condition]." Examples: "Verify that the login form displays an error message when an invalid email format is entered." / "Verify that the session is invalidated when the user logs out." "Verify that" is the standard prefix — it is more precise than "Test that" or "Check that" because it implies you are confirming an existing specification.

Section 4: Acceptance Criteria Language

Acceptance criteria define what "done" means for a user story. Poorly written acceptance criteria are the most common source of scope disputes, failed sprint reviews, and "is this a bug or a feature?" arguments. Writing clear, testable acceptance criteria is one of the highest-value skills a QA engineer can contribute to an agile team.

Given-When-Then Format

The industry standard format for acceptance criteria is Given-When-Then (also called Gherkin syntax): Given [a precondition], When [an action is performed], Then [an expected outcome occurs]. This format forces testability because every criterion must specify exactly what state the system should be in. Example: "Given a logged-in user with a Standard plan, When they attempt to export more than 100 records, Then an error message 'Export limit reached — upgrade to Pro to export more than 100 records' is displayed, And the export is not initiated." The "And" keyword extends either the Given, When, or Then clause.

Writing Testable Criteria

Acceptance criteria must be verifiable — you must be able to answer "did this pass or fail?" with a yes or no. Untestable: "The page should load quickly." Testable: "The page should load in under 3 seconds on a 4G connection for 95% of users." Untestable: "The form should be user-friendly." Testable: "The form should display inline validation errors for each field, should auto-focus the first invalid field on submission attempt, and should not require page reload."

Common red flags in acceptance criteria: "should be" (subjective) needs to be replaced by "must be"; "etc." is never acceptable — enumerate what you mean; "and so on" — same problem; percentages or quantities without baselines — "should handle high traffic" needs to specify what "high" means.

Section 5: TDD & BDD Vocabulary

Test-Driven Development (TDD) and Behaviour-Driven Development (BDD) are development methodologies with their own vocabulary that QA engineers need to understand and discuss fluently, both when working with developers and when presenting to stakeholders.

TDD Language

TDD follows the Red-Green-Refactor cycle: you write a failing test (Red), write the minimum code to make it pass (Green), then improve the code without changing its behaviour (Refactor). The language: "I'll write a failing test for the edge case first, then implement the fix." / "The tests are green — I'm now refactoring to clean up the implementation." / "We have 94% test coverage — the uncovered paths are the error branches in the payment processor." Test types in TDD: "unit test" (tests a single function or class in isolation), "integration test" (tests how multiple components work together), "end-to-end test" (tests a complete user flow in a real environment).

BDD Language

BDD extends the Given-When-Then format into actual executable test code using frameworks like Cucumber, SpecFlow, or Jest with BDD conventions. The vocabulary: "feature file" (a human-readable description of features written in Gherkin), "step definitions" (the code that implements each Given/When/Then step), "scenario" (a single test case in a feature file), "scenario outline" (a parameterised scenario with multiple data sets). "Living documentation" refers to the idea that BDD tests serve as up-to-date documentation of how the system behaves. "Three amigos" is the collaboration session between developer, QA, and product owner to agree on acceptance criteria before implementation begins.

Section 6: Defect Lifecycle Communication

A defect (or bug) moves through a lifecycle from discovery to resolution, and each stage generates communication between QA, developers, and product managers. Understanding the vocabulary of each state and the transitions between them is essential for managing defects effectively in tools like Jira, Azure DevOps, or Linear.

Defect State Vocabulary

Standard defect lifecycle states: New (just created, not yet triaged), Open (acknowledged and assigned), In Progress (developer is actively working on it), In Review (fix has been implemented, pending code review), Fixed (developer believes the fix is complete), In Testing (QA is verifying the fix), Verified (QA has confirmed the fix works), Closed (resolved and verified), Reopened (QA found the fix is incomplete), Deferred (decision to not fix in the current release), Won't Fix (decision to not fix at all).

When reopening a defect: "Reopening — the fix resolves the reported steps, but the underlying issue persists when the user accesses the same functionality via the API directly. New steps to reproduce: [steps]." When closing as Won't Fix: "Closing as Won't Fix — the behaviour is consistent with the existing system design for legacy accounts. Documented in the known limitations page."

Verification and Regression Language

After a developer marks a bug as Fixed, QA verifies it: "Verified fixed on build 2.3.1 in staging. Tested against the original reproduction steps and three additional edge cases — all pass." When a fix introduces a new problem: "The fix for #1234 resolves the original issue but has introduced a regression in the related search functionality — raising a new bug #1289." Regression testing language: "Running the full regression suite before the release." / "Targeted regression on the checkout flow — focusing on the areas changed in this release."

Section 7: Automation Testing Vocabulary

Test automation is an increasingly central part of the QA role, and the vocabulary spans multiple layers: the testing pyramid, specific framework vocabulary (Selenium, Cypress, Playwright, Jest), CI integration, and the language of test maintenance and reliability.

Testing Pyramid Language

The testing pyramid (unit → integration → end-to-end) is a foundational concept with specific vocabulary. "We need to shift the balance of our test suite — we have too many slow E2E tests and not enough unit tests. The testing pyramid suggests the inverse." / "This business logic should be covered at the unit level, not the E2E level — unit tests are faster and less brittle." / "Our test suite has too many brittle end-to-end tests that break on minor UI changes — we should mock the API layer for most scenarios."

Framework-Specific Vocabulary

Cypress vocabulary: "cy.intercept() to stub API calls," "custom commands," "test isolation," "beforeEach hook." Playwright vocabulary: "page object model," "fixtures," "parallel test execution," "tracing." Jest vocabulary: "mocking," "spying," "snapshot testing." General automation vocabulary: "selector strategy" (how tests find elements — prefer data-testid attributes over fragile CSS selectors), "test flakiness" (intermittently failing tests), "test isolation" (each test sets up its own state), "setup and teardown" (code that runs before and after tests).

Communication about test automation: "The Cypress test for the checkout flow is flaky — it times out on the payment step 20% of the time. I need to add a proper wait condition instead of using cy.wait(2000)." / "I've implemented the page object model for the authentication pages — this makes the tests more maintainable and reduces duplication." / "The test suite now runs in parallel across 4 workers — total execution time is down from 18 minutes to 5 minutes."

Most Useful Vocabulary & Phrases for QA Engineers

Recommended Learning Path for QA Engineers

1. 1

   Bug Report Writing exercises

   The most fundamental QA writing skill. Learn to write bug reports that developers can reproduce immediately without asking follow-up questions.

2. 2

   Testing & QA Lab exercises

   Comprehensive QA vocabulary and scenario exercises covering the full range of testing activities.

3. 3

   TDD & BDD Language exercises

   Given-When-Then format, acceptance criteria writing, and the vocabulary of test-driven development.

4. 4

   Testing & QA Vocabulary set

   Core terminology for software testing — defect lifecycle, test types, testing methodologies.

5. 5

   Documentation Types exercises

   Test plans, test reports, and other QA documentation formats and conventions.

6. 6

   Agile & Scrum vocabulary

   Sprint planning, bug triage, and the language of QA within agile delivery teams.

7. 7

   Technical Writing exercises

   Broader technical writing skills for QA documentation — test plans, runbooks, and process documentation.

8. 8

   QA Engineer Interview Questions

   Practice for QA interviews — testing methodology questions, scenario-based questions, and automation discussions.

Exercise Sets for QA Engineers

Practise the vocabulary and communication patterns covered in this guide with these focused exercise sets: