開発フェーズ編 -
第２５章　システムテスト・評価

２５．１　目的

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

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

システムテスト・評価で作成するドキュメントの一覧を示す。

ドキュメント名	解説	様式番号
バグシート	バグが発見されたときに記述される	4-01

２５．３　作業項目の解説

システムのテスト

システムのテストは、クラスレベル、アプリケーションレベル、そしてシステムレベルというように、開発フェーズをさかのぼるような順番で行われることになる。

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

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

バグが解決した後は、バグシートの原因分析情報の統計を取ることにより、プロジェクトチームの問題点や改善点を把握することも使われることになる。

以下にそれぞれのテストについて簡単に解説する。

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

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

クラスレベルテスト	システム実装者
アプリケーションレベルテスト	システム設計者
システムレベルテスト	システム分析者（テスト管理者）とテスト要員

クラスレベルテスト

1. 機能テスト：クラスのサービス単位でのテスト
2. 資源テスト：使用した動作環境の資源が正しく後始末されているかのテスト

アプリケーションレベルテスト

1. 操作テスト：アプリケーションの提供する操作単位のテスト
2. 障害テスト：システム共通設計フェーズで定めた信頼レベルを保証しているかのテスト
3. 資源テスト：使用した動作環境の資源の後始末を正しく行っているかのテスト

システムレベルテスト

1. 操作テスト：システムの提供する操作単位のテスト
2. 要求テスト：要求仕様で記述された内容が網羅されているかのテスト
3. 連動テスト：システムとアプリケーション間の連動テスト
4. 障害テスト：システム共通設計フェーズで定めた信頼レベルをシステムとして保証しているかのテスト
5. 資源テスト：使用した動作環境の資源の後始末のテスト
6. 過負荷テスト：システムの仕様として定めている、様々な制限値を越えた時、または越えそうな時に、仕様通りの動作がなされるか。予測していない動作をしないかどうかシステムに負荷を与えて行うテスト。
7. フィールドテスト：利用者の実環境を使っての総合テスト

システムの評価

システムの評価は、システムテストが完了に近づいた頃に行う作業として位置づけられる。システムの評価とは、システム開発全般を様々な評価項目を使って、システム分析者が中心となりADG全体で議論を行うものである。そして、チームとして改善すべき欠点や伸ばすべき長所をチーム全体で把握するために評価資料を作成する。

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

要求仕様の評価

システム開発では、要求仕様を基にソフトウェアを開発する。もし、要求仕様の品質が悪いとするならば、初めから作ろうとするソフトウェアがすべて誤っていることになる。本来、このような要求仕様の誤りについては問題領域分析フェーズにて解決しておくべきことである。しかしながらシステム開発の過程で、政治的な側面での仕様変更、期間・工数変更などによって、あるべき要求仕様をねじ曲げられて開発が進められることもあるだろう。このようなケースも考慮に入れながら、問題領域分析フェーズで作成した要求仕様を以下の観点で評価しなければならない。

• 本当にユーザ要求を組み入れた要求仕様と言えるものであったか？ もし、そうでないとすれば、ユーザ要求が組み入れにくかった原因はどこにあったのだろうか？
• 開発期間、開発工数を考慮した要求であったか？ 結果として、要求に基づいて作成されたスケジュールは適切であったか？
• ユーザ満足度はどの程度か。これは、ユーザに利用アンケートを取り、その集計結果によって判断しなければならないため評価フェーズの期間を越えて長期に調査を行うことが必要とされる。
• 開発環境の変化に応じた柔軟な要求の変更がなされたか？システム開発が長期にわたる場合、ユーザ要求が変化することもありうる。そのような時、要求の変更に柔軟に応じながら、スケジュールの変更を正しく行えるようユーザとの調整を正しくおこなったか？

要求仕様に基づく評価

システム開発の中で作成される要求仕様書は、開発するソフトウェアにおいて「何を作るべきか」という指標として開発中・開発後に使われるものでなければならない。つまり、要求仕様書は、開発中や開発後の保守ドキュメントとしても生きたドキュメントとして活かされなければならない。もしも、開発が進むにつれ要求仕様書が死んだドキュメントとして戸棚の奥に飾れれていたのならば、開発されたソフトウェアはユーザの要求を満たすものかという保証はない。

このような要求仕様書に対する大前提を基にして下記の評価を行う。

