テスト計画を作るときの4つの抑えどころ

標準

先日、ソフトウェアのテスト計画をたてるという、名誉あるミッションを任命された若手エンジニアと議論しました。彼女にとっては初めての領域であって、悩ましい課題がたくさんあったようです。ずいぶん長い間議論して(2時間以上やってた)私なりの考えを伝えたつもりですが、議論がとっちらかったのでここにポイントをまとめます。


 

  1. テストは探索的なもの、テスト計画はその性質を考慮する

    ソフトウェアテスト(に限った話ではありませんが)、あるいはシステムテストは、やってみないとわからない要素が多分にあります。これはソフトウェア開発行為が本質的に開発エンジニアの能力に依存していて、品質の特徴(どこがいいか、わるいか)も人に依存していることに一因があります。
    計画時にリスクを分析し、テストでどこを攻めるべきかを決めますが、よっぽどシンプルな開発でなければ想定通りになることはまずないでしょう。そこで、計画ではテストの活動を段階に分け、各段階で見直しをするよう、スケジュールやリソース配分を考えます。初期段階では、基本的で重要な機能やリスクが高いと判断した観点を確認し、検出したバグの内容を確認します。バグが出ない箇所は優先度を下げ、バグの出た箇所に関するテストの優先度を上げます。ここでテストの観点を新規に追加したり、より詳細に攻める(たとえば因子(条件)の組み合わせを増やす)など、テスト計画を修正し、早い段階でリスクを潰します。

  2. テンプレートとしてIEEE829-2008を活用する

    テスト計画で少なくとも考慮すべき事柄のチェックとして、テストに関連するドキュメントを体系的に定義したIEEE829-2008という規格を利用しましょう。
    この規格は、ソフトウェアに要求される品質レベルによって異なるテストのドキュメント体系を示したものですが、作りたいドキュメントのテンプレートとして活用できます。テスト計画は、マスターテスト計画書を参照します。また、テスト観点毎には、レベルテスト計画書を参照します。必ずしも該当のドキュメントを作成する必要はありません。テンプレートに定義された見出しのレベルで考慮の抜け漏れがないか確認することが大事です。例えば、「テストで対象としないもの」とか「テスト自身の品質確保方針」は不明瞭になりやすい事柄です。
    なお規格ではバグ連絡票(呼び方はいろいろ)などもテンプレートがありますので、他のドキュメントも参考になると思います。

  3. 製品やサービスが達成すべき品質を定義してテストと関連付ける

    テストの網羅性について議論するとき、網羅する地図をまず明確にする必要があります。さまざまな側面から地図を作ることができますが、もっとも大切なのは、ソフトウェアやシステムが達成すべき品質です。
    品質は可能な限り具体的に客観的に定量的に表します。品質を定義するときには、まず企画主旨を理解します。その製品またはサービスがユーザーにどんな価値を提供するのか、つまり何が「売り」なのかを把握します。企画会議の資料を眺めたり、プロジェクトオーナーに聞きましょう。
    さらに、当たり前なので暗黙的になっている品質の基準がないかどうか確認します。過去の製品との互換性とか、信頼性や安定性、セキュリティなどの機能以外の品質は隠れている場合があります。考慮すべき品質に漏れがないかチェックするために、ふたたび規格を利用しましょう。ISO規格にSQuaREISO9126(こっちのほうが情報が多い)というソフトウェア(システム)の品質特性を定義したものがあります。品質特性の一覧を眺めて、重要かそうでもないかを考えます。
    ※なお前述した品質特性の例は規格の定義と一致してません

  4. まずテストの妥当性、そしてバグ収束曲線

    バグの収束はソフトウェアがリリースできるかどうかを判定する有効な指標です。ただしテストを十分にやったことが前提です。上述のように、埋めるべき地図を埋めていること、リスクを潰すよう探索ができていることを確認します。その上で、バグたちが駆逐されつつあるかを確認します。リリースを判定する人への説明では、少なくともこの2段階のストーリーを含めると説得力が増すでしょう。


以上とりあえず大事なことを4つ挙げました。テスト計画から外れた話もあるじゃないかというつっこみはごもっともです。
次はテストアーキテクチャについて議論しよう!なんて一人で盛り上がっても気持ち悪い先輩だと思われるだけなので自粛します。