テスト文書に迷ったらISO 29119を参考にしよう

ISO 29119は、ソフトウェアテストに関する国際規格です。テスト計画書やテスト完了報告書を作成するとき、「何を書けばよいのだろう」と悩んだ経験はないでしょうか。

ISO 29119とは

ISO 29119の各規格の概要や発行状況は、ISOの公式サイトで確認できます。本文では、実務で参照しやすいPartを中心に紹介します。

ISO 29119はソフトウェアテストの国際規格群です。特定の業界に限定されず、さまざまな組織で活用できるよう整備されています。

本記事で取り上げる主要なPartを、対象テーマ、実務で役立つ場面、現行版の観点で整理します。なお、ISO 29119シリーズには、ここに掲載していないPartもあります。本記事では、ソフトウェアテストの基本とテストドキュメントの作成に関係が深いPart 1～5に加え、AIベースシステムを扱うPart 11を取り上げます。

何を書けばよいか困ったときに使う

私が実務で特に参考にしていたのは、テストドキュメントを扱うPart 3です。テスト計画書を白紙から作成すると、重要な項目を見落としがちです。経験だけに頼ると、抜け漏れが発生することがあります。例えば、テスト対象は記載していても対象外が明確でない、スケジュールはあっても完了条件がない、テスト環境は定めていても準備の担当者が決まっていない、といった抜けが生じます。

ISO 29119 Part 3をチェックリストとして活用する

そのようなとき、Part 3に示されたテストドキュメントの構成や情報項目を確認します。Part 3では、テスト方針やテスト計画、テスト状況報告、テスト完了報告のほか、テストケース、テスト手順、テストデータ要求、テスト環境要求などを扱っています。私はこれらを、規格どおりの文書を作るためではなく、検討項目のチェックリストとして活用していました。

図：ISO 29119 Part 3で扱うテストドキュメントの構成

私はこれらを、規格どおりの文書を作るためというより、検討項目のチェックリストとして利用していました。

白紙から考えるより問いを立てる

規格の項目を手掛かりに、次の観点を確認します。

• テストの目的と対象範囲
• テスト方法、必要な環境やデータ
• 設計・実行・判定の担当者
• テストの開始条件と完了条件

このように問いを立てることで、白紙の状態から考えるよりも効率よくテスト計画を整理できます。

ISO 29119の項目をすべて書く必要はない

ISO 29119を参考にするときは、規格に示された情報をすべて個別の文書として作成する必要はありません。プロジェクトの規模やリスクに応じて必要な情報を選択します。例えば、小規模なプロジェクトでは、テスト計画とテスト戦略を一つの文書にまとめられます。テストケースとテスト手順を同じ管理表で管理することも可能です。テスト状況はダッシュボードで共有し、テスト完了報告をリリース判定資料に含める方法もあります。アジャイル開発では、Wikiやチケット管理ツール、テスト管理ツールなどで情報を管理することもあります。すでに他の文書に記載されている内容は転記せず、参照先を示せば十分です。重要なのは文書の数ではありません。テストの実施や意思決定に必要な情報が整理され、関係者が確認できることです。

品質担当として開発者に勧めていたこと

私は品質を担当する立場として、テスト計画やテストドキュメントの作成に迷っている開発者に、ISO 29119を参考にすることを勧めていました。品質担当者が規格を読み、作成したテンプレートを開発者に渡す方法もあります。しかし、実際にシステムを開発し、テストする開発者自身が規格の観点を知ることにも意味があります。テストドキュメントは、後から実績を残すためだけのものではありません。作成する過程で、テストの目的、範囲、方法、リスクを整理できます。

何を、なぜ確認するのか。どこを重点的に確認するのか。どのような状態になったらテストを完了できるのか。確認できない領域には、どのようなリスクが残るのか。このような問いに答えることが、テスト計画を作るということです。ISO 29119は、そのための観点を与えてくれます。開発者に勧める際も、「規格に合わせて立派な文書を作ってください」という伝え方はしていませんでした。「何を書けばよいか分からなければ、まずPart 3を見てみるとよいですよ」と案内していました。規格を守ること自体を目的にするのではなく、考慮すべき事項の抜け漏れを減らすために利用します。

ISO 29119で学んだ「テストしないこと」

ISO 29119のテストドキュメントを参考にする中で、私が特に役立つと感じたのが、「何をテストしないのか」を明確にすることでした。テスト計画を作るときは、どうしても「何をテストするか」に意識が向きます。しかし、プロジェクトの期間、予算、要員には限りがあります。考えられるすべての条件を、同じ深さでテストすることはできません。

テスト対象外を明確にする

対象外にする理由を説明する

ただし、「対象外」と一言書くだけでは不十分です。対象外とする理由、残るリスク、別のチームや工程での確認の有無、運用監視などによる補完策、判断の承認者も併せて整理します。「時間がないからテストしない」という理由だけでは、品質上の判断として十分ではありません。時間が限られているのであれば、どのリスクを優先し、どのリスクを受け入れるのかを明確にする必要があります。テストしないことを書くのは、品質を諦めることではありません。むしろ、重要な領域にリソースを集中させるための判断です。残るリスクを可視化する効果もあります。

テスト対象外項目をレビューする

テスト対象外は、文書に書いただけでは十分な効果を発揮しません。

記載内容を関係者とレビューする

プロジェクト管理への応用

私は「テストしないことを書く」という考え方を応用し、テスト以外の活動でも「実施しないこと」を記載するようにしました。プロジェクト計画書には実施する作業が詳しく書かれますが、実施しない作業は意外と明記されていません。その結果、プロジェクトが進んでから、「これもやってくれると思っていた」という期待のずれが生じます。この場合も、書くだけでは不十分です。実施しない理由と影響を関係者とレビューします。「書いていないから実施しない」のではなく、「実施しないことを明示し、その理由と影響について合意する」ことが大切です。

ISO 29119は迷ったときに戻れる参考資料

（佐野　忠）