テストの済んでいないシステムはこの家のよう！
■テストが重要であることは，大体開発に携わる人間ならだれでもわかっていることです。しかし，実際の失敗したプロジェクトの結果をみると，まず１００％プロジェクトのあらゆる時点でテストがおろそかになっています。 　答えは簡単で，テストしている余裕が無いということです。つまり，徹夜続きでプログラムを開発して納期になんとか間に合わせたいとなると，どうしても手を抜くのがテストになってしまいます。（だいたいわかっちゃいるけど・・・ということになってしまいます） 　プロジェクトの成果物であるシステムが期待通りの効果を出すためには，品質面をクリアしている必要があります。リッチＰＭ・ライトＰＭどちらの道筋を取る場合も，実は一番重要でクリアしなければならないものがテストです。
■なぜテストがうまくいかないか。

そもそもテストとはなんでしょう。 テストとは「できあがったシステムが正しく目的通りに動作するかどうかを検査すること」に他なりません。 　まずテストに合格しないものが，出荷されると言うことは，どの製品や産物を見てもシステム分野以外には考えられないことです。システム自体も全くテストがなされずに出荷されるというこは無いかもしれません。しかし結果として，某銀行のシステムを例に出すまでもなく，出荷後に問題が多発すると言うことは残念ながらかなりみられることです。これはコンピュータシステムの成果物自体が目に見えないということが大きな原因かもしれません。逆に目に見えないということは，とりもなおさずテストの難しさの主要な原因でもあります。 　たとえば，他の工業製品なら，色が塗ってなかったり，一部分がかけていたら，まずそのまま納品しようとする人はいないでしょう。 　システムの場合，故意かどうかはともかくとして，色が塗ってなかったり，一部分がかけているものが，一見して目に見えないため結果として平気で納品されてしまうことがあります。 その原因ですが，次のようなことが多いようです。 �@テスト工程が見積もり段階で不十分 　時間が無いためテストが不十分なまま出荷せざるを得ない。また見た目には分からない。もっとひどい場合は，開発スケジュールにテストの工程を入れていない。あるいは開発が遅れても，納期は変わらないので，テストを省くしかない。最後は納期とのかねあいで見切り発車してしまう。 �Aテスト仕様が不十分 　そもそもどのようになったら合格なのかが制作者側自体も押さえていない（これは要求仕様があいまいだということ） もっとひどい場合は，仕様を出す側も正解がどうなるのかを押さえていないまま発注する。 加えて，テスト仕様書とか検査仕様書などをまず作らない。 �Bテスターがいない 　開発者本人がテストを行うので，本人の思いこみや理解している度合いでテストの品質が変わる。（本人は良いと思っているが，実際の利用者は思いも寄らない使い方をする） 第三者がテストをして初めて合格したといえるものです。 �Cテスト環境の不備 　テストの環境が不備であるため，同じプログラムでもテストによって結果が異なる。（つまりプログラムが悪いのではなく，テストデータが悪い） などということが一般的です。 ■そもそもテストにはどのようなものがあるのか システムのテストには何種類かのものがあります。 開発段階の機能テスト �@単体テスト 　プログラムで実装したすべての機能が，正しく動作するか。 �A複合テスト 　クライアントとサーバー，ブラウザとＪＳＰなど組み合わせて機能するかどうかのテスト。 �Bビジネステスト 　「購買」とか「検収」など実際に使用するビジネスの単位で実際のビジネスルールや運用形態でテストする。 �Cベータテスト 　利用部門が準本番という形で使う。 開発段階のその他テスト �@意地悪テスト わざと通常の運用では考えられないようなことを行い，システムの強さをテストする。（ちゃんとエラーメッセージを返すかなど） �A負荷テスト 　ウエブベース開発では，特に重要です。すべて機能的にできあがってからレスポンスをあげることは非常に難しい。 �Bインストールテスト �Cマニュアルテスト 運用段階のテストとしては �@レグレッションテスト �A再現テスト 等があり，アメリカでは日本と違い，要求仕様書の整合性などデザインレビューなどと呼ばれているものもテストを行っているところがあります。（品質管理として合格しないものは，開発に入らないなど） このなかで，単体テストは開発者が行うテストです。これは通常ホワイトボックステストと呼ばれ，プログラムが実装したすべての機能について，正しく動作するかとか，デザイン規約に則っているかなどのテストを行います。このテストは，自動化される場合も多くあります。 単体テスト以降の複合テストからは，通常テスターが行います。大規模プロジェクトの場合は，専任のテストチームが行いますが，小規模な場合は１〜２名程度のテスト専任者と，あいている開発などの人間が兼務で行います。 　ライトＰＭをおこなう場合，単体テストまでは，ＰＧが，ブラックボックステストと，組合わせテスト・パフォーマンステストに関してはテストチームがおこなうのが普通です。ＸＰなどライトなシステム開発では，テストが開発の最初に来ます。つまり，アプリケーションのコーディングを行う際に，まずこの関数はこうなったら合格であるというテスト関数を先にコーディングすると言うことです。この方式をとると，単体テストは，コンパイル毎に毎回テストを行っているようになります。 かなり大規模なクライアントサーバーシステムの場合も，テストは同時並行が基本です。システムの開発規模が大きくなるほど，あるビジネス的に意味のある単位でテストを行う日を先に決め。それに併せて必要なプログラムを開発する事によって，テストと開発が同時並行で出来るようになります。これもいわばプロジェクトマネージャの腕です。 ■テストの基本テクニック (１) テスト目標設定 　まずテスト目標を設定することです。テスト目標とは，テストの「ゴール」です。こうなれば合格というテストの目標は，言い換えれば一番堅い仕様書に他なりません。要求側に明確な仕様書が無い場合は，最初にテスト仕様書を作るべきです。テスト計画段階で，合格目標を決めることは一番重要な部分です。ＸＰなどでは一番信用がおけるドキュメントはソースコードであるといいますが，システム全般にとっては，テスト仕様書が一番信用のおけるドキュメントだといえます。 �@ 要件定義書の分析とテスト計画書の作成 　上でも述べたとおりシステム要件定義書は，プロジェクトの全範囲をカバーするドキュメンテーションを構成するものとして作成されるべきものです。もしシステム要件定義書がなかったえり未完成であれば，テストだけでなくプロジェクトの他の部分でも，トラブルが発生することになります。要求仕様書を分析し，テスト目標（合格値）を設定することはテストに要求されるもっとも重要な作業であり，それらは要求仕様書をより具体的にしたものであるといえます。テスト計画とは，テスト計画設計，準備，テスト実行と，結果分析プロセスという各ステップを誰がいつどのようにどういう目的でおこなうかを明記したものです。プロジェクトの要求定義が出来次第「テスト計画作成」に着手できる �A テストスーパークラス整備 　テストは，開発に比べて生産性が稼げない分野です。テストの生産性を上げ，品質を上げるためには一般的にテストスーパークラスというものを作成します。 　個々の開発では必要性に応じて，このスーパークラスを派生させてテスト計画として再利用できるくらい，汎用的に作っておく必要があります。テストスーパークラスは，ある企業にとっての普遍的なビジネスルールに準拠したテストセットともいえます。 　テストツールを使用するとかJAVAなどで開発する場合，この手のスーパーセットをテストの汎用部品化して再利用することがテストの生産性をおこなう上では重要です。テストは，開発時だけのものではありません。システム変更や，スレッド型の開発をおこなう場合は，レグレッションテストと呼ばれる，新たに加えた変更に対して余計な尾鰭が出ないというテストがより重要になりますので，テスト計画の汎化作業がなされていることが重要です。当面のプロジェクトや企業にテストスーパークラスが無い場合，ＰＭは基本的なスーパーセットを作ることをスケジューリングしべきです。 �Bテストホームベースの作成 　テスト・特にスレッド型の開発では，同じテストを何度も繰り返す必要があります。前回のリリースで合格していたロジックが，次のリリースでエラーを起こすことは良くあります。そのため，レグレッションテストをおこなう必要がありますが，問題はテストデータです。同じテストをおこなっても都度違うテストをおこなっていたのでは，合否判定の品質上問題があります。また，テスト自体をツールを使って自動化する場合はなおのことです。その場合，スレッドのサイクルを考えある程度のホームベースを作成する必要があります。いつも同じデータで同じトランザクションでテストをおこなうことはレグレッションテストの基本です。 �Cテストにあわせたスケジュール線引き 　腕の良くないプロジェクトマネージャは，開発の分担を機能別とか，出来るところからとか，仕様がまとまっている部分からなどという開発スケジュールを引きます。だいたいこの手のスケジュールで行われるプロジェクトは失敗します。もうひとつは，一度に大量にプログラマに指示を出し，２ヶ月後に納品！などという仕事の出し方。これもだめです。こういう仕事の出し方では，プログラマは自分の興味のある部分から開発し出します。どちらの場合も，完全にプログラムがすべて完成するまで，テストにかかれません。当然問題が発生すれば，すべてリリース出来なくなってしまいます。 　これに対してスケジュールをテスト中心にするというのが基本です。まず，ビジネスとして意味のある単位（これも優先度によります）のテスト日程を最初に決め，これを逆算して，テスト実行するための必要プログラムを担当者に指示をだすというのが基本です。 ■まとめ 　テスト計画というものは，プロジェクトを滞り無く進める上でもっともキーとなる工程です。しかも，リッチＰＭ，ライトＰＭ共に省略することができない工程です。テストが不十分か，部分的にしかおこなわれていない場合本番切り替え後に未発見の，とても多くのクリティカルなエラーが残るケースが多いことがよくあります。これは，単体テストばかりおこなっていて，全体的なテストをおこなっていないケースがほとんどです。 スレッド型開発をおこなう場合，リリース後に致命的なエラーが発生すると，効果が出ないばかりか，プロジェクトの存続自体に関わる重大な結果をもたらす可能性があります。 一般的にＰＧ個人が単体テストまでをＸＰなどでどのくらい重ねてもそれが，組織的でなくＰＭ経由で経営サイドに報告もされないテスト結果は，結局，テストしていないことと同じです。 　 一般的なテストの工程 �@ テストチーム編成 �A リスク分析 �B テスト目標の設定 �C テスト計画作成 �D テストケースの作成 �E 単体と組み合わせテストの実施 �F システムテストの実施 �G 分析とテスト結果のレポート �H レグレッションテストの実行 �I 分析とレグレッションテスト結果のレポート作成