テスト戦略～テスト計画プロセスにおけるテスト戦略の考え方～

テスト戦略は、SHIFTではテスト計画の一要素としていますので、まずはテスト計画の基礎から解説を行います。
テスト計画はソフトウェアテストにおける最初の工程にあたり、何をどのようにテストをするかといったソフトウェアテストの全体像を示した全体テスト計画書と、それをインプットにした個別テスト計画書のドキュメントを作成します。テスト計画は、品質の高いソフトウェアを実現するためのテストを行ううえで必要不可欠な工程です。

ソフトウェアテストを実施してシステムやサービスをリリースしても不具合が頻発するということがあります。SHIFTでは数多くテストを行ってきた経験から、不具合が頻発する背景には、行うべきテストの抜け漏れがあり、それが不具合の原因の一つとなっていることが多いことがわかりました。また、テスト計画に抜け漏れがあるため、テスト実行段階になってテストの現場が混乱に陥るということもよく見られます。テストの抜け漏れの原因は、テスト計画書が不十分なものになってしまっている、いわゆる「見かけだけのテスト計画書」に多くあるといえます。

例えば、社内標準のサンプルをそのまま使っていたり、過去のテスト計画をそのまま使いまわしたり、先にスケジュールを決めてから対象や方法を後から決めてしまったりすることで、目的に応じた計画ができておらず、必要なテストが抜けてしまっているケースなどがよくあります。
このようなケースから、現場において「関係者間の認識齟齬の発生」「各テストレベルの目的が不明確」「十分なテスト実行ができているかの判断ができない」というような問題が発生してしまうのです。

そんな事態を防ぐため、SHIFTではプロジェクトの目的に適した抜け漏れのないテスト計画が、ソフトウェアの品質を高めるソフトウェアテストにおいてとても重要と考えます。

SHIFTの※SQF(SHIFT Quality Framework)では、テスト計画作成のプロセスは以下のように定義しています。プロジェクトの目的に適した抜け漏れのないテスト計画を立案するには、テストをどう進めていくかというテスト戦略についての十分な検討が必要となります。

※SQF(SHIFT Quality Framework)は、SHIFT独自の品質保証標準です。SQFでは、プロセスや各工程の手順を示すガイドライン、各種ドキュメントの雛形が定義されているため、高品質の品質保証サービスを要員に依存することなく、再現性高く提供することが可能です。

経験が浅いテスト担当者は「計画」という言葉のイメージから、スケジュール表を先行してつくってしまいがちですが、テスト計画で最初にやるべきなのはテストの対象を明確にして、限られた期間のなかで何をどのようにテストするのかを決めることです。テスト戦略では、①テスト対象の把握、②テストリスクの把握、③テストアプローチの検討の順で進めます。

システム・要件レベルでテスト対象の概要および求められる品質特性を把握します。

テストを実施するうえで気にしておくべきリスクを抽出し、対策を検討しておきます。例えば、テストに新しい装置を使用するのであれば、テスト実施までに調達できるのか、操作の習得ができるのかといったことを検討しておくことが大事です。またテスト対象が変更されるリスクなども考えておく必要があります。

要件ごとに要件に求められる品質特性のなかで、何を重要視すべきかを考え、テストアプローチを検討します。7つのテスト戦略(分析的戦略、モデル戦略、系統的戦略、プロセス規格準拠戦略、対処的戦略、コンサル戦略、リグレッション回避戦略)なども参考にします。

次に、具体的にどのようにテストを実施していくのか、テストレベルとテストタイプを決定していきます。テストレベルとは、テスト対象を区切る粒度のことです。テスト対象やテストの目的、インプットする情報によって分類されます。「単体テスト(ユニットテスト、UTなどと呼ぶ現場もあります)」「結合テスト(統合テスト、ITなど)」「総合テスト(システムテスト、STなど)」「受け入れテスト(UAT)」の4段階に区切る分類方法が一般的です。

