UIパフォーマンステストツールと、その間に残るギャップ

UIパフォーマンステストツールの2つの系統

両者の間に抜け落ちるもの

ラボ系ツールが対象とするのはテスト環境であり、つまりデータ量は小さくなります。フィールド系ツールは実際のデータ量を捉えますが、報告されるのは実ユーザーが不便を被った後です。その結果、10行なら高速で2,000行では使い物にならない画面は、ラボをすり抜けてフィールドで表面化します。これはあり得る限り最悪の順序です。

このギャップを埋めるのに、新しいカテゴリのツールは必要ありません。必要なのは、大口顧客と同じ規模のデータを投入したアカウントと、リリース前にそのアカウントに対して同じフローを実行することです。

それぞれの系統での選び方

• ラボ系ツール： 初期読み込みだけでなく、操作の応答時間を計測できるものを選びます。読み込みはセッションごとに一度きりのコストですが、操作は絶えず発生します。

• フィールド系ツール： アカウントの規模でセグメント分けできるかを確認します。全顧客の平均値は、まさに問題を抱えている顧客を覆い隠します。

• 両方に共通： 絶対的なスコアではなく、自社の過去の推移と比較します。他所から借りてきたしきい値が製品をまたいで通用することは、ほとんどありません。

意味のあるフィールドデータにするためのセグメント分け

実ユーザーのモニタリングは2つの系統のうちより正直なものですが、集計の切り口を誤ると簡単に役に立たなくなります。

全ユーザーの平均は、レコードが50件の顧客と50,000件の顧客を同じ器に混ぜてしまいます。そして、シグナルのすべては後者にあります。デバイスをまとめること、地域をまとめること、社内ユーザーと顧客をまとめることも同じです。最大規模のアカウントが着実に悪化していても、全体の数値は改善し得ます。これが契約更新を失わせる形の失敗です。

セグメント分けは、自社の製品で実際に差が出る軸で行います。多くの業務向けソフトウェアでは、それはデバイスやネットワークではなくアカウントの規模です。ツールがその軸で分けられないなら、そこに表示される数値は、あなたが本当に気にしている対象を計測していません。

誰も挙げない前提条件

リクエストが黙って失敗したために即座に描画される画面は、ラボ系ツールで見事なスコアを出します。正しく動作していることは、あらゆるパフォーマンス数値の土台です。そしてその検証は、ここまでに挙げたどのツールよりも低コストです。

ローカルに何もインストールしたくない場合は、同じセットアップをTestSpriteのダッシュボードからも利用できます。CLIのその他の機能について詳しくは CLIリポジトリ。

それぞれが動く場所

ラボ系ツールはパイプラインの中で、プルリクエストごとに、ベースラインと比較しながら動かします。フィールド計測は常時オンにします。現実的な規模のアカウントに対する機能検証も、変更のたびに実行します。そこが、ほかの2つが空けたままにしているギャップだからです。

重要なのは仕組みよりもトリガーです。デプロイのイベントに紐づけておけば、誰かが判断しなくても、すべての変更がチェックされます。 GitHub App ならダッシュボードから、 GitHub Actions のステップならワークフローの内部から、それを実現します。

TestSpriteがラボとフィールドの間で果たす役割

両者が空けたままにしているギャップの部分です。つまり、現実的なデータを持つ環境に対して、リリース前に実際のフローを実行します。テストの範囲は製品そのものから生成され、変更のたびに実行されます。そのため、10行では動作し2,000行で壊れる画面は、パーセンタイルではなく挙動によって検出されます。

さらに、どちらの系統も確認しない前提条件を担います。取得に失敗したために即座に描画されるページは、速くても正しくありません。そしてラボのスコアはそれを教えてくれません。

ラボ系ツールは引き続き読み込みと操作のタイミングを計測し、フィールド計測は引き続きユーザーが体験した内容を報告します。そこに加わる利点は、最大顧客のデータ量でしか現れない不具合を、その顧客より先に見つけられることです。