*begin *back *foward *end *contents

開発フェーズ編

第２８章　パッケージテスト・評価



２８．１　目的

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



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

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

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



２８．３　作業項目の解説


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

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

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

　クラスレベルのテストがある程度完了すると、次はパッケージレベルのテストを行うことになる。ここでは、パッケージのテストを行うために、以下の方法が取られることになるだろう。
　コンポーネントテストのためには、テスト管理者によって作成されるテスト項目表をクリアすることが目標とされるが、実際にはテスト項目票に網羅できていないテスト内容があることも多い。よって、テスト実行者はテスト項目票をクリアすることを最低条件としなければならない。実際システムを使ってみて気が付いたケースをテスト項目票に新たに加えながらテストを実施していくことが必要となる。
　それぞれのテストは、以下のような責任範囲で実施される。なお、テスト管理者はシステム管理者が行うこともあれば、製品開発などではテストチームを組織してその管理者に行わせることもあるだろう。

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

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


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




* パッケージの評価

　パッケージの評価は、パッケージテストが完了に近づいた頃に行う作業として位置づけられる。パッケージの評価とは、ODGの提供するパッケージ（コンポーネント群やフレームワーク)開発全般を様々な評価項目を使って、コンポーネント分析者が中心となりODG全体で議論を行うものである。そして、チームとして改善すべき欠点や伸ばすべき長所をチーム全体で把握するために評価資料を作成する。
　この評価作業には「自分たちの開発プロセス全般を、客観的な視点で考察することができるか？」ということが重要となる。この評価がチーム全体として上手になれば、開発の度にチームコンピューテイング能力が強化されることになるだろう。




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



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



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



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



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



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





２８．４　チェックリスト

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

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



*begin *back *foward *end *contents