Дмитрий Ланецкий – QA и разработка на одном языке: Репорты, уточнения, «не воспроизвёлось» (страница 3)
ОС и версия,
сеть (Wi-Fi/мобильная, VPN/прокси),
аккаунт/роль (если влияет),
регион/язык (если влияет),
дата/время (если важно для логов).
7) Артефакты (Evidence)
Скриншоты, видео, HAR-файл, логи, консоль, crash report.
Если ничего нет – пишем «нет», чтобы читатель не искал призрак.
8) Частота (Frequency)
100% (всегда)
часто (например, 7 из 10)
редко (например, 1 из 20)
один раз (не повторилось)
Без частоты сложно понять: это системная поломка или космический луч поразил память.
9) Серьёзность и влияние (Severity/Impact)
Серьёзность – насколько ломает систему (краш/потеря данных/блокер).
Влияние – насколько больно пользователям/бизнесу (сколько людей, сколько денег, какой риск).
Это разные оси, и путать их – любимая ошибка.
Ожидаемое vs фактическое: маленький трюк против путаницы
Часто люди описывают «фактическое» через ожидание: «не открылось», «не сохранилось», «не работает». Это как описывать преступника словами «не тот парень».
Сделайте фактическое наблюдаемым:
что появилось на экране?
какой текст ошибки?
какая кнопка стала неактивной?
сколько секунд зависало?
что было в консоли/логах?
какой код ответа (для веб/API)?
Пример:
Плохо: «Не проходит оплата».
Лучше: «После подтверждения Apple Pay экран остаётся на спиннере 30+ секунд, затем появляется toast “Ошибка операции” без кода. В консоли: 500 на /payments/confirm.»
Разработчик читает это и сразу понимает: «О, 500. Значит сервер или интеграция. Идём в логи по времени».
Чем баг отличается от фичи: граница, которую надо обозначать
Самая дорогая переписка в жизни продукта – это спор «это баг или так задумано». Чтобы не открывать философский факультет внутри Jira, в репорте должна быть привязка к норме:
ссылка на требование/макет/спеку/прошлое поведение,
или короткая формулировка «в версии X работало так-то»,
или «в документации/FAQ описано иначе».
Даже если нормы нет (бывает), вы честно пишете: «Ожидание основано на…» – и это уже лучше, чем молчать.
Дубликаты и вариации: как писать так, чтобы ИИ и люди находили совпадения
В больших продуктах один и тот же баг может быть описан двадцатью способами. И люди, и алгоритмы лучше сопоставляют репорты, когда в них есть «якоря»:
точные названия экранов/модулей,
одинаковые ключевые термины (название кнопки, endpoint),
текст ошибки (как есть),
версия и платформа.
Так вы помогаете не только текущему фиксу, но и чистоте бэклога.
Два уровня репорта: для всех и для тех, кто будет дебажить
Иногда репорт пишет человек без доступа к логам или без технического контекста. Это нормально.
Поэтому удобно мыслить в двух слоях:
Слой A: пользовательский (обязательный)
Шаги → ожидание → факт → окружение → артефакты (скрин/видео).
Слой B: диагностический (если есть доступ)
Консоль, логи, коды ответов, трассировки, идентификаторы запросов, crash report.
Если у вас только слой A – репорт всё равно может быть отличным.
Если есть слой B – он становится «премиальным», и чинится обычно быстрее.
ИИ как автосборщик структуры
Вот типичный сценарий, который экономит часы:
Вы пишете «сырое» описание человеческим языком: что делали и что увидели.
ИИ превращает это в структуру: Title, Steps, Expected/Actual, Environment, Frequency, Impact.
ИИ задаёт 3–5 уточняющих вопросов по делу, чтобы закрыть пробелы.
Важно: в хорошей постановке вопроса ИИ не спрашивает «расскажите подробнее», он спрашивает конкретно:
«Какая версия приложения/сборки?»
«Повторяется ли в другой сети без VPN?»
«Какой браузер/устройство?»
«Есть ли текст ошибки или код?»
«Можете ли вы приложить видео 10–15 секунд до клика и после?»
Так рождается репорт, который реально ускоряет Time-to-Fix.