• 開発システムは要求仕様を満たしているか？
  要求仕様に書かれている以下の要求項目について、開発システムが要求を満たしているかどうか判断する。もし、要求を満たしていない場合は、なぜ切り落としたのか？本質的に必要のない要求だったのか？ということについて議論する。また、そのように切り落とされた要求が、今後、ユーザから不満となることがあるかを議論する。
  • 機能面に対する要求
  • 性能面に対する要求
  • 信頼性に対する要求
  • ユーザインタフェースに対する要求
  • システム構造に対する要求
  • 期間・工数に対する要求
  • 拡張性に対する要求
• 要求に曖昧性がなかったか？
  要求仕様に書かれた曖昧な定義により、システム開発時に開発依頼側と問題を引き起こした部分について、なぜ開発依頼側と意志疎通ができなかったのか。また、もっと詳細に書くべきことであったのかを論する。
• 要求仕様決定の遅れが開発の遅れにつながらなかったか？
  要求仕様を性格に作ろうという思いが、結果的にシステム共通フェーズの遅れにつながり、結果として開発が遅れてしまった場合、その遅れは妥当であったか判断するために議論する。もしかすると、問題となった要求項目自体を曖昧にしていてもシステム共通フェーズやアプリケーション設計・実装フェーズと並行に進めていけるものであったのかもしれない。
• 要求モデルは妥当なものであったか？
  • 要求を理解する上で有効なモデルであったか？
  • どの程度、次フェーズの設計指針に役だったか？
  • 複雑なばかりで、設計フェーズに役立っていなかったのではないか？
  • 単純すぎて、設計フェーズに役立つ情報が欠落してはいなかったか？何か追加しておくべきものがあったか？
  • モデルに存在するオブジェクトは、ユーザ要求に本質的に必要なオブジェクトであったか？
  • アーキテクチャモデルが要求モデルをベースに作成されたものであったか？
• 用語辞書は利用されたか？
  問題領域の理解に手間がかかる場合、用語辞書が作成される。用語辞書は、要求仕様の中に出てくる重要な用語の意味が定義されるはずである。ここでは、作成された用語辞書が以降のフェーズでどの程度利用され、有効に活用されたかを判断する。また、用語辞書を作成しなかったプロジェクトでは、本当に作成しなくてよかったのかを議論する。

開発したソフトウェアの評価

開発したソフトウェアを以下の項目により評価する。

• システム共通設計フェーズにおける共通化項目の妥当性
  システム共通設計フェーズで決めた共通ルールがプロジェクトに適切に効果をもたらしたか？または、有害な共通化ではなかったか？
• アーキテクチャモデルの妥当性
  システム共通設計で定めたアーキテクチャモデルがシステム設計として充分機能する構造であっただろうか。何か他に優れたアーキテクチャがなかっただろうか？
• コンポーネント化に対する評価
  コンポーネント化することで再利用コードを増やしテストが楽になったであろう部分を、コンポーネント化していなかったソースの箇所はなかったか？もしあれば、今のうちに改善しておいた方が保守が楽になるのではないかといった議論。
• ソースの品質
  とりあえず動いてしまったと感ずる部分はないか？もしあれば潜在バグを疑うべきでありシステム設計者の責任においてコードインスペクションを行う。
• テストフェーズの評価
  時間をかけたテストがなされたか。バグを修正したことで新たにバグを作ってしまうようなディグレードをテストによって発見できたか。また、ディグレードが頻発してしまった場合は、どこに問題があったのか議論する。

開発プロセスの評価

システム開発の開発プロセスについて、以下の項目により評価する。

• スケジュール
  計画されたスケジュールと実際に実施されたスケジュールの食い違いはなかったか？もしあったとすれば、その原因はどこにあるか？
• ODGとの連携による開発
  コンポーネント開発すべき内容を発見した際に要求を早期にODGに伝えたか？また、それに応じて作られたコンポーネントを使う努力がなされていたか？
• ワークショップの有効利用
  システム管理者は、決めるべき事を早期に決断するためにワークショップを有効に利用したか？
• 教育面
  ADG開発チームに必要とされる教育が事前になされたか？また、その教育は有効であったか？
• 開発スケジュールの変更と調整
  開発内容の変更に伴う開発スケジュールの調整が円滑になされただろうか？もし、なされなかった場合は、その原因を追求する。

ドキュメントの品質

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

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

２５．４ チェックリスト

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

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

この記事のトップへ