Bug report англійською: кроки, очікуване й фактичне
Розробник відкриває Ваш тікет і бачить одне речення: The button doesn’t work. Яка кнопка, на якому екрані, що мало статися? Відповідей немає, тож баг чекає уточнення. Добрий звіт знімає ці питання ще до першого коментаря.
Заголовок, за яким баг знайдуть пошуком
Заголовок баг-репорту читають у списку, серед сотні інших. А ще його шукають. Через тиждень колега натрапить на ту саму помилку й введе в пошук назву екрана. Тому заголовок називає місце, симптом і умову.
Із QA на заняттях ми найчастіше розбираємо одну кальку. Українське «не працює» просить перекласти себе як doesn’t work. Але розробникові потрібен симптом. Кнопка неактивна: is greyed out. Сторінка вантажиться без кінця: keeps loading. Сума показує нуль: shows $0.00. Пишіть те, що бачите на екрані.
Steps to reproduce: одна дія в рядку
Кроки нумерують і пишуть наказовим способом. Один рядок, одна дія. Розробник проходить шлях Вашими очима й не гадає, що сталося між другим і третім кроком.
- Log in as a user with an empty cart.
- Add any item to the cart.
- Go to Checkout.
- Enter the code SAVE10 and click Apply.
Слово reproduce Cambridge Dictionary пояснює як «показати чи зробити щось знову». Кроки потрібні саме для цього: щоб баг повторився в іншої людини.
Перед кроками додають середовище: браузер, версію застосунку, тестовий акаунт. Помилка з Safari на iPhone може зовсім не відтворитися в Chrome на ноутбуці. У прикладі шаблону бага в документації GitHub для цього є окреме поле Environment. Там же стоїть прохання спершу пошукати, чи такий тікет уже є.
Expected і actual: два рядки, які не зливають
Очікуване й фактичне пишуть окремо. Expected result описує, що мало статися за вимогою. Actual result описує, що сталося насправді. В одному реченні факт злипається з Вашим висновком.
Expected не місце для докору. The button must work нічого не описує. Напишіть, що побачить користувач: The Pay button opens the payment form. Якщо вимогу вже записано в тікеті, перенесіть її звідти. Як такі вимоги формулюють, розбирає стаття про acceptance criteria англійською.
Тон теж важить. Звіт описує поведінку продукту, а не роботу людини. You broke the checkout читається як претензія. Checkout fails since build 2.4.1 читається як задача.
Severity і priority: два різні поля
Ці поля плутають навіть досвідчені команди. Severity відповідає на питання, наскільки баг шкодить продукту. Priority показує інше: як швидко баг треба виправити. У багатьох командах severity ставить тестувальник, а priority вирішує продакт чи лід.
| Ситуація | Severity | Priority |
|---|---|---|
| Застосунок падає на старті в усіх користувачів | critical | high |
| Звіт в адмінці, який відкривають раз на квартал, падає з помилкою | major | low |
| Друкарська помилка в назві компанії на головній | minor | high |
| Іконка в налаштуваннях зсунута на два пікселі | minor | low |
Позначка critical чи major не замінює опису наслідку. This is a terrible bug передає емоцію, а не наслідок. Напишіть, що втрачає користувач: Users can’t complete payment. Тоді рішення про priority ухвалять за хвилину. Коли ж баг кладе сервіс для всіх, одного тікета замало, і на допомогу приходить incident status update англійською.
Чотири питання від тестувальників
Що робити, якщо баг не повторюється вдруге?
Все одно писати, але чесно. Перший рядок кроків: Happened once, can’t reproduce yet. Додайте точний час, акаунт і скриншот. За часом розробник знайде запис у логахСкриншот чи відео?
Скриншот показує стан, відео показує шлях. Для бага в один клік досить скриншота з обведеною зоною. Якщо помилка з’являється після п’яти дій, запишіть коротке відео без звукуЯк англійською «плаваючий баг»?
Intermittent bug. Додайте частоту: Reproducible about 1 in 5 attempts. Без частоти розробник спробує раз, не побачить помилки й закриє тікет. Про нестабільний автотест кажуть flaky testЧи вистачить рівня B1, щоб писати баг-репорти?
Вистачить. Звіт тримається на коротких реченнях у Present Simple і наказовому способі. Складні конструкції тут лише заважають. Важче буде на дзвінку, де баг доведеться обговорювати вголосПеред кнопкою Create перечитайте звіт очима людини, яка не бачила Вашого екрана. Чи знайде вона баг за заголовком? Чи пройде кроки без жодного питання? Якщо так, звіт готовий. Далі черга розробника. Рядок Fixes в описі pull request закриє Ваш тікет сам.
Баг доведеться ще й обговорювати вголос, на дейлі чи в чаті. Цю частину роботи QA тренує англійська для тестувальників із баг-репортами та звітами про якість.