Facebook x

ジャンル

テスト技法・工程
テスト技法・工程 2024.02.07
x hatenabookmark

テスト計画の策定|テストを円滑に進めるための3つの構成とポイント

監修: 布施 昌弘

バルテス・ホールディングス株式会社 R&C部 副部長

テスト計画の策定|テストを円滑に進めるための3つの構成とポイント

「テスト計画」とは、テストの設計、実装、実施、管理といった、テストのすべての指針を定めるものです。
「テスト計画書」とは、これらをまとめたドキュメントのことを指します。

そのテストが成功するか、それとも失敗してしまうか、多くはテスト計画で決まると言って過言ではありません。テスト計画が適切に策定できれば、テストプロジェクトは円滑に遂行される可能性が高まります。

本記事では、テスト計画の策定のための3つの構成について詳しく解説していきます。

もくじ
  1. テスト計画の3つの構成
  2. ①要求の整理・分析
  3. ②要求の実現方法
  4. ③各種管理の計画
  5. まとめ

1.テスト計画の3つの構成

テスト計画とは、テストの設計、実装、実施、管理といった、テストのすべての活動に対し、指針を定めるものです。そのテストが成功するか、失敗してしまうかはテスト計画で決まると言っても過言ではありません。

テスト計画の骨格は、以下の三つのパートで構成されます。

①要求の整理・分析

「①要求の整理・分析」では、テストに対する要求を正しく理解し、取り巻く状況を整理し、課題・リスクを抽出します。

  • テスト対象・範囲は何か
  • テストの目的・目標、重点項目は何か
  • テスト対象の開発状況はどうか
  • どんな課題やリスクがあるか

②要求の実現方法

要求と状況を整理した上で、課題とリスクを踏まえながら、「②要求の実現方法」で実行計画を策定します。

  • テストはどんな組み立てで行うか
  • ツールや環境はどんなものが必要か
  • テストプロセスで生成する成果物は何か
  • 各種基準や目標の詳細
  • 体制・役割分担・作業場所
  • スケジュール

③各種管理の計画

テストを下支えする各種マネジメントの準備を「③各種管理の計画」で定義します。

  • 課題管理、リスク管理
  • 不具合管理
  • 文書やデータの管理
  • 進捗管理・コミュニケーション

上記の三つのパートは、互いに関連しあっています。次章から各構成について詳しく解説していきます。

2.①要求の整理・分析

要求の整理・分析で、テストに対する要求を正しく理解し、取り巻く状況を整理し、課題・リスクを抽出します。そのテストが成功するか失敗してしまうのか、多くはテスト計画で決まると言って過言ではありません。

そのテストを計画する前に、以下3つを行います。

  • 要求を整理し、正しく理解する
  • 状況を整理し、正しく理解する
  • 未決事項・課題・リスクを整理し、戦略を練る

それぞれ詳しく解説していきます。

要求を整理し、正しく理解する

いかに技術的に秀でたテストを実施しても、顧客から求められるものに沿ったものでなければ、意味はありません。

そのため、さまざまな計画を検討する前に、まず、顧客やステークホルダから「何に対し、どんなテストを実施するよう求められているか」を確認します。

テストへの要求の、主な確認事項は以下のとおりです。

  • テスト対象は何か
  • テストの範囲は何か(特に他システムと関連する部分)
  • テストの規模はどの程度か(機能数や画面数や開発量など)
  • テストレベルは何か
  • 求められているテストタイプや観点(テスト条件)は何か
  • 顧客・ステークホルダが特に重視しているのは何か
  • テストの期間・コストはどれくらいか

上記の「テストへの要求」を明らかにする際には、なぜそれが要求されているのか、理由や背景も理解するようにします。

理由や背景を理解することで、開発プロジェクトが置かれた状況をより深く理解できます。ひいては、未決事項・課題・リスクの抽出に役立ちます。

状況を整理し、正しく理解する

テスト計画を策定するためには、テストへの要求だけでなく、ソフトウェアの開発状況や顧客・ステークホルダの状況なども整理していきます。

主な確認事項は以下のとおりです。

  • 開発規模(プログラムStep数など)
  • 開発難易度(スクラッチ開発、中核部分に大規模改修、新しい要素技術など)
  • 開発スタイル(ウォーターフォール型開発、アジャイル型開発など)
  • 仕様の明瞭さ(仕様書はそろっているか、曖昧でないかなど)
  • 開発でのレビューの実施状況、前工程でのテストの実施状況
  • 開発プロジェクトの進捗(何がオンスケジュールで、何が遅れているのか、及びその理由)

これらを確認するのは、以下を検討し、計画に反映するためです。

  • テストはどんなものが必要で、どのように進めるか
  • 仕様理解など、テストの設計・準備・実施の他に必要な作業は、何がどの程度か
  • 品質の良い・悪いはどの程度か、各タスクはどの程度の工数が必要か
  • 未決事項・課題・リスクは何か

未決事項・課題・リスクを整理し、戦略を練る

テストに求められているもの、開発の状況を整理したら、更に、未決事項・課題・リスクの整理を行います。

▼未決事項とは

まだ正式決定されていない、合意されていないものを指します。何が決定事項か未決事項か、意外に曖昧なことが多いです。

一つ一つを確認し、未決事項であれば、その影響範囲、重要度によって、対処の優先順位を設定します。

▼課題・リスクとは

課題とリスクの違いは、以下の通りです。

課題:既に何か問題が発生しており、それをいかに解決するか

リスク:まだ問題は発生していないが、未来に発生することが危ぶまれるもの

