Як написати звіт про помилку, який буде виправлений

Звіт про помилку — це документ для обміну інформацією. Його мета не просто записати, що щось не так — це дати іншій людині достатньо інформації, щоб відтворити проблему, зрозуміти вплив і ефективно її виправити. Погані звіти про вади спричиняють переговори, що йдуть туди- сюди, марнують час розробників, і іноді призводять до закриття вади як « неможливо відтворити ». Добрі звіти про вади отримують пріоритет і розв’ язуються.

---

Більшість з них не мають жодних відомостей

Найпоширеніші причини, через які звіти про вади ігноруються або втрачають пріоритет:

• ** Занадто нечітке **: « Програма іноді зазнає аварій » не дає розробнику майже жодних вказівок щодо того, що робити.
• ** Відсутні кроки відтворення **: Без знань про те, як викликати ваду, інженери не можуть підтвердити її існування або перевірити виправлення.
• ** Немає очікуваної поведінки у порівнянні з фактичною поведінкою **: Без знань про те, що має статися, неможливо перевірити, чи правильна виправлена поведінка.
• ** Неправильна оцінка тяжкості **: перебільшення тяжкості призводить до шуму; недооцінка тяжкості призводить до того, що важливі вади не враховуються.
• ** Поховано у прозі **: стіна тексту ускладнює швидке вилучення ключової інформації.

---

Ключовий словник

• ** Кроки відтворення ** (також: кроки відтворення, STR) — точна послідовність дій, необхідних для запуску вади
• ** Очікувана поведінка ** — те, що система повинна робити відповідно до специфікації або інтуїції
• ** Фактична поведінка ** — що система робить насправді, коли виникає вада
• ** Серйозність ** — вплив вади на систему або користувача (Критична, Висока, Середня, Низька)
• ** Пріоритет ** — ступінь критичності вади, яку слід виправити. Часто цей параметр встановлюється власником продукту
• ** Середовище ** — контекст, у якому відбувається помилка (ОС, переглядач, пристрій, версія збірки)
• ** Регресія ** — помилка, яку раніше було виправлено, але яка з’ явилася знову
• ** Періодична ** — вада, яка не виникає постійно, через що її важче відтворити
• ** Блокер ** — критична помилка, яка перешкоджає користувачеві виконати необхідну дію
• ** Обхід проблем ** — альтернативний підхід, який дозволяє користувачеві досягти своєї мети, незважаючи на ваду

---

Стандартна структура звіту про помилку

Добре написаний звіт про помилку має послідовну структуру. У кожного поля є мета.

Title

Заголовок має бути конкретним і мати можливість пошуку. Вона повинна описувати проблему, а не симптом у неясних термінах.

Weak title	Strong title
Login broken	Login button unresponsive after password reset on iOS 17.4
App crashes	App crashes when uploading image larger than 5MB on Android
Search doesn’t work	Search returns no results for queries containing apostrophes

Формула: ** [Компонент] [що не так] [коли/де/умова] **

Description

Опис містить контекст. Включити:

• Одним-двома словами объясните, что не так
• Коли вперше було помічено проблему (особливо для регресій)
• Як часто він відбувається (завжди, періодично, лише за певних умов)

** Приклад: ** « Потік скасування пароля не перенаправляє користувача на сторінку реєстрації після введення ним нового пароля. » Замість цього сторінку буде перезавантажено і буде показано ту ж саму форму з порожнім полем пароля. Ця поведінка відбувається постійно на пристроях iOS, на яких запущено Safari. Перший спостерігався в збірці 4.2.1.”

Кроки до відтворення

Це найкритичніша частина. Читай номери кроків. Будьте точними щодо того, який елемент ви клацнете, які дані ви введете і у якому порядку відбуватимуться події.

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

1. Відкрийте програму на iPhone 14 з операційною системою iOS 17.4 і Safari 17.
2. Натисніть « Забути пароль? » на екрані входу.
3. Введіть зареєстровану адресу електронної пошти і натисніть « Надіслати посилання для скасування »
4. Відкрийте лист і натисніть на посилання для скасування.
5. Введіть новий пароль і натисніть « Встановити новий пароль »
6. Спостерігати за поведінкою сторінки.

Очікувана поведінка

Скажіть, що має статися, простою, прямою англійською.

“Після натискання кнопки « Встановити новий пароль » користувача буде перенаправлено на вікно реєстрації з повідомленням про підтвердження: « Ваш пароль було оновлено. Будь ласка, зареєструйтеся»

Реальна поведінка

Зазначте, що саме відбувається замість цього.

“Сторінка перезавантажується і знову відображає форму скасування пароля з порожніми полями пароля. Повідомлення про підтвердження не показано. Новий пароль було збережено (користувач може увійти вручну), але перенаправлення не відбувається.”

Environment

Включити всі відповідні технічні параметри:

