A/Bバリアントをまたいだテストの自動化

mablでは、アプリの異なるバージョン全体でテストカバレッジを確保するために、チームのA/Bテスト実装方法に合わせてテストを設定できます。この記事では、mablでA/Bテストを処理するためのガイドラインをいくつか説明します。

チームの実装方法を理解する

mabl でテストを作成する前に、チームが A/B テストをどのように実装しているかを理解しておいてください。次の表は、一般的な A/B テストの実装方法と、mabl テストでそれらに対応する方法を示しています:

異なるバリアントをテストするための戦略を選択する

mabl でチームの A/B 実装方法に対応する方法を特定したら、テストロジックを構造化する戦略についてチームメイトと調整してください。このセクションでは、さまざまなバリアントをテストするための戦略をいくつか紹介します:

同じテスト内のテストバリアント

2つのバリアント間の差異が小さい場合は、1つのmablテストを作成し、条件分岐を使用してバリアントのステップを処理できます。

たとえば、A/Bテストがeコマースのチェックアウト体験の一部をカバーしている場合、現在のバリアントに応じて適切なmablステップを実行する条件を作成できます。または、同じインタラクションを必要とする環境ベースのバリアントをテストしている場合は、両方の環境に対して同じテストを実行するようにプランを設定できます。

別々のテストでバリアントをテストする

バリアント間でエクスペリエンスが大きく異なる場合は、異なるバリアントごとに個別のテストを作成する方が簡単な場合があります。

たとえば、A/Bテストで新しい「ワンページチェックアウト」エクスペリエンスを評価し、元の「マルチステップチェックアウト」と比較している場合、両方のエクスペリエンスに対して個別のテストを作成し、同じ部分にはフローを使用できます。

データテーブルシナリオでテストバリアントを使用する

バリアント間の違いがデータ駆動型の入力で管理できる場合は、データテーブルを使用して、同じテストを複数のシナリオに対して実行できます。このアプローチは、バリアント間のエクスペリエンスが十分に類似しており、同じ機能テストステップで検証できる場合に最適です。

たとえば、クエリーパラメータによってトリガーされる複数の異なるプロモーションバナーをテストする場合、それらのパラメータ値をデータテーブルに保存できます。mablは同じテストを複数回(テーブルの各行に対して1回ずつ)実行し、基礎となるテストロジックを変更することなく、各バリアントが正しく表示され機能することを検証します。