You found a bug. You know exactly what went wrong. But when you open Jira and start typing in English, the words don’t come out right. The dev team misunderstands, asks for clarification, and the bug sits unresolved for another sprint.
Sound familiar? This happens to many Vietnamese QA engineers and developers working in international teams. The problem isn’t your technical skill — it’s having the right English vocabulary and structure for QA communication.
This guide gives you the exact phrases, templates, and patterns you need.
Why Clear QA English Matters
In Vietnamese teams, you can say “bị lỗi khi bấm vào đây” and everyone understands. In an international team, vague descriptions like “it doesn’t work” or “the button is broken” waste everyone’s time.
A well-written bug report in English:
- Gets fixed faster (devs understand exactly what to reproduce)
- Shows your professionalism
- Reduces back-and-forth messages
- Builds trust with your international colleagues
Key Phrases for Bug Reports
Describing what happened
- "The application crashes when..."
- "The page fails to load after..."
- "The button does not respond when clicked on..."
- "The data is not saved when the user..."
- "An error message appears unexpectedly when..."
- "The field accepts invalid input such as..."Steps to reproduce
1. Navigate to [page/section]
2. Click on [element]
3. Enter [value] in the [field name] field
4. Click [button/submit]
5. Observe the resultUse “navigate to” instead of “go to” — it sounds more professional. Use “observe” at the end to signal “here’s what you should see.”
Expected vs Actual behavior
This is the most important part of any bug report. Always include both:
Expected behavior: The system should display a success message and redirect the user to the dashboard.
Actual behavior: The system shows a blank white page with no error message.Severity and Priority language
- "This is a blocker — the user cannot complete the checkout flow."
- "High severity: data loss occurs when..."
- "Low severity, but affects the user experience."
- "This is a cosmetic issue (alignment/spacing)."Example Bug Reports
Bad (what many Vietnamese QA write first):
“Login page have bug. When I click login it not work. Please fix.”
Good:
Summary: Login button unresponsive on Safari 17 — users cannot authenticate
Steps to reproduce:
- Open Safari 17 on macOS Sonoma
- Navigate to
/login- Enter valid credentials
- Click the “Sign In” button
Expected behavior: User is authenticated and redirected to
/dashboardActual behavior: The button does not trigger any action. No network request is sent. No error message is displayed.
Severity: Critical — affects all Safari users (approx. 18% of our user base)
Environment: Safari 17.2, macOS 14.3, Production
Writing Test Cases in English
Test cases should be simple, direct, and unambiguous. Use this structure:
Test Case ID: TC-001
Title: Verify successful login with valid credentials
Preconditions: User account exists with email "test@example.com"
Steps:
1. Navigate to the login page
2. Enter "test@example.com" in the Email field
3. Enter the correct password in the Password field
4. Click the "Sign In" button
Expected Result: User is redirected to the dashboard. A welcome message is displayed.Useful verbs for test case steps
| Instead of… | Use this |
|---|---|
| ”click the button" | "click”, “select”, “tap" |
| "write something" | "enter”, “input”, “type" |
| "check if" | "verify”, “confirm”, “assert" |
| "see the result" | "observe”, “note”, “inspect” |
Writing Review Comments in English
Code review is another area where Vietnamese developers often struggle to phrase things diplomatically. Here’s how to give feedback without sounding rude:
Suggesting changes (not demanding)
- "Could we consider using X here instead? It might improve readability."
- "I think this could be simplified to..."
- "Have you considered handling the edge case where...?"
- "This looks good, but we might want to add a null check here."Pointing out bugs
- "This will throw an exception if `user` is null."
- "I believe there's a race condition here — what happens if two users submit at the same time?"
- "The logic here seems off — this condition will always be true."Approving with comments
- "LGTM (Looks Good To Me) — just one minor nit."
- "Approved. Great improvement over the previous approach."
- "This is clean. One suggestion for future improvement..."Common Mistakes Vietnamese Speakers Make
1. Missing articles (a, an, the)
❌ “User cannot click button” ✅ “The user cannot click the button”
2. Wrong verb tense in bug descriptions
❌ “Button was not working” ✅ “The button does not work” (use present tense for current bugs)
3. Vague pronouns
❌ “It shows error when it loads it” ✅ “The modal displays an error when the page loads”
4. “Confirm” vs “verify” confusion
In QA English: “verify” means you check something is true. “Confirm” is more conversational. Use “verify” in formal test cases.
5. Translating too literally
❌ “The screen have problem display correctly” (direct translation from Vietnamese) ✅ “The screen does not display correctly”
A Cheat Sheet to Save
Starting a bug report:
“I’ve identified an issue where [describe].” “The following bug was found during [regression/smoke/exploratory] testing.”
Asking for clarification:
“Could you clarify the expected behavior for this scenario?” “Is this working as designed, or should I log it as a defect?”
Updating a bug status:
“I’ve retested this on build 2.3.1 — the issue is still reproducible.” “This appears to be fixed. Closing the ticket.”
Clear English in QA work isn’t about perfect grammar — it’s about giving your team enough information to act without asking follow-up questions. Start with the template above, and over time these phrases will become second nature.
The goal is simple: write a bug report so clear that someone who has never seen your product can reproduce the issue in under two minutes.
That’s the standard. Now you have the language to meet it.