Technical English guide
QA Vocabulary in English: Test Plans, Severity vs. Priority, and Release Sign-off
October 21, 2026
The words QA and test engineers need beyond basic bug reports: test plans, test cases, acceptance criteria, severity versus priority, and the language of release sign-off.
Our guide on explaining a bug in English covers the vocabulary any developer needs for standups, tickets, and Slack. This one is different: it's for the artifacts and decisions that are specific to the QA role, the ones that show up before and after a bug report, not inside one. How to Explain a Bug in English.
Key Takeaways
- A test plan states the objective and scope of testing before you write a single test case: what you are testing and, just as importantly, what you are not.
- A test case always has four parts: precondition, steps, expected result, and actual result.
- Severity and priority are different axes. 'This is high severity but low priority' is a normal sentence, not a contradiction.
- 'Sign-off' means a formal, stated approval, not just silence. If nobody says 'QA has signed off,' assume it has not happened.
- A smoke test checks that the build is stable enough to test at all. A regression test checks that old features still work after a change.
Writing a test plan
A test plan is the document that states what you are going to test and why, before you write a single test case. In English, the key is stating scope explicitly, including what is out of scope.
“The objective of this test plan is to verify the new checkout flow before the release.”
States the goal in one sentence, at the top of the document.
“In scope: payment methods, discount codes, and order confirmation emails.”
Lists exactly what will be tested.
“Out of scope: performance testing and third-party integrations, which are covered in a separate plan.”
Stating what you are not testing prevents misunderstandings later.
“Entry criteria: the build must be deployed to staging and the smoke test must pass.”
States what has to be true before testing can start.
“Exit criteria: all P0 and P1 test cases pass, with no open blockers.”
States what has to be true before testing can be considered done.
Writing a test case
A test case is more structured than a bug report. In English, it follows the same four-part shape every time, so anyone on the team can run it the same way you did.
“Precondition: the user is logged in and has at least one item in the cart.”
States what must be true before you start the test.
“Steps: 1) Go to the cart page. 2) Click 'Apply discount code'. 3) Enter 'SAVE10'. 4) Click 'Apply'.”
Numbered, one action per step, no ambiguity.
“Expected result: the total updates to reflect a 10% discount.”
What should happen if the feature works.
“Actual result: the total does not change and no error message appears.”
What actually happened. This is where you report the test as failed.
“This test case is blocked because the discount code field is not rendering.”
Use 'blocked' when you cannot even execute the steps.
Acceptance criteria
Acceptance criteria define when a feature is considered 'done.' The Given/When/Then format is common on English-speaking teams, but a plain sentence works just as well.
“Given a logged-in user with items in the cart, when they apply a valid discount code, then the total updates immediately.”
The classic Given/When/Then structure.
“Given an expired discount code, when the user applies it, then an error message explains that the code has expired.”
Always write a criterion for the failure case too, not just the happy path.
“This is done when a user can complete checkout with a saved card in under three clicks.”
A plain-English alternative to Given/When/Then. Equally valid.
“Acceptance criteria met. Moving this to 'Ready for QA'.”
What you say when development is complete and ready for testing.
Severity vs. priority, and release language
Severity describes how bad the bug is. Priority describes how soon it needs to be fixed. Confusing the two is one of the most common mistakes for non-native English speakers in QA.
“This is high severity but low priority: it crashes the app, but only for an internal admin tool nobody uses yet.”
Severity (technical damage) and priority (business urgency) do not have to match.
“This bug is low severity but high priority: it is just a typo, but it is on the homepage right before a big launch.”
A small bug can still be urgent for business reasons.
“We ran a smoke test on the new build and it passed, so QA can start.”
A smoke test is quick: it just confirms the build did not break completely.
“Before sign-off, we need a full regression pass on the payment module.”
A regression test re-checks old, already-working features after a change.
“QA has signed off on this release.”
The explicit phrase that means testing is complete and approved. Silence does not count as sign-off.
“This build is not release-ready: there are two open blockers in the payment flow.”
The phrase for saying a release cannot go out yet, with the reason.
QA vocabulary table
Vocabulario de QA
Terms you will use constantly once you move past 'there is a bug' into the language of test planning and release readiness.
| Term | Translation | Definition | Example |
|---|---|---|---|
| test plan | plan de pruebas | The document stating the objective, scope, and schedule of testing for a feature or release. | The test plan for the new onboarding flow is ready for review. |
| test case | caso de prueba | A single, specific scenario to test, with a precondition, steps, and an expected result. | I wrote 12 test cases for the new discount code feature. |
| precondition | precondición | What must be true before a test case can be executed. | The precondition for this test is that the user has an active subscription. |
| expected / actual result | resultado esperado / resultado real | What should happen if the feature works correctly, versus what actually happened when you ran the test. | Expected result: a success message. Actual result: the page just reloads with no message. |
| acceptance criteria | criterios de aceptación | The specific conditions a feature must meet to be considered complete and correct. | This story has three acceptance criteria, and the last one is not implemented yet. |
| smoke test | prueba de humo / smoke test | A quick test that checks whether a build is stable enough to test further, not a full test pass. | The smoke test failed, so QA cannot start testing this build yet. |
| test coverage | cobertura de pruebas | How much of the feature or codebase is actually being tested. | Test coverage for the checkout flow is still low; we are missing cases for failed payments. |
| blocker | bloqueante | An issue serious enough that testing, or the release, cannot continue until it is fixed. | This is a blocker: I cannot test the rest of the flow until login works. |
| sign-off | aprobación formal / sign-off | A formal, explicit approval that a release or feature is ready, stated out loud or in writing, never assumed. | We are waiting on sign-off from QA before we deploy to production. |
| release-ready | listo para release | The state of a build that has passed all required testing and has no open blockers. | This build is release-ready as of this morning. |
| pass / fail | aprobado / fallido | The final verdict of a test case: whether the actual result matched the expected result. | Of the 40 test cases in this run, 38 passed and 2 failed. |
| test run | ronda de pruebas | One full execution of a set of test cases, usually against a specific build. | This is the second test run against the release candidate build. |
FAQ
What's the difference between severity and priority in QA?
Severity measures how much technical damage a bug causes: does it crash the app, corrupt data, or just look wrong. Priority measures how urgently it needs to be fixed, based on business impact. A bug can be high severity and low priority, or low severity and high priority. Good bug reports state both axes separately.
What does 'sign-off' mean in a software release?
It's the formal, explicit statement that testing is complete and a release is approved to ship, usually written as 'QA has signed off on this release.' It is never implied by silence: if nobody has said the words, assume it has not happened yet.
What is the difference between a smoke test and a regression test?
A smoke test is a quick check that a new build is stable enough to test at all. A regression test is a broader pass that re-checks features that already worked, to make sure a recent change did not break them. Smoke test first, then the full regression pass.
How do I write acceptance criteria in English?
The most common format is Given/When/Then. A plain sentence works too: 'This is done when a user can complete checkout in under three clicks.' Always write at least one criterion for the failure case, not just the happy path.
Related articles
Ready to practice your English at work?
Lingua-e has interactive exercises built around real developer conversations: standups, code reviews, retrospectives, and more. Practice until it comes naturally.
Try Lingua-e for free
Written by
Roxana LafuenteLingua-e's founder
Roxana Lafuente is a software engineer with 8+ years of experience. At the beginning of her career, even though she had already passed the First Certificate in English, she still froze every time she had to speak up in the daily standup. That was a gap nobody was fixing. After 2,000+ standups, she figured out what actually builds fluency: practice that looks like your real work. She built Lingua-e so other developers wouldn't have to take the long road to feel confident working in an international development environment.