Почему две разные версии файла могут отдаваться разным пользователям как фича?

Что проверяют

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

Как отвечать

Перечислите механизмы, из-за которых пользователи законно видят разное:

• A/B-эксперимент и фича-флаг: сплит по идентификатору пользователя, вариант фиксируется за ним и не должен меняться от перезагрузки;
• поэтапный или канареечный выкат: часть трафика идёт на новую версию, остальные на старую, признак обычно виден в заголовке ответа или в версии бандла;
• сегментация: тариф, роль, регион, язык, платформа, версия клиента;
• кэш: браузер или CDN отдаёт старый файл, пока не истёк Cache-Control или не сменился хэш в имени. Это уже не фича, а следствие того, что статика не версионируется.

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

Где спотыкаются

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

Второе: тестируют только новый вариант. Старый в этот момент видит основная масса пользователей, и регрессия в нём стоит дороже, чем дефект в эксперименте на малой доле трафика.

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