開発フェーズ編 -
第２８章　パッケージテスト・評価

２８．１ 目的

パッケージテスト・評価フェーズでは、パッケージの総合的なテストおよび評価を行う。

２８．２ 作業ドキュメント

パッケージテスト・評価で作成するドキュメントの一覧を示す。

ドキュメント名	解説	様式番号
バグシート	バグが発生したときに記述する	7-01

２８．３ 作業項目の解説

再利用コンポーネントのテスト

パッケージのテストはコンポーネントレベル、パッケージレベルというように、開発フェーズをさかのぼるような順番で行われることになる。

コンポーネントレベルのテストは実装担当者の責任で行われる。コンポーネントレベルのテスト後は、ソースファイルはチームで一括管理され、この時点からバグシートが作成される。つまり、Dropでは、個人の管理からプロジェクトの管理に移った時点より発生する問題についてバグとして管理されることになる。

バグシートはこの段階から発行される。そして、その原因が判明し解決した後新たなバージョンとしてソフトウェアがリリースされるまでの間、記録として保管されることになる。バグシートは、バグの対応を円滑に行えるよう、テスト、解析、修正のそれぞれのセクションの窓口を決め、メール等によって交換されることになるだろう。そして、解決状況が把握できるように、テスト管理者によってデータベース化されなければならない。 バグが解決した後は、バグシートの原因分析情報の統計を取ることにより、プロジェクトチームの問題点や改善点を把握することも使われることになる。

クラスレベルのテストがある程度完了すると、次はパッケージレベルのテストを行うことになる。ここでは、パッケージのテストを行うために、以下の方法が取られることになるだろう。

• 必要となるいくつかのスタブやドライバのプログラムを作成してテストを行う。
• 他のパッケージと結合してテストする。
• ADGによって開発中のアプリケーションを使ってテストする。

コンポーネントテストのためには、テスト管理者によって作成されるテスト項目表をクリアすることが目標とされるが、実際にはテスト項目票に網羅できていないテスト内容があることも多い。よって、テスト実行者はテスト項目票をクリアすることを最低条件としなければならない。実際システムを使ってみて気が付いたケースをテスト項目票に新たに加えながらテストを実施していくことが必要となる。

それぞれのテストは、以下のような責任範囲で実施される。なお、テスト管理者はシステム管理者が行うこともあれば、製品開発などではテストチームを組織してその管理者に行わせることもあるだろう。

クラスレベルテスト	コンポーネント実装者(担当者)
パッケージレベルテスト	コンポーネント分析者（テスト管理者）

コンポーネントレベルテスト

1. 機能テスト：コンポーネントの提供するサービス単位でのテスト
2. 資源テスト：使用した動作環境の資源の後始末テスト
3. 網羅テスト：コンポーネントを構成するクラスを単位に、エラー経路を含めて起きうるパスのテスト

パッケージレベルテスト

1. 操作テスト：コンポーネントの提供するサービス単位のテスト
2. 障害テスト：パッケージとして保証する障害時の仕様テスト
3. 資源テスト：使用した動作環境の資源の後始末テスト
4. 過負荷テスト：コンポーネントの仕様として定めている、様々な制限値を越えた時、または越えそうな時に、仕様通りの動作がなされるか。予測していない動作をしないかどうかコンポーネントに負荷を与えて行うテスト
5. 品質テスト：多態性実現のために付加されているコードや、メソッドインタフェース名の付与の一貫性など、再利用構築基盤の形成という観点でコードインスペクションを行う

パッケージの評価

パッケージの評価は、パッケージテストが完了に近づいた頃に行う作業として位置づけられる。パッケージの評価とは、ODGの提供するパッケージ（コンポーネント群やフレームワーク)開発全般を様々な評価項目を使って、コンポーネント分析者が中心となりODG全体で議論を行うものである。そして、チームとして改善すべき欠点や伸ばすべき長所をチーム全体で把握するために評価資料を作成する。

この評価作業には「自分たちの開発プロセス全般を、客観的な視点で考察することができるか？」ということが重要となる。この評価がチーム全体として上手になれば、開発の度にチームコンピューテイング能力が強化されることになるだろう。

コンポーネント要求の評価

システム要求の評価と同様に、コンポーネント分析フェーズにて定義されるコンポーネント要求自身の要求に対する評価を行う。

• 本当にコンポーネントユーザ要求を組み入れることが可能なコンポーネントであったか？
  もし、そうでないとすれば、コンポーネントユーザの要求が組み入れにくかった原因はどこにあったのだろうか？
• 開発期間、開発工数を考慮されたコンポーネント要求であったか？
  結果として、要求に基づいたスケジュールであったかどうかを判断する？
• コンポーネントユーザ満足度はどの程度か。
  これは、ユーザに利用アンケートを取り、その集計結果によって判断しなければならないため評価フェーズの期間を越えて長期に調査を行うことが必要とされる。
• 柔軟にコンポーネント仕様の変更に応じたか？
  システム開発からでたコンポーネント開発に対する要求の変更について柔軟に対応し、かつ、コンポーネントしてのコンセプトが崩れないよう配慮がなされただろうか？もし、コンポーネントユーザからの要求変更が相次ぎコンポーネントとしてのコンセプトが保てなかった場合、コンポーネントとして作り直す必要性を議論する。

