バグを見逃さないテスト観点表の作り方

「思いつきテスト」で何が起きるか

機能を触りながら思いついた操作を試す。それだけでも一定のバグは見つかりますが、担当者の経験や気分に依存するため、毎回違う箇所が抜けます。テストを終えた後になって「そういえば権限が違うユーザーでは試していなかった」と気づくのは、思いつきテストの典型的な失敗パターンです。

この抜け漏れを構造的に減らす道具がテスト観点表です。機能を「何を試すべきか」という軸に分解し、埋まっていない欄を可視化します。

観点表とは何か

観点表は、テストケースそのものではなく「テストケースを作る一段階手前の、抽象度が高いチェックリスト」です。縦軸に観点、横軸に機能や画面を置き、交差するマスに「試すべきか・試したか」を記録します。個々のテストケース(具体的な入力値と期待結果)に落とし込むのはその後の工程です。

観点を洗い出す4つの軸

機能軸(正常系・異常系の基本フロー)だけで観点表を作ると、結局は思いつきテストと同じ抜け漏れが残ります。以下の4軸を必ず追加してください。

1. 状態軸

画面や機能が「今どの状態か」で挙動が変わる箇所を洗い出します。ログイン中/未ログイン、初回利用/再利用、処理中/完了後、など。

2. 権限軸

ロールやプランによってアクセス可否・表示内容が変わる箇所。管理者/一般ユーザー、無料プラン/有料プラン、退会済みアカウント、など。

3. データ量軸

0件・1件・大量件数・上限突破・重複データなど、データの量や境界値によって壊れる箇所。

4. タイミング軸

連打・多重送信、有効期限ギリギリの操作、複数タブや複数デバイスでの同時操作など、時間軸に関わる箇所。

観点表のテンプレート

実務では以下のような表を機能ごとに作ります。「観点」列にチェック項目を書き出し、埋まっていない軸がないか確認するだけでも効果があります。

記入例: パスワード再設定機能

「パスワード再設定」機能を例に、4軸それぞれで観点を埋めるとこうなります。

• 状態軸: ログイン中のユーザーがリセットURLを踏んだ場合／既に使用済みのトークンで再度アクセスした場合
• 権限軸: 退会済みアカウントのメールアドレスでリセット申請した場合／管理者が代理でリセットを実行できる範囲
• データ量軸: 同一メールアドレスに対して短時間で複数回リセット申請が来た場合
• タイミング軸: トークンの有効期限が切れる直前に再設定を完了しようとした場合／複数タブで同時にリセット画面を開いた場合

機能軸の「メールを送って新しいパスワードを設定できる」だけをテストして終わっていたチームが、この4軸を足しただけで「退会済みアカウント宛のリセットメールがエラーにならず届いてしまう」という権限周りの不具合を事前に見つけられた、というのはよくある話です。

観点表をチームで使い続けるコツ

• レビューの叩き台にする: 実装レビューやテスト計画レビューで観点表を先に見せ、抜けている軸を指摘してもらう
• テンプレートを使い回す: 4軸のひな形を機能横断で共通化し、機能固有の項目だけを都度埋める
• 消化率を追う: 「実施」列が埋まらないまま放置されている軸がないか、リリース前に確認する

Bugoon での実践

観点表で洗い出した項目は、実際にテストして見つかった不具合と紐づいて初めて価値を持ちます。Bugoon はサイトに埋め込んだウィジェットからスクリーンショット付きでバグを報告でき、操作ステップの記録や GitHub Issue 連携、カンバンボードでの管理まで一気通貫でつながります。観点表に沿って手を動かしたテスト担当者が、そのまま画面上から報告できる状態にしておくと、観点表とテスト実施の距離が縮まります。

観点表の項目とバグレポートを紐づけて集計できると、「どの観点で何件出たか」が見えるようになり、次回の観点表の優先度づけに使えるかもしれません。今回はその一歩手前、観点表そのものの作り方に焦点を当てました。