Как надоели эти жуки...⁠⁠

Есть миф: “Ну вы же тестировали. Значит, багов быть не должно”. Мы бы тоже хотели жить в этом мире. Но реальность разработки такая, тесты ловят многое, но не ловят всё. Особенно в стартапе, где команда небольшая, а приложение должно работать у людей на тысячах разных устройств и в сотнях разных сценариев.

Какие бывают баги? Самые понятные — “грубые”, кнопка не нажимается, экран не открывается, платеж не проходит. Их обычно видно практически сразу. Но самые неприятные те, которые появляются редко и “по настроению”. Например:

• баг проявляется только на старом Android, а на новых всё идеально;

• всё ломается только при плохом интернете, когда связь то появляется, то пропадает;

• ошибка случается, если человек сделал действия в необычном порядке;

• баг возникает в момент, когда на сервер одновременно пришло много запросов;

• “что-то пропало”, потому что в одном месте обновилось, а в другом не успело.

Небольшой абзац про технический поиск и выявление багов, а именно логи: они помогают не гадать на кофейной гуще. Логи — это следы того, что происходило внутри приложения в момент ошибки (бага). Они помогают понять, где именно всё сломалось, особенно когда баг случился один раз и больше не повторяется по просьбе.

И дальше начинается настоящая работа, которую пользователь не видит. Мы пытаемся воспроизвести баг (и ловить его по логам), если о нем узнали, но не поняли когда точно и при каких обстоятельствах он случился. Потому что пока он не воспроизведён, он как призрак: “вроде был, но где неизвестно”. Обычно мы начинаем с простого, что делал человек, на каком устройстве, в каком месте приложения, был ли интернет, обновлялось ли приложение, происходило ли что-то параллельно. Потом пробуем повторить шаги один в один. Если не получается, то усложняем условия: слабее интернет, другой телефон, другой порядок действий, другие настройки.

Часто баги всплывают только тогда, когда появляется реальная база пользователей. И это нормально: тысяча людей (хотели бы мы такой онлайн ;) )за день создаёт больше уникальных комбинаций действий, чем небольшая команда тестировщиков за неделю. Пользователь делает то, что разработчик никогда бы не придумал: закрывает приложение на середине, разворачивает телефон, кликает быстрее, чем мы успеваем моргнуть, уходит в метро, возвращается через час и ждёт, что всё продолжится “как было”. Самое крутое в большом количестве пользователей — среди них всегда есть достаточно неравнодушных, чтобы быстро находить баги. Они часто пишут, где и когда столкнулись с ошибкой (дают точные данные, в каких логах искать), и это сильно упрощает их исправление.

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

P. S. Баг (англ. bug — «жук») — это термин, который используется в программировании и означает ошибку в программе