О чем: Как описывать ошибки разработчикам и QA так, чтобы их не закрыли с пометкой "Cannot Reproduce". Баг-репорт — это не жалоба, а инструкция к действию. Ваша задача — сэкономить время разработчика. Анатомия идеального репорта: Title (Заголовок): Максимум информативности. Плохо: "Кнопка не работает". Хорошо: [iOS 17] Payment button disabled after CVV input. Preconditions: Что должно быть в системе? (User is logged in; Cart has items). Steps to Reproduce (Repro steps): Нумерованный список действий как для ребенка. Actual vs Expected Result: Золотое правило QA. Expected: Payment should be declined with error 402. Actual: App crashes and logs out user. Environment: Устройство, ОС, версия сборки. Без этого баг закроют. Severity vs Priority: Severity: Насколько всё плохо? (Critical/Blocker/Major). Priority: Как быстро бизнесу нужно это починить? (P1/P2). Опечатка на главной может иметь Minor Severity, но Highest Priority перед запуском рекламы. Ключевая лексика (Lingo): Intermittent issue: «Блуждающий» баг (появляется иногда). Обязательно указывайте частоту: Occurs 1 out of 10 times. Regression: Регрессия. Баг там, где раньше работало (старый фикс сломали новым кодом). Edge case: Граничный случай (ввел -1 яблоко, имя из 10к символов). Методика REAL-SPEECH Екатерины Шитовой Мы учим переводить эмоции в факты: Bad: "The server sucks!" Good: "Dashboard latency exceeds 5s on 5xx errors." Используем структуру STAR (Situation, Task, Action, Result), чтобы описание бага было логичным доказательством, а не эмоцией. Если разработчик отвечает "Works on my machine", мы учим отвечать фактами со ссылками на критерии приемки (AC), сохраняя холодный тон (Cold Read). Описывайте проблему так, чтобы самый ленивый программист починил её за 5 минут по вашему тексту. Убирайте эмоции, оставляйте только Facts, Steps и Environment. http://realspeech.ru/