テスト観点レビュー時のチェックポイント
はじめに
これはウイングアーク Agile and DevOps Stories のAdvent Calendar 2019、第14弾（2019年12月19日）の投稿です！
はじめまして、ウィングアーク１ｓｔの ソフトウェアプロセス＆品質改善部の吉田と申します。散歩しながらの風景撮影と温泉巡りにはまってます。今の時期だと東京の公園ではちらほらと紅葉が見れて綺麗ですよ。
さて……。新機能を評価するための一つの手段として、仕様書を利用者側からの視点でレビューや監査を行い開発者へフィードバックすることや、またはテスト要求分析の一環としてテスト条件や観点の出力等を行うこともあるかと思います。
2019年度、当時私が担当していた製品では、社員・業務委託を含め新規メンバーが一気に増える機会がありました。製品に慣れるためにも、テスト観点に関するレビューについてはグループメンバー全員で参加して行うスタイルを取りました（メンバーの特性を把握する目的も含んでいます）。
この1年を通じて、テスト観点に関するレビューで発生することが多かった指摘事項を元に、次の4点について工夫や考慮を行いました。
- 最初にユーザストーリーで要求分析を行う
- 観点は丁寧に書くことを意識する
- トレーサビリティを確保する
- 仕様書に書かれていない内容を観点に含める
以降に、それぞれの解説をしたいと思います。
1. 最初にユーザストーリーで要求分析を行う
テストする内容を大まかに考えてから具体化するため、テスト観点を整理することで全体像を把握しやすくしますよね。新機能の仕様書が開発から共有されたとします。じゃあさっそく機能を単位毎に分割しようかな……ちょっと待って！
新機能が実装されたということは、その機能を使うことでユーザーに何か良いこと（イコール ＝ 価値）を与えるはずです。たとえば新機能の説明自体は一見同じ内容であったとしても、その目的の背景・理由が異なれば、最終的にユーザーが求めている結果が異なる場合もあります。
- 最終的にユーザは何を求めているのか
- どうすればユーザの目的＝したいことを達成することができるのか
- 何を確認したらその機能が、目的を果たせたといえるのか
QA担当者全員が常に“この新機能は何のために作られたのだろう？”と考える習慣をつけるために、「新機能追加の背景と目的」の記述欄を、観点表のテンプレートに追加することとしました。
どこかで見たことがありますよね。
<ユーザの種類> として<達成したいゴール>をしたい。
なぜなら<理由>だからだ。
そうです。6W2Hと ユーザストーリーを参考に、最初に「実現したいコト」を考えてから、テスト観点分析を行うこととしました。
上記、シンプルですが効果はとても高かったです。
レビュー時、最初に目的機能の認識合わせを必ず行ってからテスト観点のレビューを行う流れとすることで、事前に認識合わせを行う時間が少し増えましたが、トータルのレビュー時間は大きく減りました（そもそも手戻りがなくなった）。
また新機能の観点自体から“ユーザ要望を満たすことができているか”が漏れなくなったため、導入してとても良かったと思います。
2. 観点は丁寧に書くことを意識する
観点は、プログラムやシステムが果たすべき目的を予測して”正しく動作”することを確認するため、またはユーザが求める”正しい動作”を確認するために「製品のどの部分を、どのようにテストするのかを決めるための内容」とも言えます。
仕様書で”設定できる”と書かれていても、ユーザからすれば”設定すること”が目的ではないですよね。
利用者の視点を取り入れているかを意識し、かつ「設定が反映される・設定が保持される 」など 「何を見たくてその観点を記載しているのか」が一目で判断できる観点の書き方だと、機能をあまり知らない第三者がレビューした場合でも、話がとてもスムーズに進みやすかったです！
”その機能が実現できるか” が、明確かつ簡潔に含まれていると「曖昧な文章による認識のずれ」や「必要なテスト観点が、レビューを行ったのに全員気づけなかった」といった事象の防止にもなりました。
観点 ＝ 着眼点と言えばイメージしやすいかと思います。
(対象/前提) どの内容/条件に対して
(方法) どのように
(目的) 何がしたいのか？何ができるのか？何を見たいのか？
第三者が見て「この観点は “〇〇に対して過去バージョンと比較” して “性能が同等である” ことを見たいのか…」とパッとイメージできるよう「何をテストすればいいのか（着眼点はどこか）」については、具体的に書くことにしよう！と、お話してました。
※ どのような手順と値で、どの画面で何を操作することで、どんな結果を期待している…はテストケースにて。
3. トレーサビリティを確保する
テストはあくまで品質を確保していることを評価するための一つの手段です。そのため、計画次第でテスト実施を行わないことを決める場合もあります。計画段階で上流から定めたテスト非対象機能についてはともかく、テスト対象機能については、どのようにトレーサビリティを確保すればいいでしょうか。
トレーサビリティを確保する方法は色々とあるかと思いますが、グループ内でテスト観点表を作成する段階においては、以下の点を重視していました。
- 新機能などのインプット元情報とのマッピングを行う
- そもそも観点を作成しない機能は、その旨をキチンと示す
- テスト観点表とテスト仕様書を、命名規則で一致させる
- テストの観点番号と、テストケースの番号が一致している状態とする
- 想定するテスト観点は全て記入 ※ケースは間引いてもいい
トレーサビリティが確保できている状態であれば、仕様書や設計書が更新されたとしても変更点がすぐに判断でき、抜け漏れを防ぐことができます。すぐに簡単に追跡できることから、問題点に気づきやすくなります！
またテスト観点には”あえて書いていない”場合においては「抜け漏れ？何らかの理由での対象外とした？ヒアリングしなきゃ。」といったよう事象が減るかと思います。「残りはあとで」という場合においても、どこまで対応したかが分かりやすいため、最初は面倒に思えても、とても効率的だったり。
※ ちなみに管理ツール等のシステム面でカバーしている場合は、当たり前になるためトレーサビリティも意識しないでいけるかと思います。
4. 仕様書に書かれていない内容を観点に含める
設計書や仕様書に書かれておらず、テスト観点としては取り入れたい内容があるかと思います。例としていくつか挙げます。
- 環境要件は開発者にとって当たり前の想定であり触れられていない
- アクティブは書かれているが、非アクティブについては書いてない
- 新機能の情報がメインであり、既存機能との互換性に関する情報がない
上記ような「仕様書に書かれていない内容」に対しても、テスト要求分析を行い、テスト観点に含める方法は様々な切り口があるかと思います。なお、こういった場合には、必要に応じてQA担当者間のレビューだけでなく開発者ともレビューや相談を行い観点を抜きだすとともに、テスト可能な仕様となるようフィードバックをしています。
よく検討していた、いくつかの切り口を以下にまとめておきます。
内部の振舞いや関連機能・過去のインシデントから洗い出す方法
- 既存機能上で動作する新機能である場合
- 内部的に共通する・既存のルートを通る場合
- 新機能であっても既存機能に類似した内容である場合 など
上記のようなケースで、関連しあう機能間連携の組み合わせを検討することは勿論、過去バージョンで発生した類似パターンの不具合や、ユーザからの指摘不具合を分析した方法を取り入れると、とても有効な観点となることが多いと思います。
テストタイプ・テストレベル・品質特性をテスト観点で表す方法
テスト計画段階にて、どのテストレベル（α、β…）でどのテストタイプ（環境、性能、負荷…）を実施するのか区分けすることもあるかと思います。テストタイプを見れば「環境テストだから、環境を確認したいテストなのだな。」ということは分かります。しかし「この環境テストでは、どのシステムに対して、どの部分に着眼点を置いてみたいのだろう」という具体的な個別の内容はまだ曖昧です。
テストタイプ・テストレベルをより詳細に表すためにも、テストタイプ別に分類した上でのテスト観点を作るのも有効な手だと思います。
ちなみにグループ内では現在、上記と組み合わせて品質特性（ISO/IEC 25010（JIS X 25010）を利用しています。品質特性に定めたサブゴールに対して「テスト観点」をマッピングすることで、第三者から見て、レビュー時に品質特性自体からの観点漏れがないことや、またサブゴール自体、抜け漏れがないように考慮できているんだな、と示すこともできますので、ある意味便利です。
一般的な観点一覧から洗い出す方法
グループ内で検討したこととしては「統一観点一覧」や「製品固有の観点一覧」ということで共通観点を作成しておき、クライアントやサーバー側でよく発生しうるパターンの観点の一覧化を行いました。
全ての製品・パターンに適応はできないこともありますので、一覧＋αの考慮は必要となりますが、最初にまとめておけば抜け漏れのチェックリストとしては便利かと思います。
※以下は「統一観点一覧の参考例」となります。
テスト技法を活用する方法
ブラックボックスで一般的な同値分割、境界値分析等の技法を利用する方法や、ユーザシーンからテスト対象のテスト条件を抽出する方法もあるかと思います。また組み合わせテストでは、総合的な要因「ノイズ(環境)、状態(変化)」なども必要に応じて取り入れます。
◆簡易チェック◆
・最初にユーザストーリーでの分析を行っている
・テスト観点の内容は分かりやすく書いている
・トレーサビリティを確保している
・仕様書に書かれていない内容も検討できている
切り口は様々ですので全て考慮する必要はありませんが、一つの事例として記載させていただきました。ご参考になるようでしたら幸いです。