しかし、組織やプロジェクトごとに違いがあります。どのようなテストレベルの呼び方にして、何を確認することになっているのか決めておくことが必要です。テスト計画書はこのテストレベル単位に作成します。

テストタイプとは、テストの目的ごとにテストを分類したもので「機能テスト」や「性能テスト」「負荷テスト」「使用性テスト」などが該当します。

テスト対象の要件ごとに、その品質特性に応じたテストタイプを、どのテストレベルで誰が実行するのか「テストタイプ－テストレベル対応表(下図)」などの形でまとめ、テストが漏れていたり、重複したりすることがないかを確認します。また、テスト全体を効率よく進めるため、手動テスト以外に、テスト自動化やツールの導入、過去のテスト資産の再利用もあわせて検討を行っていきます。

最後に、テストベースと呼ばれるテスト設計の入力が何になるのかを「テストベース対応表(下図)」などを用いて確認し、テストを実施するにあたっての制約条件を明確にしておきます。テストベースの確認をすることにより、テストに必要な仕様書や設計書の作成漏れを防ぎます。また、テストタイプとテストベースの紐づけができないものを確認することによりテストの漏れを確認することができます。

これらの作業を行い、テスト戦略が明らかになった後にテスト計画書の作成に進みます。

SHIFTはプロジェクト特性やリスク分析結果を加味し、何を、いつ、どうやって誰がテストするのかプロジェクトごとに指針を策定します。このノウハウを使って、お客様の策定したテスト計画が、プロジェクトの定めた指針に基づいているのかといったチェックも可能にしています。

テスト計画では、プロジェクト計画書、マスタースケジュールなどの「プロジェクト関連ドキュメント」、要件定義書、システム仕様書などの「システム関連ドキュメント」といったテストベースを基にテスト計画書を作成します。

テスト計画書には2種類あります。それがプロジェクト全体の計画書である「全体テスト計画書」とテストレベル別のテスト計画書となる「個別テスト計画書」です。

全体テスト計画ではテストにおける全体像を俯瞰し、限られたリソースやリリースの時期をふまえたうえで、実施するテストの目的、対象、方法、メンバーの役割、スケジュール、管理の仕方などを定義し、全体テスト計画書に記載します。全体テスト計画書は経営層などの上位マネジメントやユーザー企業や接続先システムの開発会社といった広義のプロジェクト関係者向けに共有することを意識し、作成することが大切です。

全体テスト計画書のドキュメントをもとに、実施想定の単体テストや結合テストなどのテストレベルごとに個別テスト計画書を作成する個別テスト計画を実施します。個別テスト計画書は直接プロジェクトに関わるメンバー、特にテストを担当するメンバーが対象です。テスト設計プロセスの直接的なインプットとなるため、テスト設計作業に与える影響も大きくなります。

これらのようなテスト計画をまず、プロジェクト初期段階(要件定義工程）で定めた後、さらに実行性のあるものにするためには、以下がポイントです。

・現場を想定した現実的なものであること
・優先度などを加味した全体の最適化が図られていること
・テストを実施するメンバーへの共有がされていること

テスト計画書に記載する項目は多岐に渡りますが、各項目に書くべきことを明確にしたうえで、組織やプロジェクトで規定されたフォーマットに沿ってドキュメントを記述します。
SHIFTでは、環境やデータ、担当者のリソースなど、テストであらかじめ準備しておくべきことを含めた詳細なテスト計画を立てています。それにより、実行段階での混乱や手戻りを防ぎ、スケジュールやコストを想定の範囲内におさめています。

今回は、テスト戦略からテスト計画書作成までの流れについて、解説を行いました。
精度の高いテスト計画書を作るためにも、テスト戦略の考え方や考慮すべき点を押さえることは必須条件となりますので、まだテスト計画に慣れていない方は、時々初心に帰って当コラムを見直しされることをオススメいたします。また、SHIFTでは、テスト計画書のテンプレートもご用意しておりますので、ぜひダウンロードのうえ、今回確認してきた手順に沿ってテスト計画を作成いただければと思います。