私の会社は多変量テスト ベンダーと提携しており (まだどのベンダーかは明らかにできません)、彼らのシステムを当社の主力の B2C コマース サイトに統合するよう求められています。
通常、「統合」という言葉は難しい用語です。ただし、ここでは、<script>複数のビューにタグを追加し、その時点からループから抜け出すことを意味します。多変量実験は、当社のマーケティング部門 (および/またはベンダー) によって設定されます。私たちの開発チームはそれに関与することはありません。
基本的に、JavaScript インジェクション攻撃ベクトルをフラグシップ アプリケーションに意図的に追加するように言われています...そして最善を尽くします。私の懸念は、悪意のあるコードではなく、不注意による失敗です。私たちの CSS と基本的なページ レイアウトはすでに混乱しています。他の誰かの多変量実験がホームページのルック アンド フィールなどを爆破したときに熱を帯びることが予想されます。さらに重要なのは、醜い AJAX とサーバー サイドがたくさんあることです。予測可能な HTML 要素、属性などに依存する粗雑な作業id...そのため、実験で HTML 要素を変更しすぎると、コア コマース機能が予測できない方法で完全に壊れてしまいます。
私の懸念は、実際のテスト環境がないことで増幅されます。ベンダーはフィルタリングを行うため、本番 URL からの AJAX 呼び出しのみが処理されます。開発環境または QA 環境からの呼び出しは無視されます。ただし、それはテスト環境を持つことと同じではありません。むしろ、本番環境が各実験のテスト環境になったことを意味します。
上記のすべてを考慮して、これらのリスクの一部を軽減するために利用できる慣行はありますか? 多変量テストは非常に新しい分野です。Google 検索の最初の数ページは、CIO にバズワードを売りつけるいかがわしいコンサルタントで構成されています。最終的にリスクを監視する責任を負う社内の技術者向けに書かれたものはあまりありません。上記の制限の下で適切に QA を行う方法はありますか、またはそのようなシナリオでプッシュ バック (*) する以外に方法はありませんか?
(*) 注: ベンダーとの関係の政治的事情を考えると、プッシュバックに対して非常に気密性の高いケースを構築する必要がありますが、いずれにせよ無視される可能性があります。