Дмитрий Ланецкий – QA и разработка на одном языке: Репорты, уточнения, «не воспроизвёлось» (страница 4)
Артефакт: универсальный шаблон «Ноль домыслов»
Скопируйте и используйте как есть (в трекер, в чат, в форму).
Заголовок:
[Модуль/Экран] – [действие] → [проблема] (условие)
Описание (1–3 строки):
Что ломается и почему важно.
Шаги воспроизведения:
…
…
…
Ожидаемый результат:
…
Фактический результат:
…
Частота:
(всегда/часто/редко/один раз)
Окружение:
Продукт/версия:
Устройство/браузер:
ОС:
Сеть/VPN:
Аккаунт/роль:
Регион/язык:
Дата/время:
Артефакты:
(скрин/видео/логи/консоль/ID запроса)
Серьёзность / влияние:
(что блокируется, сколько пользователей/денег/риска)
Если в первой главе мы договорились, что репорт – это контракт, то во второй мы собрали юридический язык этого контракта: поля, которые уменьшают неопределённость. В следующей главе мы займёмся тем, что чаще всего рушит идеальные шаблоны: реальной жизнью, где баг «плавает», воспроизводится через раз и прячется за состоянием системы. Там нам пригодятся методы охоты.
Глава 3. Охота на «плавающие» баги: как ловить то, что появляется через раз
Есть баги честные. Они ломаются всегда, воспроизводятся по инструкции, стоят на месте и ждут, когда их починят.
А есть баги хитрые – «плавающие». Они возникают раз в десять попыток. Пропадают после перезапуска. Зависит «от чего-то». Иногда это сеть, иногда время, иногда состояние кэша, иногда – тонкая гонка (race condition), когда два события соревнуются за право случиться первым. Иногда – всё сразу, потому что вселенная любит сюрреализм.
Плохая новость: такие баги портят жизнь сильнее всех.
Хорошая новость: их можно ловить системно, если перестать воспринимать их как мистику.
Почему «иногда» – не описание, а старт расследования
Слово «иногда» в баг-репорте – как надпись на заборе «где-то тут клад». Это не информация, а приглашение к поиску параметров.
«Иногда» означает: существует скрытая переменная, которая меняет результат. Задача автора репорта – помочь сузить набор этих переменных.
Условно, мы хотим превратить «иногда» в что-то вроде:
«В 30–40% случаев при плохом LTE и включённом VPN после возвращения из фона запрос /sync уходит дважды, из-за чего UI зависает на спиннере».
Это уже не магия. Это гипотеза с проверяемыми условиями.
Принцип трёх осей: состояние, окружение, время
Плавающие баги почти всегда живут на трёх осях:
Состояние
Кэш, авторизация, заполненность данных, флаги/эксперименты, состояние корзины, наличие черновика, размер списка, прогретость приложения, фон/передний план.
Окружение
Устройство, версия ОС, браузер, сеть (Wi-Fi/мобилка), VPN/прокси, регион, язык, права доступа, производительность (low-end vs high-end), энергосбережение.
Время
Таймауты, задержки сети, последовательность событий, «успел/не успел», фоновые задачи, расписание сервера, дата/время, перегрузки.
Если вы при описании плавающего бага собираете данные по этим трём осям – вы уже играете на стороне победы.
Метрика вместо эмоций: частота как компас
Для плавающих багов частота – один из главных сигналов.
Недостаточно: «бывает».
Нужно: «примерно 2 из 10», «один раз за вечер», «всегда на первом запуске после установки», «только после 5–6 переключений вкладок».
Как это добывать без лаборатории:
повторить сценарий 10 раз и отметить, сколько раз проявилось;
менять только один фактор за раз (например, сеть) и снова 10 повторов;
фиксировать результат: «Wi-Fi: 0/10, LTE: 3/10».
Да, это звучит как научный метод. Потому что это он и есть, просто в миниатюре.
Тест «переключателя»: как быстро найти подозреваемого
Есть простой приём: выбираете фактор и «щёлкаете» им туда-сюда, проверяя корреляцию.
Примеры переключателей:
Wi-Fi ↔ LTE
VPN on ↔ off
режим энергосбережения ↔ обычный
новый аккаунт ↔ старый (с данными)