UXテストとUIテストは同じ作業ではありません

UXテストとUIテストは、二つの異なる問いを立てます

すべてのUIテストに合格していながら、使っていて苦痛な製品はあり得ます。逆に、ユーザビリティセッションでは好評でも、本番環境でデータを失う製品もあり得ます。どちらの活動も、もう一方の代わりにはなりません。

自動化が正直に担える範囲

• すべてのフローの機能的な正しさ。 1列目に挙げたものすべてです。

• 機械的に判定できるアクセシビリティのチェック。 ラベルの欠落、コントラスト、フォーカス順序など。確かな価値がありますが、アクセシビリティのすべてではありません。

• 一貫性のチェック。 同じ操作が3か所で同じように振る舞うかどうか。これはテスト可能な形を持つUXの問題です。

自動化にできないこと

そのフローは筋が通っていたか。エラーメッセージは役に立ったか。途中で諦めた人はいなかったか。これらには人が必要です。有用な捉え方は、手作業のリグレッション確認をなくすことで、自動化がそれらに充てる時間を取り戻してくれる、というものです。

自動化する価値のある重なり

両者が本当に重なる狭い領域があります。そしてそこは、多くのチームにとって最も活用されていない自動化の対象です。

一貫性は、テスト可能な形を持つUXの性質です。同じ操作は、それが現れる3か所すべてで同じ確認表示を出すか。エラーはどこでもエラーらしく見えるか、それともある画面だけ何も表示されずに失敗するか。主要なアクションは、すべてのモーダルで同じ位置にあるか。いずれもデザインの善し悪しについての判断を必要とせず、いずれもユーザーが雑さとして気づく類のものです。

こうした点は、各画面を作った本人には見えません。画面単体で見れば、それぞれは一貫しているからです。画面をまたいで確認するコストは小さく、機能テストもユーザビリティリサーチも探していない種類の不満を拾い上げます。

落とし穴

UIテストのカバレッジが高いことを理由に、UXリサーチを削るチームがあります。一見もっともらしい理屈ですが、これはカテゴリーの取り違えです。カバレッジが示すのは、製品が作られたとおりに動くということだけであり、それが作るべきものだったかどうかについては何も語りません。

より健全な分担は、繰り返しの確認を自動化に任せ、そこで空いた時間を人にしかできないリサーチに充てることです。

ここまでの内容に、ターミナルは必要ありません。TestSpriteのダッシュボードでプロジェクトを作成し、確認したいことを平易な言葉で記述して、対象のアプリを指定します。コマンドラインのほうが好みであれば、チームの開発者はそこから同じことを実行できます。その方法をまとめているのが CLIリポジトリです。

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

TestSpriteが自動化するもの、そして人に残すもの

機能面の列は、まるごと自動化されます。フローが動作するか、ステップ間で状態が正しく引き継がれるか、ユーザーに伝えられる内容が実際に起きたことと一致しているか。テストケースは製品から生成され、平易な言葉で調整でき、変更のたびに実行されます。

重なりの領域にある一貫性のチェックも対象です。たとえば、同じ操作が現れる場所すべてで同じように振る舞うかどうか。これはテスト可能な形を持つUXの不満です。

意図的に人の側に残しているのが、リサーチです。手作業のリグレッション確認をなくす価値は、それによって戻ってくる時間にあります。そしてこのページの主張は、その時間をバックログに注ぎ直すのではなく、ユーザーと話すことに充てるべきだ、というものです。