テスト計画の要素と根拠

対象読者

テスト計画の存在意義と目的がいまいちわからない人
TestRailのようなツールはなく自分の脳とExcelだけを頼ってテスト管理をする必要がある人(こじつけ)

この記事を読んで得られるもの

テスト計画の存在意義をイメージできるようになる

大前提

• プロジェクトのドキュメントは別の根拠となるドキュメントがある。
  ここではこれをインプットと呼ぶ。
• テスト計画書にもインプットがある。
• また、あるドキュメントは別の成果物の根拠となる。
• この時、ドキュメントを参照する別の成果物やアクションをアウトプットと呼ぶ。
• テスト計画書にもアウトプットがある。
• インプットとアウトプットという関係で結ばれたドキュメント間のつながりを
  トレーサビリティと呼ぶ。
  (※trace = 追跡する traceability = 追跡可能なこと)

小前提 テスト計画をとりまくドキュメント

存在意義を理解するために、テスト計画のトレーサビリティを見ていこう。
テストにおける成果物たち全体を理解すると、その中でのテスト計画書の位置づけ、つまりテスト計画だけが担える役割を理解することができるからだ。

まず、テスト計画書の上流には2つのドキュメントがある。
(並列しているのではなく、直列でつながっている点に注意)
すなわち、テストポリシーとテスト戦略だ。

それらを一つ一つを紹介する。

テスト計画のインプット

テストポリシー

目的

組織がテストを行う理由を示す

構成要素

組織がテストから得られる価値

価値の例：

• リリース前に欠陥を修正する
• リリース前に欠陥を検出し回避策を決定する
• プロジェクト、プロセス、プロダクトについてのステータスの情報提供
• 品質の向上
• スムーズで予定を立てやすいリリース
• システムがうまく動くなどの確信度合いの向上
• システムが法律で定められた品質を保っていることを確認する
• システムが果たすべき機能を果たす
• システムが損害をもたらすリスクを軽減する

テストの目的

目的はバグの発見、信頼の積み上げなど、多様な観点から記述できる。

テストの有効性と効率性を評価する方法

例：信頼度成長曲線

一般的なテストプロセス

例：計画→分析→設計→実装→実行...など。
拙文だがこちらにまとめているhttps://qiita.com/MaiTana/items/e07aa526c0cc2de5f95f

テストプロセスの改善方法

テスト改善モデルの例：TMMi🄬, STEP, CTP, TPI Next🄬

テスト戦略

目的

組織の一般的なテストの方法を定義する

構成要素

• プロジェクト面のリスクマネジメントの方法
• プロダクト面のリスクマネジメントの方法
• テストの段階のブレークダウン(例：単体テスト、結合テスト...)
• テストの開始基準と終了基準
  • テストを開始するための基準
  • テストを終了するための基準
• テストのプロセス
• 一般的なテストの方法(補足セクションに後述)

テスト計画のアウトプット

テスト計画本体の話...

に入る前にテスト計画のアウトプット側を見る。
その方がテスト計画の中身の要素の存在意義が分かりやすいと思うので。

テスト関連のドキュメントのとテスト計画との関係性を図に表した。
この中で、テスト計画は4つのアウトプットにつながる。
①テスト技法の情報を提供し、テストケースのアウトプットに使われる。
②テストメトリクスを定義し、テストの進捗のモニタリングを可能にする。
③モニタリングする際、予定と実際の比較を行う。その予定を提供する。
④コントロールできる要素に何があるかを示す。

さて、上記のアウトプットのために、
テスト計画はどのような構成要素を持つのかを見ていく。

テスト計画本体

テスト計画には2種類ある。
マスターテスト計画とレベルテスト計画だ。
マスターテスト計画は単体テスト~ユーザー受け入れテストなど複数のレベルのテストに共通の要素を定義する。
一方、レベルテスト計画は個々のレベルのテストの計画を定義する。
それでは1つ1つ見ていこう。

マスターテスト計画

目的

テストの目的を達成するために必要なアクションとリソースを定義する

要素

• プロジェクトのガイド
  つまり、プロジェクトを推進するための判断を助けたり必要な情報を提供する。

  • スケジュール
  • 役割

• 計画から逸脱していないかの判断の拠り所

• 目標の達成を評価するためのメトリクス

• 実行するテストレベル (単体テスト、結合テスト、システムテストetc.)

• テストレベル間の関係 (テスト同士の棲み分け的なもの)

• テストレベルと対応する開発活動 (V字モデルを参照)

• テスト戦略の実装方法
  (テスト戦略は前述。例えばリスクベーストテストを行うために、リスクを聞き出すワークショップを設けるなど。戦略は絵に描いた餅ではダメなので、テスト計画で実現方法を記載する)

• テストする項目としない項目

インプットの補足

テスト戦略のほかに仕様、要件とリスクがある。

アウトプット

• 採用するテストレベル

• 各レベルの目標と目的

• 各レベルで使用するテスト技法

