はじめに

プロダクトの品質を検査する時には欠かせないテスト。
ただ、そのテストがその時の思いつきや、行き当たりバッタリで行われているとしたら…プロダクトの品質状況については当然、疑問が残りますよね。
テストは意外とクリエイティブなお仕事なので、属人化しやすいと感じています。
ということで、いつ誰がテストしても同じバグを検出できる方法を模索していました。
そこで導入したのが「テスト観点リスト」です。

テスト観点とは

どのような角度から、どのような目的でテストを実施するかという視点 です。
ISTQB glossary（QAの用語集）にもテスト観点に関する定義はありません。
なので、どうしても主観になってしまうのですが…
テストをする際の切り口、とでも言いますか…

テスト観点リストとは

簡単に言うと、「何ができていれば良いかを、考える切り口を提示するリスト」です。
ベテランQAであればテキストボックスを見た瞬間に、
「半角カナを入力したら…」「絵文字を入力したら…」「最大文字数＋１文字を入力したら…」と瞬時にテストのアイデアが湧き上がってくると思います。

これをある程度抽象化したものが「テスト観点リスト」です。
つまり、私がテストを考えるときの頭の中をリスト化したものになります。

とはいえ、ただ単に経験に頼って作ったものではなく「ISO/IEC 25010:2011」の品質特性から
ブレイクダウンしたものを、取りまわしやすいサイズにして今の形にしてあります。

使い方

AI に「仕様書」と「Figmaなどのデザイン仕様」と「観点リスト」をPDF形式で渡して

「考慮すべき仕様の具体例」を埋めてください

と打ってみてください。
良い感じのドラフト版が出来上がるので、レビューしたら、そのテスト対象に特化したテスト観点リストの完成です！

人力でイチからやる時も、
今回のテスト対象になる機能について下表の「考慮すべき仕様の具体例」を埋めていきます。
書きながら、細かい機能が思い浮かんでしまったり、詳細な条件をまとめたくなったら「パラメータ」に追記していきましょう。
（機能によっては、対象外のものもアリ）

テスト観点リスト

大分類	中分類	小分類	テスト観点	パラメータ
機能テスト	表示（UI）	レイアウト/文言	アイテムの配置/表示サイズは？（記載内容/文字化け/文字切れが生じていないこと）
機能テスト	表示（UI）	エラー表示（正常系）	エラーメッセージはある？
機能テスト	入力	文字種	入力した文字種による仕様外の動作が発生しないこと
機能テスト	入力	文字数（正常値）	仕様通りの文字数が入力、実行できること
機能テスト	入力	文字数（正常限界）	仕様の上限/下限文字数が入力、実行できること
機能テスト	入力	文字数（異常値）	入力できない文字数が入力、実行できないこと
機能テスト	入力	数値（正常値）	仕様通りの数値が入力、実行できること	ゼロを含む/含まない
機能テスト	入力	数値（異常値）	入力できない数値が入力、実行できないこと	整数欄に小数点が入った場合は切り捨て演算記号（数式）…etc,
機能テスト	入力	未入力	入力欄を空白のまま機能を実行した場合の動作
機能テスト	動作確認	単機能	各機能が仕様通りの動作をする条件(Must) / できない条件(Never)
機能テスト	状態遷移		イベント発生（ボタン押下を想定）により状態が仕様通りに変わる・ステータス変化に応じた挙動	[ 変更・反映・設定保持 ] にて併せて確認する
機能テスト	状態遷移	経時変化	試合後、イベント発生後の状態はどうなるか？
機能テスト	画面遷移		特定の画面から仕様通りに画面 / 表示内容が切り替わる画面遷移時にデータを保持する / しない
機能テスト	変更・反映設定保持	初期値	インストール時 / 起動時の設定・表示・初めて使った時・再ログイン後
機能テスト	変更・反映設定保持	変更・反映	その変更がどの機能 / 画面に反映される（影響する）か
機能テスト	変更・反映設定保持	設定保持	変更された設定が終了後も保持されている
機能テスト	変更・反映設定保持	キャンセル	キャンセル時は設定の変更が反映されないこと（なにも変化がないこと）
組合せテスト	機能組合せ		複数の因子間で各水準を組み合わせた場合の動作がすべて正しいこと・関連する因子と水準は何か？	アカウント/機能/環境（構成テスト含む）
組合せテスト	同時実行	登録と参照	DBへの登録とデータ参照が同時であった場合の動作が仕様通りであること	登録＆検索/登録＆ページ更新（実施可能？）
組合せテスト	同時実行	同一アカウント複数環境	処理中に別環境・同一アカウントから操作を行った場合の動作が仕様通りであること
組合せテスト	割込み	別アカウント別環境	処理中に別デバイスや別アカウントから操作を行った場合の動作が仕様通りであること	複数アカウントでプッシュ通知受信して、カスタマイズされた通知が来る
組合せテスト	割込み	登録と参照	DBへの登録中に参照リクエストがあった場合の動作が仕様通りであること DB参照中に登録(変更)があった場合の動作が仕様通りであること
組合せテスト	排他処理	禁則	禁則条件に合致した操作ができない・注意すべき禁則は存在するか？
組合せテスト	互換性	OS	動作対象環境のOSで表示・動作ができること	構成テスト
組合せテスト	互換性	ブラウザ	動作対象環境のブラウザで表示・動作ができること	構成テスト
非機能	運用性	デプロイ	・データベースの移行は必要か（実行方法の目処はついているか）・デプロイ時のダウンタイムは影響ないレベルか
非機能	運用性	障害アラート	障害発生時などにアラートが発生するかエラーメッセージが仕様通り表示されるか（ErrorID:xxxxxxxx）
非機能	運用性	ログ	運用ログが収集されるか・計測関連
非機能	相互運用性	競合ハードウェア競合ソフトウェア連携システム	同一システム内の他プログラム間や他のシステムのソフトウェアとの間で、データやコマンド等をやりとりできること	環境変化（実行時のタイムゾーンを変更）構成テストメール（POP/SMTP/Webメール）各SNSとの連携/投稿他の操作による切断 OS設定の変更反映がされるか他の機能との依存関係（マナーモード、アラーム）