上記を踏まえて、計画を練っていく中で行いたいことは以下の二点です。

  • 未決事項や課題には、早期に適切に対策し、それを計画に盛り込む。
  • リスクを管理下に置き、問題そのものを起こさせないようにする。または問題が発生してもダメージがより小さくなるようにする。

上記によって、要求と状況に沿ったテストを適確に推進できるようにします。

「問題が起きてから対策する」のような「問題の後追い」をせず、未決事項や課題には計画的に対処していきます。さらに、リスクを管理下に置いて問題そのものが発生しないように、マネジメントします。

これらの整理をした上で計画を策定すると、考慮の漏れ抜けが防止でき、細かいところまで気を配り、マネジメント力を強化することができるのです。

3.②要求の実現方法

要求と状況を整理した上で、課題とリスクを踏まえながら、「要求の実現方法」で実行計画を策定します。

テストの粒度と実施順序

テストに要求されていることを元に、実施するテストタイプ(テストの種類)と粒度、実施順序を定めます。

例:単機能テストの正常パターンと限界パターンを優先的に行う

‐次に、準正常パターン、異常パターン、組合せパターンをテストする

‐性能テストは定期的に行う

‐リグレッションテストは自動テストで常に行う

このように、個々のテストを設計する前に、テストの全体を設計します。

ここで注意すべき点は「実施するテスト」を計画するだけでなく、「実施しないテスト」も計画することです。なぜそれをテストしないのか、理由も一緒に明らかにします。

使用する機材、ツール・環境

テストで使用する機材、ツール・環境は多岐に渡ります。

  • テスト設計に用いるもの
  • テスト実施に用いるもの
  • テストデータの作成に用いるもの
  • 不具合報告、管理、分析に用いるもの
  • 進捗管理、各種連絡に用いるもの
  • 構成管理、文書管理に用いるもの

これらを明らかにするとともに、機材の調達や、ツール・環境の準備に必要なタスクを洗い出し、計画に落とし込みます。

  • ライセンスの取得、ID登録の数やタイミング
  • 機材、ツール・環境のセットアップ、初期動作確認
  • テストデータの調達、作成
  • 不慣れなメンバがいる場合、レクチャーと必要に応じてリハーサル

これらの準備は、意外に時間も労力もかかります。あらかじめ計画しておかないと、後で突貫的に作業することが余儀なくされ、悪くすればテストの遅延が生じることになります。

成果物の定義

テストの成果物は、テストの各種プロセスからのoutputであり、さまざまなものがあります。 代表例を以下に記します。

■テスト計画プロセスからのoutput

  • テスト計画書

■テスト設計プロセスからのoutput

  • テスト設計仕様書
  • 機能動作確認一覧
  • テストマップ
  • テスト明細

■テスト実装プロセスからのoutput

  • テストデータ
  • テストケース

■問題解決プロセス

  • バグ票
  • 課題票
  • リスク票

■進捗管理・品質管理プロセスからのoutput

  • 各種 計測データと、そこから導き出される分析データと見解
  • 進捗報告、品質分析報告

■テスト終結プロセス

  • サマリーレポート

これら成果物を作成するタスクのWBS(Work Breakdown Structure)を作成し、開始日・終了日・担当者を割り振って実行計画に落とし込んでいきます。

基準・目標

基準

テスト開始基準、テスト終了基準、必要に応じて、テスト中断基準、テスト再開基準を設定します。

テスト開始基準.png

目標

テスト消化ペース、バグ票 起票のリードタイムなどの目標値を立てます。

テストの目標.png

体制・役割設計・作業場所

テストの各プロセスを実行する体制と役割設定、必要に応じて作業場所を定義します。このあとに控えるテスト設計を円滑に行うため、連絡・確認ルートなどを体制図などで表現します。

スケジュール

これまで検討した内容を、ガントチャート等で表現します。

ガントチャート等には、テストの設計、実施、不具合改修確認などのタスクだけでなく、テストデータの作成、ツールや環境構築、トレーニングなどのタスクも盛り込み、各タスクの前後関係を明らかにします。

ガントチャート等は、規模に応じて、テスト計画とは独立した文書にすることもあります。ガントチャートを別紙にする場合、テスト計画書には、そのガントチャートの内容のポリシー、計画の意図などを記載しておきます。

4.③各種管理の計画

テストを遂行する主軸は、計画、設計、実装、実施のプロセスです。

これらのプロセスを円滑に的確に運用するために、各種管理の準備・計画を行います。

各種管理の計画.png

まとめ

これまで説明してきたように、テスト計画に記載すべき事項は多岐に渡りますが、大きく分けると以下の三つのパートで構成されます。

  1. 要求の整理・分析
  2. 要求の実現方法
  3. 各種管理の計画

ポイントは、計画策定やテスト設計を行う前に、テストに対する要求を正しく理解し、取り巻く状況を整理することです。

要求を正しく理解し、状況を整理した上で計画を策定すると、考慮の漏れ抜けが防止でき、課題やリスクに対して配慮が行き届き、マネジメント力が向上します。

つまり、テスト計画は、テストへの要求を元に、テストの設計や管理の個別の事項に橋渡しをする、重要な役割を持っているのです。

テスト技法・工程
x hatenabookmark

監修: 布施 昌弘

バルテス・ホールディングス株式会社 R&C部 副部長

様々なテスト対象(組込み系、Web 系、金融系)の現場でテスト設計、テスト管理などを行う。現在は社内外のテスト関連教育セミナーの講師とコンテンツ制作、コンサルティングを担当する。JSTQB 認定 Advanced Level テストマネージャ。 著書は、『【この1冊でよくわかる】 ソフトウェアテストの教科書 [増補改訂 第2版]』、『いちばんやさしいソフトウェアテストの本』。