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

Давайте на этом примере рассмотрим способы отлова плавающих багов, о которых говорилось в прошлом посте.

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

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

3. Коммуникация с пользователями позволит Пете во время общения с пострадавшими узнать, что общего между ними, и довольно быстро понять, что связь – смена часового пояса.

4. Во время поиска похожих ошибок Петя может наткнуться на ошибку, заведенную очень давно и оставленную в бэклоге (разделе таск-менеджера для второстепенных задач), с описанием воспроизведения нашей ошибки. Или, например, найти сообщение об обратной, но связанной ситуации, когда доставка предмета приходила почти мгновенно, если перемотать время вперед.

5. Постепенно усложняя тесты, а именно добавляя новые действия, Петя через какое-то время перешел бы к проверкам влияния функций телефона на игру и заметил бы, что изменение времени на телефоне связано с изменением времени в игре. А упрощение, наоборот, помогло бы очистить шаги воспроизведения от бесполезных действий (например, покупки конкретных вещей в определенный период времени).

6. Проведение стресс-тестов поможет в случае менее тривиальных багов. Если, скажем, игра не рассчитана на некоторые слабые устройства, но может быть скачана, то произойти в ней может буквально что угодно. И именно стресс-тесты с параметрами, схожими с теми, что есть у жалующихся пользователей, позволят понять, что ошибка не в железе пользователей, а именно в их действиях. А может и наоборот показать, что ошибка стабильно воспроизводится на слабых устройствах и игре требуется оптимизация.

7. Расстановка ловушек, по сути, – самый универсальный способ охоты на баги. Петя не раз встречал ошибки, которые непонятно, как повторить, а у программистов были только теории, но уверенности не было. Именно ловушки помогают в таких ситуациях. Программист, имея несколько теорий, просто добавляет несколько строк кода, который в случае, если какая-то теория подтвердится, даст сообщение в логи или консоль. Со следующей версии, если ошибка повторяется, логи уже дадут однозначный ответ, что именно произошло.

8. И последний пункт даст Пете самое нужное для улучшения качества – время. С течением времени может произойти очень много разнообразных изменений с игрой. Возможно, ошибка будет исправлена во время оптимизации кода достаточно пытливым программистом. Возможно, достаточно подкованный пользователь даст точную информацию о том, что именно нужно сделать, чтобы сломать игру. Возможно, игра вообще будет переделана с 0, и исправление этой ошибки уже не будет иметь значения. А в то время как эти изменения будут происходить, Петя займется более важными задачами. Но если он будет следить за ситуацией, то ошибка обязательно будет найдена.

Недостатки методов

А теперь давайте посмотрим, в чём недостатки этих способов.
1. Подключенный со стороны человек имеет меньший опыт, а значит, может смотреть совершенно не имеющие отношение к проблеме вещи и просто потратит и без того драгоценное время.

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

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

3. Пользователи – один из самых ненадёжных источников информации. Среди них встречаются хитрецы, которые думают, что могут соврать о том, что они заплатили за инап, и награда за покупку не пришла. Встречаются те, кто пишет сообщения максимально неинформативно. И даже если пользователь добропорядочный, хочет помочь и пишет доступное сообщение в саппорт, он по незнанию проекта может напутать термины, элементы, механики. А это приведёт опять же к поиску ошибки там, где её нет.

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

5. Данный метод требует приличной экспертизы в понимании работы ПО, над которым работает QA. Если Петя не знает о зависимости времени игры от времени телефона, ему никогда не придёт в голову идея двигать время на телефоне.

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

6. Стрессовое тестирование зачастую открывает целую россыпь ошибок. И быстро разобраться в ней очень сложно. Также если ошибка вызвана не слабым железом, то этот метод вывалит на нас большое количество в данный момент не приоритетной работы.

7. Самый универсальный способ, но даже он в большинстве случаев требует нескольких итераций для успеха, т.к. ловушка может быть поставлена не там или не на то. Также здесь мы опираемся в первую очередь на скилл программиста и, следовательно, зависим от него.

8. Ожидание и мониторинг – хорошая практика, но, к сожалению, если ошибка критическая, время становится непозволительной роскошью.

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

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