Как описывать баги так, чтобы их не закрыли с пометкой "Cannot Reproduce"
Для многих разработчиков баг-репорты от тестировщиков или пользователей — это белый шум. Разработчики часто закрывают задачи со статусом Not a Bug (Это фича) или Cannot Reproduce (Не смогли повторить), просто потому что описание было непонятным.
Хороший баг-репорт — это не жалоба, а инструкция к действию. Ваша задача — максимально сэкономить время разработчика.
Анатомия идеального баг-репорта
Чтобы баг починили, он должен быть Actionable (пригодным к действию).
1. Title (Заголовок) — 70% успеха Плохо: «Кнопка оплаты не работает». Разработчик видит сотни таких заголовков и ставит приоритет Low. Хорошо: [Payments] [iOS 17 / Safari] Payment button remains disabled after filling CVV field. (Включаем: Где? На чем? В каком месте?)
2. Precondition (Предусловия) Что должно быть в системе, чтобы баг случился?
- User is logged in.
- Shopping cart contains items.
- Dark mode is enabled. (Иногда важно).
3. Steps to Reproduce (Repro steps) Самый важный блок. Нумерованный список действий. Пишите как для ребенка:
- Navigate to the Checkout page.
- Enter an expired credit card number (4111...).
- Click the "Pay" button. (Не пишите «Попробовал оплатить», пишите алгоритм).
4. Actual Result vs Expected Result Золотое правило QA.
- Expected Result: The payment should be declined with error code 402. (Ожидаемый результат: Должна быть ошибка платежа).
- Actual Result: The app crashes and user is logged out. (Фактический результат: Приложение падает и выкидывает пользователя).
5. Severity vs Priority (Критичность против Срочности) Это разные вещи, которые новички всегда путают:
- Severity (Серьезность): Насколько сильно сломана система? (Crash, Data loss).Critical / Blocker: Система падает, данные удаляются.Major: Основная функция не работает.Minor / Trivial: Опечатка в тексте.
- Priority (Приоритет): Как быстро бизнесу нужно это починить? (P1, P2, P3).Пример: Опечатка на главной странице сайта банка имеет Minor Severity, но Highest Priority перед запуском рекламной кампании.
6. Environment (Окружение) Где именно упала система?
- Device: iPhone 14 Pro
- OS: iOS 17.4.1
- Browser: Chrome 124
- Build version: v.2.4.1-beta Без этого разработчик даже не будет пытаться искать ошибку.
Лексикон профессионального репорта (Lingo):
- Intermittent issue (Блуждающий баг): Баг появляется иногда, его сложно поймать. Обязательно добавляйте частоту: "Occurs 1 out of 10 times".
- Regression (Регрессия): Баг в том месте, которое раньше работало отлично. Это очень злит менеджеров, значит, старый фикс сломали новым кодом.
- Scope Creep (Разрастание скоупа): Когда вы просите починить кнопку, а вам заодно пытаются переписать всю базу данных. Держитесь исходного ТЗ.
- Edge Case (Граничный случай): Редкая ситуация (ввел -1 яблоко в корзину, имя из 10 000 символов).
Как мы тренируем это в REAL-SPEECH Екатерины Шитовой
Хотя наша школа специализируется на разговорном английском (Conversational English), логика описания дефектов абсолютно идентична логике ведения переговоров на английском.
1. Fact-based communication (Факты вместо эмоций) Типичная ошибка студента при описании проблемы — использовать эмоциональные оценки: "The server is super slow and it sucks!". Мы учим сухому деловому стилю: Bad: "Everything is broken!" Good: "I'm experiencing latency issues on the dashboard endpoint. Response time exceeds 5 seconds for 5xx errors." На наших тренингах мы переводим эмоции в бизнес-метрики.
2. Структура убеждения (Метод STAR) Описание бага — это микро-сторителлинг.
- Situation: Context (Preconditions).
- Task: What I tried to do (My goal was to export the report).
- Action: Steps taken (Steps to Reproduce).
- Result: Actual result vs Expected result. Использование этой структуры делает ваш баг-репорт неоспоримым документом.
3. Soft Skills: Pushback (Умение сказать "Нет") Если разработчик отвечает "Works on my machine" («У меня всё работает») или "It's not a bug, it's a feature", нельзя начинать кричать. Нужно вернуть мяч фактами:
- "I understand it works on your device. However, per our Acceptance Criteria (AC) in ticket #402, the behavior should be X. Here is the video evidence from real device." Мы учим студентов сохранять холодный тон (Cold Read) даже когда внутри все кипит. Конфликт убивает продуктивность команды.
Цель баг-репорта — не доказать, что вы умнее разработчика, а сделать продукт лучше. Описывайте проблему так, чтобы самый ленивый программист мог исправить её за 5 минут, просто следуя вашему тексту. Убирайте эмоции, оставляйте только факты, окружение и шаги воспроизведения. Ждем вас на обучение разговорному английскому!