IEEE829
IEEEとは
IEEE（アイ・トリプル・イー、英: The Institute of Electrical and Electronics Engineers, Inc.）は、アメリカ合衆国に本部を持つ電気工学・電子工学技術の学会である。（Wikipediaより引用）
論文誌を出したり、IEEE829のような規格策定（標準化活動）を行っている。
IEEE829とは
IEEE Standard for Software and System Test Documentation
テストで作成するドキュメントの定義。
「ちゃんとテストするならテストを計画する段階で、こうゆうドキュメントが作られるはずだよね」というものです。「テストの用語定義」も含まれます。
「これらを揃えればバグがなくなる！」と言うものではないのですが、関係者の共通のコンテクストになるので、意味はあります。
全ての項目を網羅する必要はなく、必要に応じて取捨選択し、準備すべきものを意識してテスト設計・実施することで効率的に品質を担保できればそれで良いと思います。
メジャーバージョンは1998と2008の2つがあります。
2008のほうが業務向きに洗練されていますが、その分複雑になっているので普通のソフトウェアなら1998で十分かと思います。
|SEQ|名前|name|内容|例|
|:------------------|:------------------|:------------------|:------------------|:------------------|:------------------|
|1|テストプラン文書番号|Test Plan Identifier|組織内での管理番号。構成管理物としてバージョン番号もつける。「Ver1」でも日付でもよい。|○○_ITテスト仕様書ver1.0|
|2 |レファレンス |References |テストプランに関連するドキュメントを列挙する。|プロジェクトプラン、要求仕様書、UI仕様書|
|3 |はじめに |Introduction |テスト対象となるシステム・ソフトウェアや機能のサマリーを記述する。開発のコンテキスト、他のドキュメント（プロジェクト計画書・製品企画書・サービス企画書・品質保証計画書など）との相関についてを記述する。「なぜテストプランを書かねばならないのか」「今後のテストはどういう方向性で作業を進めていくのか」「どういう品質の製品を出したいのか」|○○のリリースにあたり、品質保証するため開発部品とその関連機能についての内部結合試験を実施する。|
|4 |テストアイテム |Test items|テスト対象について具体的に記述する。テスト対象について規定したドキュメントもここに記述する。ビルドのバージョンやソースコード名、テストで用いるハードウェアや外部機器との組み合わせなどのテスト対象について具体的に記述する。|管理ツール プロジェクト名 ブランチ名|
|5 |テストするべき機能|Features to be tested|テスト対象となる機能を記述する。ここではテストアイテムとの違いを意識する。コンポーネントやサブシステム単位に分かれる場合はそういった分け方でもよい。|○○インポート □□インポート|
|6 |テストする必要のない機能|Features not to be tested|プロジェクト全体に関してテストでの責任・保証範囲を明確にするために、テスト対象としないものを規定する。システムを段階的に構築する場合において、すべての機能を一度にテストしないときなどに、テストを実施しない機能を明示することができる。※他社製品などある場合、この項目は上長に承認を得たほうが良い。テストを要求された場合は、予算と人員、スケジュールを確保すること。|入会 マイページ ○○連携|
|7 |アプローチ|Approach|テストによる評価と検証のためのテスト戦略とテスト戦術について記述する。ここがテスト計画の肝になる。どんな種類のテストを誰がいつ実施するか。ホワイトボックステスト「すべてのテストケースはカバレッジツールでモニターされ、ブランチカバレッジで90%以上を実現する」 ブラックボックステスト「同値分割、境界値分析を実施する」|・テストの準備期間で作成した仕様書に基づき試験を実施し、システムが業務用件、処理概要に合致していることを確認する。
・機能テスト
・各機能が機能仕様書に則った動作をしているか ・結合テスト|
|8|テストアイテムの合否判定基準|Item pass/fail criteria|テスト全体で用いる合否判定基準を記述する。個別のテスト結果だけではなく、業界標準や社内標準、物理的制約などのテスト対象が満足すべき前提や条件があれば、ここに記述する。|■開始条件
開発済み
環境構築済み
仕様書の作成、レビュー済み
■終了条件
・重要度が「高」のバグ残存なし
・全ケースの98%をパスしている
・48時間以内に重要度「高」のバグなし
・「次」の欠陥を見つけるのに要する限界コストが、
その欠陥で生じると予想される損害額よりも大きくなった|
|9|中止基準と再開要件|Suspension criteria and resumption requirements|バグが出すぎて続行する意味がないような場合のテストを中止する基準と再開するための要件を記述する。
どんな状態になったら危険な状態なのか分かるようにする。|KLOC数あたりのバグが平均値60の倍以上の場合
続行不可能なバグが出た場合|
|10|テスト成果物|Test deliverables|テストの結果としてアウトプットされるドキュメントや証跡を記述する。また、成果物に含まないものも記述しておく。
（業界的には、委託なら納品物・成果物が大抵必要になり、準委任契約ならあっても納品物や成果物という呼び方をしない）|○○_IT仕様書ver1.0
○○_IT結果報告書
○○_ITインシデント報告書|
|11|テスティングタスク|Testing tasks|スケジュールや工数を見積るにあたり必要となるタスクを記述する。|管理作業
テスト分析
設計
準備
実施|
|12| 実行環境 |Enviromental needs|テストを実行する環境を記述する。
調達に時間が掛かるようなものを記述する。|STGxxxxサーバー
db_name|
|13| 責任範囲| Responsibilities| テストチームの中の役割と担うタスク、責任者を記述する。|リーダー：○○, サブリーダー：○△
テスト設計：△△, テスト環境構築：△×|
|14|人員計画とトレーニングプラン |Staffing and training needs|以下の項目を鑑みながら綿密に計画を立てる。
・終盤に人員を投入しても遅れは取り戻せない。中盤前くらいに厚めに投入する。
・バグを見つけるコスト
・テストケースを作成及び実行するコスト ・修正されたバグを確認するコスト ・ミーティング時間 ・ドキュメンテーション時間 ・開発者へ説明する時間 ・ハードウェアコスト ・ソフトウェアコスト ・出張費 ・トレーニングコスト|
|15|スケジュール|Schedule|スケジュールは重要だが、正確に見積もることは困難なので、コントロール可能なスケジュールを策定する。
2週間間隔くらいで見直すようにする。
コントロールしやすくする要素・・・スケジュール管理ソフトウェアの利用、開発関連情報（KLOC、API数、UIの数など）
スケジュールに影響する要素・・・バグの数、コードの再利用化率、予算、開発者との関係、チーム構成、チームのモチベーション、チームの成熟度|
|16|リスクとその対策|Risks and contingencies|リスクは「起こり得る可能性のある問題」を記述する。
リスク＝問題の起こる確率＊問題が起こったときのダメージ
複雑度、新規性、変更、上位依存性などがリスク要因となる。|環境設定起因による○○
外部要因（外部APIトラブル等）によるスケジュールの遅延|
|17|承認|Approvals|組織として承認を取るべき人を記述する。|プロジェクトマネージャー、開発責任者、自分の上司|
所感
このドキュメントの定義を知る前は、テストケース作成の際に作業者が「ただ上流からケースを書き起こしていく」といった手順でシナリオを完成させていたので、検証対象外の機能にまで範囲が広がったり、逆に検証対象機能へのアプローチが疎かだったりしていたように思います。
共通認識のようなものを最初に作ることで、その後の議論・作成・レビューがスムーズにいくのではないでしょうか。
上記の全てではなくても、適用できる部分は積極的に導入していきたいと思います。