В большинстве компаний, которые я видел, дихотомия прод / постановка сформулирована следующим образом на примере прямой трансляции Facebook:
При такой настройке, когда новую функцию необходимо протестировать «вживую» перед переходом к продукту, единственный способ сделать это - создать промежуточную среду на основе снимка базы данных продукта и протестировать на ней новую функцию.
Это оказывается весьма вредным, когда тестируемые функции являются функциями, которые сильно зависят от сложной комбинации постоянно поступающих данных и взаимодействуют с ней. Такими функциями могут быть, например, изменение способа отображения новых сообщений в каналах других пользователей или предложение контента на основе сообщения, которое только что понравилось пользователю. Или это также может зависеть от поступающих внешних данных, таких как погода или статьи из внешнего информационного агентства и т. Д. Или это могут быть алгоритмы машинного обучения, которые предсказывают, что пользователи будут делать дальше, и реагируют на любые входящие данные в режиме реального времени.
После очевидной фазы предварительного тестирования наступает момент, когда нам нужно оценить, как на самом деле будет вести себя новая часть функциональности в среде ACTUAL prod по мере поступления новых данных, а не теоретически, основываясь на некоторых статических сценариях использования.
Мне кажется, что с вышеуказанным требованием лучше всего справиться с помощью «живой промежуточной» среды, которая является точной копией prod и которая будет продолжать обновляться новыми данными, как и prod. Единственная разница в том, что prod - это новый фрагмент кода, который необходимо протестировать. В этой промежуточной среде тестировщики QA смогут проверить, как эта новая система работает при поступлении новых данных.
Тем не менее, я должен сказать, что ни одна из компаний, в которых я работал до сих пор, не имела такой возможности, и во всех этих компаниях «постановка» означает замороженный снимок продукта и единственный способ справиться с «зависимостью от данных в реальном времени». "описанные выше функции заключаются в том, чтобы прибегнуть к трудоемкому ручному тестированию с использованием странных фиктивных данных (создание поддельных сообщений с поддельными пользователями или имитация внешних входящих данных, что является неэффективным и ненадежным).
При внутреннем обсуждении обычно ответ заключается в некоторой вариации между «у нас нет на это времени» или «я не понимаю, чем это может быть полезно, просто добавьте некоторые данные вручную, и все будет в порядке». Итак, мои вопросы: