English for QA Engineers: Bug Reports, Test Plans, and Reviews (англійською)

Інженери QA виробляють дивовижно велику кількість письмової англійської щодня: звіт про помилку, плани тестування, тестові випадки, критерії прийняття, коментарі до перегляду і повідомлення про підписання випуску. Кожен тип документа має свою структуру, словниковий запас і очікування.

Цей посібник містить вміння англійської мови, які є найважливішими для інженерів з контролю якості, які працюють в англомовних або міжнародних командах.

---

Баг-рейтинги: Основний документ інженера QA

Звіт про помилку — це офіційний письмовий запис про помилку. Його метою є надати розробнику все, що йому потрібно для відтворення, розуміння і вирішення проблеми — без будь-яких переходів туди-назад.

Необхідна структура

Кожне повідомлення про помилку має містити ці розділи. Точна назва залежить від команди, але вміст є стандартним:

Section	What goes here
Title / Summary	One-sentence description of the bug
Severity / Priority	How bad is it? How urgently must it be fixed?
Environment	OS, browser, device, app version, backend environment
Steps to Reproduce	Numbered steps from scratch to the bug
Expected Result	What should happen
Actual Result	What does happen
Attachments	Screenshot, screen recording, log file

Словник заголовків

Заголовок - це перша річ, яку розробники читають. Зроби це конкретним і структурованим.

❌ “Вхід не працює” ✅ “[Auth] Форма входу заморожується на 3-5 секунд на Chrome 122, коли поле електронної пошти містить спеціальні символи”

Розпочніть заголовок з ** компонента або можливості ** у дужках, після чого вкажіть точний опис симптому.

Кроки для відтворення: нумеровані, імперативні

Записувати кроки у форматі нумерованого списку за допомогою ** імперативних дієслів ** (команд):

1. Європа Відкрити програму на https://app.example.com/login 2-й. Введіть будь- яку коректну адресу ел. пошти 3-й. Введіть пароль: Test@1234 4-й. Натисніть ** Вхід ** 5-й. Смотрите, как зарядка

** Примітка: ** Кожен крок описує одну дію. Не об’ єднувати декілька дій в один крок. Не приймайте за твердження, що розробник знає, як виглядає « сторінка входу » — починайте з адреси URL.

Очікувана проти. Фактичний результат

Це найясніший спосіб описати ваду англійською мовою.

** Очікувалося: ** Користувача перенаправляється на сторінку /dashboard протягом 1 секунди. ** Фактична: ** Завантаження спинера продовжується без обмеження. Переспрямування не відбувається. Повідомлення про помилку не показано.

Використовуйте нейтральну, фактичну мову. Уникайте емоційних слів, таких як “зламано”, “жахливо” або “очевидно неправильно”.

---

Складні і оригінальні слова

Інженерам QA регулярно потрібно повідомляти про серйозність (наскільки погано це впливає?) і пріоритет (як швидко це має бути виправлено?) помилок. Це не те саме.

Term	Definition
Critical / Blocker	The application crashes or a core workflow is completely broken. Blocks testing or release.
Major / High	Significant functionality is impaired, but a workaround exists.
Minor / Medium	The feature partially works. The bug has limited impact.
Trivial / Low	Cosmetic issue: typo, wrong color, minor layout misalignment.

Використовуйте ці терміни послідовно. Команди часто мають свою власну шкалу пріоритетів (P1-P4 або S1-S4), але вищезазначений словник є універсальним.

** Приклади речень: **

• « Це блокування — користувачі не можуть завершити процес отримання. » *
• “Я записую це як P2. Це важливо, але є обхідний шлях через API.”* “Встановлення цього на Тривіальне — це проблема з відображенням на старішій версії iOS, яка впливає менше ніж на 2% користувачів.”

---

Проводить тести та випробування

** План тестування ** це документ, який описує обсяг, підхід і розклад тестування можливості або випуску. ** Тестовий випадок ** є одним документованим тестовим сценарієм.

Тестовий план словникового запасу

“Ця програма тестування охоплює модуль автентифікації, включаючи входження, реєстрацію, скасування пароля і керування сеансами.”

• « За межами обсягу: сторонні провайдери OAuth (описано окремо у тестовому наборі інтеграції) ». *

• “Тестове середовище: сервер перевірки ( staging.example.com ) з виділеним тестовим базовою базою даних, що містить дані про пристрої.” *

• “Критерії успішного/ невдалого виконання: всі випадки тестування P1 і P2 повинні бути успішними. Помилки P3 будуть записані і сортовані в наступному спринті.”*

** Ключові терміни: **

• ** in scope / out of scope ** — що включено і що не включено
• ** критерії успішного проходження / критерії виходу** — умови завершення тестування
• ** димовий тест ** — мінімальний тест для перевірки, чи не повністю пошкоджено збірку
• ** тест регресії ** — перевірка того, що раніше працюючі можливості не були порушені
• ** крайовий випадок ** — незвичайна або межова умова вводу
• ** happy path ** — головний, очікуваний потік з коректними вхідними даними

Написання тестових випадків

Тестовий випадок складається з трьох необхідних частин:

