Баги в проде неизбежны, и при чем тут тесты

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

И речь в основном будет про автотесты, а не ручное тестирование.

Что я понимаю под багом

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

1. кнопка не нажимается, хотя она подсвечена как активная, и по логике в коде она точно должна нажиматься, т.е. нет никаких объективных причин для ее блокировки
2. элемент на экране нажимается, но в редких ситуациях, т.е. проблема с зоной нажатия
3. что-то на экране не отображается, или уехало куда-то в сторону, сжалось или растянулось, т.е. выглядит плохо, не как задумано
4. приложение само закрывается при выполнении какого-то действия (крашится)

Первые 3 примера часто не считаются критичными, потому что приложение же работает, так?

Четвертый уже не так просто игнорировать - статистика по крашам приложения видна во всех популярных инструментах типа firebase, и тут уже не отвертишься - там это включено по умолчанию, если конечно в проекте подключен firebase.

Что я не считаю багом

То, что было сделано по задумке команды (дизайнеры/аналитики/продакты и т.д.). Если чтобы добраться до какого-то меню, нужно пройти 7 кругов ада из бесполезных переходов по нескольким экранам, то это не баг, а "фича". Так кто-то задумал, и разработчик сделал по требованию в задаче.

Или если в приложении используются вырвиглазные цвета, некрасивые иконки/картинки - ситуация та же.

При этом разработчику могло не нравится это решение, он мог даже высказать свое мнение команде или конкретному лицу, принимающему решение по этому функционалу, но его мнение могло быть легко послано на все 4 стороны, потому что не все и не везде хотят/готовы слушать мнение разработчика, когда есть заказчик с его хотелками и "видением".

Заказчиком, кстати, может быть кто-угодно - это необязательно какой-нибудь акционер или директор, или клиент. Кто-угодно может быть заказчиком в зависимости от ситуации.

Тесты

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

Хотел повеселиться немного, ведь мне такую дичь часто говорили в прошлом)

Unit-тесты

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

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

Команда напрягается и повышает процент покрытия тестами.

И баги снова возникают. Что дальше?

UI-тесты

Начинаем делать UI-тесты, у нас все получается. Да, они выполняются медленнее, чем UI-тесты, но они снижают нагрузку на тестировщиков (если они вообще были и тестировали что-то), уверенность в каждом релизе все выше и выше с повышением процента покрытия UI-тестами.

Но баги все еще возникают. Что дальше?

Больше тестов!

Делаем больше тестов, потому что всегда есть что-то, что можно протестировать. Без шуток. Интеграционные тесты, e2e тесты и прочие страшные названия видов тестов.

Реальность

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

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

Выходит новый закон или пакет санкций и часть функционала отваливается у части пользователей из-за ip-адреса и т.д.

В чем же проблема?

На мой взгляд тут комбинация факторов, главный из которых - человеческий, а потом все остальное, кому что больше нравится:

• угнаться за прибылью
• не отстать от конкурентов
• попытаться повторить успешный сценарий, который у кого-то на рынке сработал
• и т.д.

Человеческий фактор

Перечислю реальные случаи из моего опыта (без имен и компаний), потому что на мой взгляд это отличные примеры:

• Можно не передавать задачу в тестирование, потому что вряд ли что-то сломается, там ведь так много легаси, и оно как-то работает, верно? Да и тестировать сейчас некому, а задача срочная...
• Можно не передавать в тестирование задачу, потому что разработчик проверяет ее сам, и уверен, что все будет хорошо, а если вдруг на регрессе найдут проблему, то ее будет несложно поправить
• Можно пройтись по сценарию тестирования вручную целиком, а можно не целиком, ведь вряд ли что-то сломалось в том месте, где мы даже не задевали в этом релизе?
• Можно пройтись по всем сценариям тестирования, найди баги, но посчитать их некритичными и никому не сообщить о них.
• Можно пройтись по всем сценариям тестирования, найти баги и завести их в список багов, но не акцентировать внимание ни на одном из них, т.е. не высказать свое мнение в команде, потому что, очевидно, баги есть баги, и их когда-нибудь нужно будет починить, верно?
• Можно пройтись по всем сценариям тестирования, рассказать всем про статус основных задач, и случайно найти другой баг, не относящийся к задачам, которые были в сценарии, и никому не сказать, потому что очевидно это старый баг, или баг другой команды, или его вообще не нужно было тестировать.

Обстоятельства непреодолимой силы

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

Такие обстоятельства будут, на них нужно вовремя реагировать ... и по возможности покрывать такие сценарии автотестами 😉

Что же делать?

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

Можно поставить себя на место пользователя вашего приложения и прикинуть, насколько комфортно вам лично пользоваться приложением с багами, которые в нем есть.

Нужно спросить себя/команду, можно ли как-то улучшить UX путем написания тестов, добавления дополнительных сценариев в общий список тестов и т.д.

В конце-концов можно автоматизировать многое, если есть желание, и пользователю будет приятнее.

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

Заключение

Спасают ли тесты от багов? Нет.

Нужны ли тесты? Обязательно, если вам важен качественный результат ✅