コンポーネント要求に基づく評価

コンポーネント開発の中で作成されるパッケージ利用解説書は、開発するコンポーネントにおいて「何を作るべきか」という指標として開発中・開発後に使われるものでなければならない。つまり、パッケージ利用解説書は、開発中のコンポーネント設計の基本指針として、開発後の利用ドキュメントとして、有効に活かされなければならない。このようなパッケージ利用解説書に対する大前提を基にして下記の評価を行う。

• コンポーネントは要求を満たしているか？
  パッケージ仕様書の要求条件に書かれている以下の要求項目について、要求を満たしているかどうか判断する。
  • 機能面に対する要求
  • 性能面に対する要求
  • 信頼性に対する要求
  • ユーザインタフェースに対する要求
  • システム構造に対する要求
  • 期間・工数に対する要求
  • 拡張性に対する要求
• 要求に曖昧性がなかったか？
  パッケージ仕様書の要求条件により、システム開発時にADG開発者と問題を引き起こした部分について、なぜADGと意志疎通ができなかったのか？また、もっと詳細に書くべきことであったのかということについて議論する。
• コンポーネント要求モデルは妥当なものであったか？
  • 要求を理解する上で有効なモデルであったか？
  • どの程度、次フェーズの設計指針に役だったか？
  • 複雑なばかりで、設計フェーズに役立っていなかったのではないか？
  • 単純なばかりで、設計フェーズに役立つ情報が欠落してはいなかったか？
  • モデルに存在するオブジェクトは、コンポーネント要求に本質的に必要なオブジェクトであったか？
  • アーキテクチャモデルがコンポーネント要求モデルをベースとして作成されたか？

開発されたコンポーネントの評価

開発されたコンポーネントを以下の項目により評価する。

• パッケージ開発環境標準の妥当性
  コンポーネント分析フェーズで決められているパッケージ開発環境標準を使うことでどのようなメリットがあったか？また、デメリットがあったとすれば、それはどのような理由か？
• アーキテクチャモデルの妥当性
  システム共通設計で使われるアーキテクチャモデルを前提としたコンポーネント設計として充分機能する構造であっただろうか。何か他に優れたアーキテクチャがなかっただろうか？
• ソースの品質
  とりあえず動いてしまったと感ずる部分はないか？もしあれば潜在バグを疑うべきでありシステム設計者の責任においてコードインスペクションを行う。
• テストフェーズの評価
  時間をかけたテストがなされたか。バグを修正したことで新たにバグを作ってしまうようなディグレードをテストによって発見できたか。また、ディグレードが頻発してしまった場合は、どこに問題があったのか議論する。

開発プロセスの評価

コンポーネント開発の開発プロセスについて、以下の項目により評価する。

• スケジュール
  計画されたスケジュールと実際に実施されたスケジュールの食い違いはなかったか？もしあったとすれば、その原因はどこにあるか？
• ADGとの連携による開発
  コンポーネント開発を依頼された際に早期にコンポーネント開発計画を立てたか？また、それに応じてコンポーネントを計画通り開発したか？
• ワークショップの有効利用
  コンポーネント管理者は、決めるべき事を早期に決断するために再利用基盤ワークショップを有効に利用したか？
• 教育面
  ODG開発チームに必要とされるシステム問題領域の教育が事前になされたか？また、その教育は有効であったか？ADGの開発者に対してオブジェクト指向に関する教育を積極的に行うことができたか？
• 開発スケジュールの変更と調整
  開発内容の変更に伴う開発スケジュールの調整が円滑になされただろうか？もし、なされなかった場合は、その原因を追求する。

ドキュメントの品質

作成されたドキュメントに対して、下記の評価を行う。

評価項目	評価の方法
ドキュメントの必要性	コンポーネントドキュメントとして本当に必要だったのか？
使われなかったドキュメント	なぜ使われなかったか？どうすれば使えたか、または、不必要なものか？
書くべきドキュメント	なぜ書かなかったのか？その影響はどうだったか？
分厚いドキュメント	なぜ分厚くなったか？意味のある情報か？改善策は？
適切な情報	ドキュメント利用者にとって適切な内容か？たとえば、保守と利用を混同して書いていないか？
古くなった情報	新しくする必要があるか？するとすれば何時やるか？

２８．４ チェックリスト

コンポーネントテスト・評価フェーズの作業過程や完了時に、作業内容の評価を行う材料として以下のチェックリストを示す。

• 手順通りテストを行ったか？
  テストは、コンポーネントレベル、パッケージレベルの順に行われる。もし、コンポーネントレベルでバグが発覚して修正したのであれば、パッケージレベルのテストが必要となる。
• パッケージの評価が客観的かつ、有意義な形でなされたか？
  パッケージの評価で作成するパッケージ評価資料の内容が、客観的な立場で整理されているか？また、単なる個人攻撃ではなく、今後の開発に有効なるような目標を具体的な数値としてまとめられているか？

この記事のトップへ