使い道

テスト観点リストが、どんなプロセスのインプットになっているのかイメージしていただけるようにプロセスフローを貼っておきます。

レビュー時のチェックに使える
マインドマップ作成時に切り口を提供してくれる
テストケースの抜け漏れがないかレビューのチェックリストに使える
ハイレベルケースとして使える

ちょっと横に逸れますが、フローの水色の部分、私はChatGPTを使って進めています。
それにより、ゼロから作るのに比べて3割くらいの工数で済んでいます。
観点リストを導入する前は、AIの出力がフワッとした通り一遍のものでしたが、テスト観点リストをInputに使うことで、かなりレビューに耐えられる出力になりました。
マインドマップやPRDと比べて、テスト観点リストはある程度は体系化されており、観点の意図が読み取りやすい点が強そうに感じます。

メリット

テスト観点リストがあれば、誰でも同じ作業品質を保てるようになる（ことを狙っています）
テストすべきことをリスト化することで、チェックが簡単になる
- PRDを読む時、作る時、テスト観点リストに照らし合わせて考えることで、
  - 「やるべきこと」が見える
  - 「あるべき姿」が見える
レビューのチェックリストに使える
観点ベースのテストカバレッジに着目して進捗が把握できる
- この観点でテストした！というものは ✅ を入れたり
ドメイン知識があれば、最悪、ケースにしなくても良い
テストチャーターとして探索的テストのフックにできる
開発エンジニアさんや、PMさんと「ここどうなれば良いでしょうね？」を会話する時に使える
- マインドマップを渡して確認していただくより分かりやすいかなと思います。

どういうテストをするかエンジニアさんに共有する際、マインドマップをお渡しすることがありますが、あれ、読む方のカロリーがすごく高いんですよね。
（QA内で他の方が書いたマインドマップを読むのも、実は苦手です）
マインドマップはあくまでも「発散」に使うものであって、その人の脳内を可視化したものです。他人が見るように設計されてないんです。
その点、観点リストは、「切り口の角度・意図」が明確なので、考えやすいかなと。

まとめ

陶芸が趣味の友人と話していて得た知見ですが、こんなことが言えそうです。

芸術家＝同じものを生み出すことができない。常に1点モノを作ることで価値を出す
プロ＝同じものを作ることができる。再現性に価値がある

QAが芸術家だったら、思いもよらないバグが上がってきたり、なかなかエキサイティングなシステム開発になりそうですが、仕事としてはあまり価値がなさそうです。
行き当たりばったりのテストから脱却して、いつでもどこでもどんな機能にも使える。
（プロダクトごとに作成が必要ですが）
テストにそんな普遍性を持たせたいという野望を少し形にしてみました。

というわけで、テスト観点リストを使うことで、作業の再現性を高めることができると感じています。
もし1年後に同じ機能をテストすることになっても、今回と同じバグを検出できるぞ！と言い切れると強いなぁと思うのです。