テストはシステムの品質を向上させるためにも重要な工程ですが、他の工程と同様に、スケジュールやコストなどを考慮して行わなければなりません。
そのためには、テスト工程を問題なく進められるテスト計画を策定する必要あります。今回は、テスト計画書の作成目的や定義するべき要件についてご紹介します。
テスト計画書とは？
テスト計画書とは、テストにおける設計や実施、管理に伴う必要作業をまとめてその要件をリストアップしたドキュメントのことを指します。
例えば、テストの実施目的や対象範囲、実施方法、テスト時の体制や環境、納期などテスト全般に関わる方針をテスト計画書としてまとめます。具体的なテストの内容は、テスト方針に沿って決まっていきます。
そのため、テスト方針を明確に定義してテスト計画書に書いておき、具体的なテスト設計や実施に進められる準備を整えることが重要です。
作成の目的
テスト計画書を作る目的は、テストの抜け漏れをなくして、リリース後の不具合の頻発を防止することにあります。
リリース後に不具合が頻発してしまうシステムは、テスト工程で十分にテストが行われていなかったことが主な原因として挙げられます。これはつまり、明確なテスト計画が作られていなかったことによるものです。
過去の案件や社内で定義されたサンプルやテンプレートを流用して作成したために、目的に応じたテスト計画が作られなかったり、プロジェクトの都合で曖昧なテスト計画となってしまうケースは少なくありません。
このような状況では、クライアントやプロジェクトメンバー間での認識齟齬やテストが十分に実行されているかの判断もできなくなり、システムの品質低下につながります。
リリース後に不具合が頻発すると、修正コストが掛かるだけでなく、会社の信用問題にも大きく関わってくる問題に発展しかねません。こうした事態を招かないためにも、プロジェクトの目的に適した明確なテスト計画を策定することが重要となります。
テスト設計との違いとは？
テスト計画はテストの背景や目的、対象範囲などの全般的な内容を決定する工程です。一方、テスト設計はテスト計画で決めたテスト対象に基づいてテスト対象をより詳細化し、テスト実施の段階まで落とし込む工程です。
テスト設計は「それぞれの機能に対して、どのようなテスト観点・設計技法でテストしていくかを決定する」工程となります。テストを行う上で必要になってくる考え方や切り口であるテスト観点を整理して、テスト対象を網羅するためにはどのような設計技法を使ってテストするべきかを決定します。
テスト計画でテストの全般的な内容やスケジュールを決めて、テスト設計の工程にて、計画通りにテストを実施していきます。
テスト計画書に記載する要件
テスト計画書に記載する要件は、背景や目的からスケジュール、体制、発生しうるリスクまでさまざまにあります。
いずれもテストを実施するためには定義しておくべき内容なので、押さえておきましょう。
プロジェクト背景/テストの目的
プロジェクトの背景は何のためにどういったシステムを開発するのかなど、プロジェクトを発足するに至った経緯を指します。
そして、テストの目的はプロジェクトの背景を踏まえ、どれぐらいの品質を求めてテストを実施する必要があるのかを設定します。開発するシステムの規模に応じて適切なテストを実施できるよう、プロジェクトの背景とテスト目的から求められる品質を明確にしましょう。
テストアイテム
テストアイテムとは、テストを実施するにあたっての、各機能の個々の要素を指します。テストを実施するにあたって前もって一覧化することで、抜け漏れやメンバー間での認識齟齬を防ぎます。
アプローチ
効果的なテストを実施するための方法や手順を決定します。アプローチの決定は、テスト工程全体の方向性を左右する重要な要素です。代表的なアプローチにとして、次の7つが挙げられます。
1.分析的アプローチ
リスクの高い箇所や、ユーザーの業務フローにおける優先度などを分析して、そこを重点的にテストする進め方です。
2.モデルベースアプローチ
統計モデルなど、既存のモデルに基づいてテストする進め方です。統計データに基づいてユーザの使用頻度の高い機能などを割り出して、重点的にテストを進めます。
3.方法論的アプローチ
仕様や不具合を発見するための方法論に基づいてテストを進めます。エラー推測やフォールト攻撃を基にしたテストや、あらかじめ用意したチェックリストに沿ってテストを進めます。
4.プロセス準拠/標準準拠アプローチ
業界固有の標準に基づいたり、スクラム開発やアジャイル開発などの利用している開発プロセスに則ってテストを進めます。
5.動的で経験則に基づいたアプローチ
テスト設計者やテスターが、自身の経験に基づいてテストケースを実行したり、改良していく進め方です。
6.コンサルテーションベースアプローチ
対象システムの分野において深い知見のある専門家の助言や指導をもとにテストを進めます。
7.回帰的アプローチ
既存のテストを再利用したり、繰り返し実行できるテストを自動化してテストを進めます。
テスト開始、中断、再開、終了基準
テスト工程における開始や中断、再開、終了の基準をそれぞれ決定します。特に、終了基準は未解決や懸案事項、カバレッジの度合いなど総合的な判断をもとに定義する必要があります。
カバレッジについては、こちらの記事でも詳しく紹介しているのでぜひご確認ください。
テストスケジュール
テストで発生するタスクや、決定したアプローチに基づいてスケジュールを策定します。
体制
テストケース作成者やテスターは誰か、システム間ではどのように連携を取ってテストを実施するのかなど、体制図としてまとめます。
テストの成果物
テスト実施の成果として提出するものを決定します。例えば、テスト項目書やテスト結果報告書、不具合レポートなどが挙げられます。
コミュニケーション方法
どのようにコミュニケーションを取ってテストを進めていくのかを決定します。
定例会は対面で行うのか、それともWeb会議ツールを利用するのか、また用語の認識齟齬による混乱を避けるために、前もって用語の意味合いを文書化しておくなど、コミュニケーションが円滑になるように定義します。
BTSチケットフロー
BTS（Bug Tracking System）とは、検出された不具合の内容や不具合の対応予定、対応状況、履歴などをまとめるシステムです。1つの課題や不具合を管理する単位をチケットと呼びます。
「誰がこの課題に対応するのか」や「どの状態になれば解決とみなすのか」など、チケットを管理する上で必要な事項をまとめたものがBTSチケットフローです。
リスクと対策
テストの実施にあたって、想定されるリスクを洗い出します。そして、それぞれのリスクに対する対応策も、方針として計画書にまとめておきます。
【まとめ】テスト計画書の書き方をマスターしよう
テスト計画書は、目的やスケジュール、メンバー間の意思疎通など、テストをスムーズに進める上で必要な事項をまとめます。
記載が十分であれば、テストの抜け漏れや不具合が減少して、結果的に品質の向上につながります。品質を左右する大切なドキュメントのため、テスト計画書の書き方はマスターしておきましょう。
