Как воспроизвести баг и что делать с теми, которые не воспроизводятся

Чаще всего баг-репорт умирает под статусом “Cannot reproduce” (не воспроизводится), и эту фразу стоит прочитать внимательно: она означает не то, что кажется на первый взгляд. Это утверждение не о самом баге. Это утверждение о двух окружениях: о том, где баг произошёл у автора репорта, и о том, где он не воспроизводится у вас.

Сам баг сомнений не вызывает: кто-то своими глазами видел, как он произошёл. Под вопросом другое: сможете ли вы воссоздать условия, которые для этого понадобились, и чаще всего репорт этих условий не содержит, потому что автор понятия не имел, какая из тысячи мелочей вокруг него имела значение.

Что на самом деле нужно для воспроизведения

Шаги являются лишь одной из четырёх составляющих, и именно о ней думают в первую очередь.

Те же шаги. Что человек нажимал, в каком порядке, начиная с точки, с которой можете начать и вы.

То же состояние. Аккаунт, права доступа, флаги функциональности, настройки, изменённые полтора года назад, недописанный черновик, лежащий в базе данных. Именно это чаще всего губит попытки воспроизведения, потому что состояние невидимо для человека, который в нём находится. Он не знает, что его аккаунт необычный. Для него это просто его аккаунт.

Те же данные. Не свежая тестовая запись, а именно та самая: заказ с оформленным возвратом, имя с апострофом, пустой список, загруженный файл на сорок мегабайт. Сгенерированные тестовые данные всегда аккуратные. Продакшен-данные представляют собой пятнадцать лет накопленных решений, а это тот же разрыв, из-за которого стейджинг вас обманывает.

То же окружение. Браузер и сборка, устройство, сеть, размер экрана, часы, расширения. Иногда достаточно одной только версии: “latest Chrome” за одну неделю означало три разные основные версии.

Это четыре оси, и репорт обычно фиксирует лишь одну из них. Работа по воспроизведению заключается в том, чтобы угадать остальные три, поэтому на это уходит целый день, и поэтому так часто всё заканчивается пожатием плеч.

Начинайте с состояния, а не с шагов

Первым порывом обычно бывает повторить шаги и посмотреть, что получится. Правильнее в первую очередь спросить себя, что должно быть верно, чтобы эти шаги привели к сбою.

Если оформление заказа ломается на этапе оплаты, сами шаги представляют собой три клика, которые может сделать кто угодно. Не универсальны корзина, адрес, способ оплаты, валюта и то, оформлялся ли когда-нибудь возврат по этому аккаунту. Разберитесь, что из этого могло повлиять на результат, и вы превратите расплывчатый репорт в три-четыре конкретных эксперимента.

Слабо

Повторили шаги на тестовом аккаунте. Всё работает. Закрыли со статусом «не воспроизводится».

Лучше

Шаги воспроизводятся на новом аккаунте без проблем. На аккаунте автора репорта сохранена карта в валюте, поддержку которой мы прекратили, и сбой происходит именно при поиске валюты. Воспроизвели, добавив такую же карту на тестовый аккаунт.

Второй вариант не требует больше усилий. Это те же усилия, направленные на правильный вопрос.

Сократите воспроизведение до минимума, при котором сбой всё ещё происходит

Когда сбой воспроизводится стабильно, начните убирать части. Уберите шаг, уберите поле, возьмите файл поменьше, отключите расширение, сократите данные. После каждого удаления либо сбой сохраняется, и тогда убранная часть была не нужна, либо сбой пропадает, и тогда вы только что нашли что-то важное.

Это стоит делать, даже если исправление уже готово, и вот почему. Минимальное воспроизведение становится тест-кейсом, который можно сохранить. А сам процесс минимизации очень часто находит причину ещё до того, как вы заглянули в код: баг, который сохраняется только при пустом списке, сам подсказывает, в чём дело.

Обращайте внимание на воспроизведение, которое срабатывает лишь иногда. Это не провалившаяся попытка, а баг другой природы, а нестабильность в этом случае является данными, а не шумом: где-то есть гонка потоков, зависимость от порядка выполнения или холодный кеш. Здесь действует та же логика, из-за которой нестабильный тест стоит расследовать, а не перезапускать.