** Попередня умова: ** Стан перед початком тестування. ** Кроки: ** Що робить тестер. ** Очікуваний результат: ** Що має статися.

** Приклад: **

** Тестовий випадок: ** Ел. пошта для скасування пароля буде надіслано за зареєстрованою адресою електронної пошти ** Попередня умова: ** У базі даних існує користувач з адресою електронної пошти test@example.com. ** Кроки: **

1. Європа Перейти до /forgot-password 2-й. Введіть test@example.com у поле Ел. пошта 3-й. Натисніть кнопку ** Надіслати посилання на скасування**

• Нет, не надо ** Очікуваний результат: ** Буде показано повідомлення про успіх. Користувач отримає повідомлення про скасування пароля через 2 хвилини.

---

Критерії прийняття мови

** Критерії прийняття ** (КП) визначають умови, які повинні бути виконані для того, щоб історія користувача або функція вважалися завершеними. Вони записуються як Given/When/Then інструкції (формат BDD) або як пронумерований список.

Формат «Дана/Коли/Тогда»

Це найпоширеніший формат у гнучких командах:

** Якщо вказано **, користувач не розпізнаний Когда они пытаются получить доступ к /dashboard ** Потім ** вони перенаправляються на /login з статусом 302

** Вказано ** користувач вводить некоректний формат електронної пошти Когда они подают регистрационную форму ** Тоді ** у рядку повідомлення про помилку буде написано: * « Будь ласка, введіть коректну адресу електронної пошти » *, і форма не буде надруковано

Формат контрольного списку з простою англійською

Деякі команди воліють простий список:

• ✅ Користувачі без автентифікації не можуть отримати доступ до захищених маршрутів
• ✅ Перенаправлення зберігають початковий запит URL у параметрі запиту ?returnTo=
• ✅ Куки сеансу використовують прапорці HttpOnly і Secure

Корисні фрази для написання AC

• « Система повинна / має… » * — формальне, часто використовується у специфікаціях
• « Користувач повинен мати змогу… » * — описує можливості користувача “In case that…” — обробка помилок/країн
• « Якщо [застосувати умову], тоді [результат] » * — умовний вираз
• « Функція вважається виконаною, коли … » * — визначає завершення

---

Результати тестування

В кінці циклу тестування, інженери QA повідомляють результати команді і зацікавленим сторонам.

Мова виходу

• “Тестування завершено. Всі тестові випадки P1 і P2 пройшли. Три проблеми P3 зареєстровані (#312, #314, #315) — жоден не блокує випуск. Підписання надано для випуску v2.4.0. *

• « Я не можу вийти з цього випуску. Потік отримання має блокувальник (див. ваду # 318). Це потрібно вирішити перед відправкою.»*

• “Часткове виключення: основна функціональність перевірена і пройдена. Мобільний платіжний потік все ще в процесі — я завершу до EOD. *

Відповідь на тести

• “Покриття: виконано 45 з 48 запланованих тестових випадків. 2 тести пропущено через проблеми з середовищем (не вдалося запустити базу даних). 1 тест заблоковано до виправлення розробником.” *

• “42 пройшли, 3 не пройшли, 2 пропустили. Звіт про тестування доступний в Confluence. *

---

Щоденні QA Communication Phrases

** Запит на пояснення щодо вимог: **

• “Критерії прийняття не вказують стан помилки для застарілого токена. Чи можете ви пояснити очікувану поведінку?»*

• “Це перевірена поведінка або не визначена? Якщо це не визначено, я рекомендую визначити його перед початком тестування.”*

Сповіщення про прогрес:

“Я завершив тестування димової частини на збірці. Немає критичних проблем. Перехід на тестування регресії зараз.”

“Я на 60% завершив тестовий план. Я очікую закінчити до кінця завтра.»

Ризик позначки:

*“Існує ризик — у нас немає тестових даних для кращих випадків у платіжному процесорі. Я б хотів відкласти підписання, поки це не буде вирішено». *

• “Ця область бази коду значно змінилася. Я б рекомендував повний регресійний прохід, а не тільки вибіркові перевірки.”*

---

Основні слова QA Vocabulary Reference

Term	Meaning
regression	Testing that old functionality still works after changes
blocker	A bug so severe it stops testing or release
flaky test	A test that sometimes passes and sometimes fails for no obvious reason
false positive / false negative	Test passes when it should fail / fails when it should pass
test harness	The infrastructure that runs automated tests
fixture / seed data	Pre-populated test data used to set up test scenarios
smoke test	Quick check to verify the build is minimally functional
sanity check	Informal term for a quick verification
exploratory testing	Unscripted testing — using the application to discover unexpected issues
repro steps	Short for “reproduction steps” — how to recreate the bug
intermittent / non-deterministic	A bug that only happens sometimes, not consistently
root cause	The underlying reason a bug occurred
workaround	A way to avoid the bug without fixing it

---

Інженери QA часто є останньою лінією оборони перед тим, як користувачі стикаються з помилкою. Якість вашого письмового спілкування — наскільки чітко ви описуєте ваду, наскільки точними є ваші описи AC, наскільки професійно ви повідомляєте про відмову — безпосередньо впливає на швидкість роботи вашої команди. Точність мови в QA не є приємною річчю; це робота.