• iOS 17.4
• ** Версія браузера/програми **: Safari 17, App v4.2.1
• Пристрій:
• ** Тип облікового запису **: Стандартний користувач (проблема не відтворюється на облікових записах адміністратора)
• ** Мережа **: WiFi і мобільний зв’язок (обидві мережі)

Серйозність і пріоритет

** Серйозність: Висока ** — користувач не зможе завершити поток без збою. Вони можуть вважати, що скасування пароля зазнало невдачі.

** Пріоритет: Високий ** — впливає на шлях відновлення первинної автентифікації.

Attachments

Завжди включати:

• ** Знімок вікна **, що показує справжню поведінку
• Запис екрана, якщо вада має критичний час або включає послідовність подій
• ** Журнали консолі ** або повідомлення про помилки, якщо доступні
• Файл HAR (мережевий запис) для помилок, пов’ язаних з API

---

Виступає за національну команду

Під час написання звітів про вади для глобальної команди, ясність важливіша за красномовство. Використовуйте прості, прямі речення. Уникайте ідіом, сарказму або неоднозначності.

** Менш чітко: ** « Здається, пошук втратив рішучість, коли я ввімкнув деякі спеціальні символи. »

** Чистіше: ** « Функція пошуку повертає сторінку помилки (500), якщо запит містить символи & або %. »

Використовуйте ** активний голос ** для опису дії користувача і відповіді системи:

• «Користувач натиснув «Підтвердити»» (а не «Підтвердити натиснуто користувачем»)
• «Система показує помилку 404» (не «Показана помилка 404»)

---

Шаблон для копіювання і використання

**Title:** [Component] [problem] [condition]

**Description:**
[1-2 sentences explaining the problem and context]

**Steps to Reproduce:**
1. 
2. 
3. 

**Expected Behaviour:**
[What should happen]

**Actual Behaviour:**
[What actually happens]

**Environment:**
- OS:
- Browser/App version:
- Device:

**Severity:** Critical / High / Medium / Low
**Frequency:** Always / Intermittent / Rare

**Attachments:**
[Screenshot / Video / Logs]

Добре написаний звіт про помилку є актом поваги до інженерів, які його розслідують. Це знижує час, розчарування і показує професійну компетентність. Усі ваші зусилля, вкладені в написання чіткого тексту, обійдуться вам у багато разів швидше і точніше.

Навигація Нуанси: точна мова для міжнародних команд

Написання ефективних звітів про помилки не просто описує те, що не працює; це стосується чіткого і точного спілкування, достатнього для того, щоб ваші колеги — особливо ті, що вивчають професійну англійську — зрозуміли проблему і впровадили рішення. Поширеною перешкодою для носіїв мови, яка не є рідною, є використання надто нечіткої або неформальної мови, що може призвести до неправильного тлумачення і затримок у виправленні помилок. Давайте посмотрим на некоторые конкретные области, где осторожное выражение делает всю разницу.

По-перше, замініть розмовні вирази та ідіоми їх прямими еквівалентами. Замість того, щоб сказати « це дає змогу », що може бути розуміно метафорично, але може збентежити когось, хто не знайомий з цим виразом, скористайтеся « програма стикається з помилкою ». Аналогічно, уникайте фраз на зразок « щось не працює правильно » — набагато точніше буде сказати: « Кнопка не відповідає після натискання ». Таким чином ви продемонструєте увагу до деталей і уникнете неоднозначності. Зверніть особливу увагу на дієслова; «встановити» можна замінити більш формальною і описовою «розв’язати», «виправити» або «адреса»

Інша ключова область — опис * кроків * для відтворення вади. Типовий запит може бути таким: « Спробуйте натиснути кнопку ». Це недостатньо. Замість цього, надайте нумеровану послідовність: “1. Перейти до домашньої сторінки. 2. Натисніть кнопку « Надіслати », розташовану у правому верхньому кутку. 3. Зауважте, що сторінку не оновлено і не показано повідомлення про підтвердження. ” Цей рівень докладності надає розробникам точні інструкції, які потрібні для відтворення проблеми. Пам’ятайте, ваша мета не просто вказувати на проблему; це надати комусь іншому можливість її вирішити.

Наконец, подумай о тоне твоего доклада. Хоча розчарування зрозуміле, коли ви стикаєтеся з вадами, уникайте обвинувачувальної мови або звинувачування конкретних осіб. Сфокусировался на самой проблеме. Замість « Джон поламав його », напишіть: « Програма не змогла зберегти зміни після надсилання форми. » Професійний і об’ єктивний тон сприяє співпраці і запобігає обороні. Використання фраз на кшталт «Як результат…» або «Внаслідок…» допомагає чітко сформулювати вплив помилки. Пам’ятайте, що наша мета - сприяти продуктивному обговоренню і швидкому вирішенню.