Те, что невозможно воспроизвести в принципе

Некоторые сбои невозможно воссоздать на вашей машине, и никакая настойчивость этого не изменит. Распознать их пораньше полезнее, чем упорнее пытаться.

Нужны были их часы. Устройство с неверным временем даёт ошибки сертификатов, истёкшие сессии и невозможные временные метки. Именно в этом заключались три из пяти причин предупреждения о сертификате.

Нужна была их сеть. Корпоративный прокси, DNS-фильтр, captive portal, мобильный оператор, переписывающий запросы. Вы не можете подключиться к этой сети, а значит, не можете увидеть, что она делает.

Нужна была их сборка. Поэтапный релиз выкатил новую версию лишь части пользователей, и её нет больше ни у кого, включая вас.

Нужен был именно тот момент. Деплой на середине процесса, холодный кеш, сторонний сервис, который тормозил девяносто секунд. Состояние, вызвавшее сбой, перестало существовать ещё до того, как был написан репорт.

Нужны были их расширения. Что-то, встроенное в страницу, изменило её. У вас другие расширения, значит, и страница у вас другая.

В таких случаях вопрос не “как это воспроизвести”, а “что было верно в тот момент, и могу ли я это ещё выяснить?”

А это аргумент в пользу того, чтобы фиксировать всё сразу

Каждый пункт из этого списка невидим постфактум, но дёшево фиксируется в момент, когда всё происходит. Консоль в момент сбоя. Упавший запрос с его статусом и таймингом. Сборка браузера, размер экрана, URL. Ничего из этого не требует, чтобы автор репорта знал, что важно, а в этом и вся сложность, потому что он никогда этого не знает.

Это и есть аргумент в пользу репорта, который несёт в себе доказательства, а не их описание. Воспроизведение представляет собой способ восстановить информацию, которая была выброшена, и оно обходится дорого именно потому, что эта информация была выброшена.

Как правильно расспросить автора репорта ещё раз

Если всё же приходится возвращаться с вопросами, спрашивайте о том, на что человек действительно может ответить, а не о том, что вам хотелось бы увидеть в репорте.

Плохо: “пожалуйста, укажите точные шаги для воспроизведения”. Человек и так уверен, что уже это сделал.

Лучше, и у каждого из следующих вопросов неплохая результативность:

• В какое время это произошло и какое время сейчас показывает ваше устройство? Это два вопроса, а не один. Разница между ответами позволяет поставить диагноз.
• Это случалось больше одного раза? Если это произошло один раз, это просто момент. Если повторяется, это уже состояние.
• Происходит ли это в другой сети, например при использовании мобильного интернета вместо wifi?
• Что именно написано на экране? Нужны сами слова, а не их пересказ.
• С кем ещё вы можете это воспроизвести? Другой аккаунт сужает круг до данных, а другой человек на том же аккаунте сужает его до устройства.

Руководство по баг-репортам описывает полную структуру хорошего репорта, а частые ошибки разбирают то, что чаще всего упускают.

Что написать, когда вы сдаётесь

Иногда воспроизвести действительно не получается, и в этом случае закрыть репорт будет правильным решением. Не закрывайте его просто со статусом «не воспроизводится» и ничего больше не пишите, потому что эта фраза ничего не скажет следующему человеку, и он потратит на это точно такой же день, что и вы.

Напишите, что вы пробовали. Какой аккаунт, какой браузер и сборку, какие данные, какие из четырёх осей вы варьировали, а какие не смогли. Тогда следующий репорт о том же самом, от другого человека с другой деталью, не станет стартом с нуля. Это будет вторая точка данных, а два репорта, у которых совпадает одна необычная деталь, обычно и есть весь ответ.

Это и есть честная версия статуса. Баг не был опровергнут. Он не был воспроизведён при имеющейся информации, а это совсем другое утверждение, и оставить его после себя гораздо полезнее.