• テストのスコープ範囲内と範囲外の機能

• テスト環境の仕様の定義

• 必要な環境や要員などのリソースを使えるかの確認
  (例：アサインしたけど別PJでテスト要員が使えなかった!なんて場合もある)

• 環境設定の担当者にタスクを割り当てたことの確認

• テスト環境のための準備の作業

• コスト、納品スケジュールを把握するための要求事項

• 外部との依存関係と関連するSLA
  外部とは

  • 外部の組織へのリソースの要求
    (例：ユーザーにテストを依頼する場合はユーザーのリソースを要求する)

• 同じプログラム内の他のプロジェクト
  (例：ウェブアプリ開発プロジェクトとアプリで使うデータベース移行プロジェクトが1つのプログラムの中で進む場合)

• 外部ベンダー

• テスト計画においてテストポリシーとテスト戦略から逸脱している部分
  (例：テスト戦略ではシステムテストを行うことが指定されているが、今回の計画では行わない)

  • 逸脱する計画をした理由
  • 逸脱による影響
  • それに対するリスク対応

• テストする/しない品質特性
  (※品質特性が何かはこちらを参照ください)

• テストスケジュールと予算

• テストレベルごとの開始基準と終了基準

• テストレベルごとのインプットとアウトプット

• テストにまつわるプロジェクトリスク
  (例：テストがクリティカルパス上にあるがテスターのスキルが低い)

• テストが依存する活動

• テストが依存する活動から受ける影響と関連

• テスト終了作業

  • テスト完了基準を満たしていることの検証
  • テスト成果物の納品
    (例：テスト結果)
  • 学習した教訓を記録
  • ドキュメントなどを整理して保管

レベルテスト計画

マスターテスト計画を個別のテストレベルに適用できるよう、
調整したテスト計画。

アウトプット

マスターテスト計画をより詳細化したスケジュール、タスクなど。
(例：マスターテスト計画では週単位でスケジュールを作成したが、レベルテスト計画では結合テストのための1日単位のスケジュールとした。)

テスト計画のアウトプットの詳細

さて、以上でテスト計画本体をみてきた。
ここで再びテスト計画のアウトプットを深堀りする。
これによってテスト計画本体の存在意義への理解を深めよう!

①テスト技法の情報を提供し、テストケースのアウトプットに使われる。
②テストメトリクスを定義し、テストの進捗のモニタリングを可能にする。
③モニタリングする際、予定と実際の比較を行う。その予定を提供する。
④コントロールできる要素に何があるかを示す。

①テスト技法

技法も多様である。それぞれに使いどころやメリットとデメリットがある。
各手法の説明はIPAの資料やQbookのサイトの参照をお願いします。

上のポジショニングマップの引用元↓

②テストメトリクス

拙文だが以下の記事でご紹介しているので参照されたし。

③モニタリングとコントロール

アウトプット側にあるモニタリングとコントロールがどのようなものかを説明する。
それらのアクションをとるために、テスト計画が参照されたり、更新されたりする。

モニタリング

• 使えるリソース(テスト環境や要員)とテストの成果物(テスト結果やシステム)とをモニタリングする
• モニタリング結果をテスト計画・戦略と比較する
  そして、比較して、計画・戦略とのギャップがあればコントロールを行う。

コントロール

• プロダクトリスクの見直しと更新
  (例：画像が表示されない故障がリスクだったが、修正されたのでリスクリストから削除した)
• テストの優先度の見直しと更新
  (例：残り時間が少ないため、故障時のリスクが大きい機能を先にテストすることにした)
• 計画の見直し
  (例：他の作業をしている人をテスト担当に変えた)
• クラッシング、ファストトラッキングの開始
  (例：テストを行う人数を増やした)
• リリース日の延期
• テスト終了基準の緩和、厳格化
• プロジェクトのスコープ変更

おまけ テスト戦略内で定義されるテストの方法

テストの方法には色々ある。
それらを紹介する。

分析的戦略

• リスクベースドテスト
  平たくいうと、欠陥による影響が大きい機能を優先してテストするアプローチ。
• 要件ベースドテスト
  要件を網羅することを目指してテストするアプローチ。

モデルベースド戦略

• ユーザーが5年後、10年後に増加するなどの想定でテストするアプローチ。

系統的戦略

• よく使われるチェックリストやテスト項目に基づいてテストするアプローチ。

プロセス準拠、規格準拠戦略

• 金融系のシステムなど、遵守すべきテストのルールが権威ある組織に定められている場合、それに従ってテストするアプローチ。

対処的戦略

例：探索的テスト

コンサルテーションベースの戦略

例：テストの専門家にテストのサポートをもらう(雑)

回帰的テスト戦略

またの名をリグレッションテスト。
開発によって既存の機能が動作しなくなるというデグレードがないかを確認する。

参考資料

テスト技術者資格制度 Advanced Level シラバス日本語版
テストマネージャ Version 2012.J04