В больших компаниях обычно есть «тестовое окружение» – среда, в которой разворачивается приложение и в него тыкают разрабы и QA.
Лиды порой приобретают привычку говорить (и, что страшнее – думать!), что код работает как надо, если в тестовой среде не нашлось багов, прошли модульные и интеграционные тесты и тд. В идеальном мире – так оно и есть, но в реальном..если ты работаешь над большим приложением, которому много лет: этот подход не работает!
––
Почти всегда найдется:
– 10 конфигов, расходящихся в проде и в тестинге
– Паттерны использования приложения, до которых дошли странные юзеры и не дошли qa
– Блоки кода твоих коллег, которые включены в проде и выключены в тестовой среде
– Разница по нагрузке и данным, проходящих через разные окружения (моё уважение людям, которые льют в тестинг часть данных и нагрузки из прода! К сожалению, этот подход не устраняет остальные обозначенные проблемы).
– Банально невнимательный участник команды, который забыл проверить какой-нибудь сценарий на себе
Как следствие – вместо ожидаемого запуска на пользователей («всё ведь протестировано и работает – выкатим да включим») в день X происходит..получение 10 баг-репортов из прода и изменение графика поставки.
Решение: относиться к любому крупному изменению как к эксперименту
Даже если продуктовые метрики не должны прокраситься. Даже если это – «просто большой рефакторинг» (или оптимизация времени ответов бэкенда на 20%). Во многих случаях, выкатив сделанное на процент пользователей (или на всех сотрудников компании; или на город) ты, внезапно, соберешь пачку багрепортов, а иногда – увидишь прокрасившуюся в неожиданную сторону метрику :)
После эксперимента в проде – функционал и правда протестирован и готов к включению 🙂