今回は品質管理における地道なテストの重要性を取り上げる。ソフトウエアは極めて多くの機能を持つだけに、すべてのケースをテストすることは実質的に不可能だが、あきらめすぎては稼働後に大きな支障を来すことになる。
 |
テストでは、システムが（1）設計者の考えどおりにできているかどうかを確認する「内側から見るテスト」と、（2）ユーザーの要求を満たしているかどうかを確認する「外側から見るテスト」とが必要である。いわば前者がホワイトボックス・テスト、後者はブラックボックス・テストといえよう。
内側から見るテストは、設計者中心で行うべきだが、外側から見るテストでは、テスト部隊や検査部隊、さらには顧客にも入ってもらうことが大事である。外から見ることで、設計者の勘違いや視野の不足、使い勝手の悪さなどの早期発見につながるからだ。
設計者のテストは、あくまで自分が設計しようと思った通りにできていることをテストするものであり、それが顧客の要求通りにできているかどうかは保証できない。だからこそ、ブラックボックス・テストには顧客にもできる限り参加してもらうことが望ましい。検収段階になって初めて顧客に使ってもらうのでは遅すぎるのである。
 |
計画したチェック項目はすべて消化したものの、安定品質に達したとは判断できないとき、追加テストが必要になる。しかし、どういうテストを追加すればよいかは大きな課題だ。それまでに何をテストしてきたのかが怪しげで、追加テストが追加にならず、単に過去のテストをやり直しているにすぎないというような事例もよくある。
バグを分析し、これまでのテストでバグの多かった部位を狙ってテストするのは当然としても、やはり、テスト計画をきちんと立てるとともに、テストの来歴管理、特にテストの網羅性をよくフォローしておかなければ合理的なテストはできない。全命令をカバーしたかを見る「C0メジャー」や、全分岐をカバーしたかを見る「 C1メジャー」についてはしっかり見ておきたい。
 |
テストが完了すると、「完了した」「終了した」という報告はなされるが、完了の定義がきちんとなされていない場合が意外と多い。いくらテストをしても“完全”“完ぺき”の立証は無理なだけに、どんなテストを計画し、どの観点から何件のテスト項目を設定し、どんな方法でテストしたかなどを明確にして、テスト完了を宣言すべきだ。
さらに、後から何をもって合格と判断したのかをトレースできるようにしておきたい。予期しない障害が発生したとき、そうした情報が役に立つ。例えば、テスト終了後に予想以上の障害が発生し再見直しを求められたとき、前と同じテストを実施しても見直し効果はない。従来とは違う再テスト項目を設定しなければ意味がないからだ。
 |
座席予約システムでキップが出てくる、銀行システムでお金が引き出せる、生産管理システムで発注伝票が出てくる、といった主要な機能は、誰もが着目していることもあり、案外早く動くことが多いが、それでも全体システムの一部の機能が動いたにすぎないとみるべきである。メインの機能よりサブ機能のほうが多いし、まして、エラー処理や例外処理になると、さらに多くを確認しないと動いたことにならないからだ。“一応”は早く動くが、全部が動くことは大変なことなのである。
主要機能が動いたとは、プロトタイプ・システムが動いた程度であり、単にuシステムの実現が可能であることを実証できた状態vと考えるべきだ。今後の連続稼働に耐えられるか、エラー発生時に問題なく復旧するか、保守作業で問題はないかなどなど、システムが稼働したずっと後のことまで確認しなければ、完成したとは言えない。
「一応動きました」という言い方ほどあいまいな表現はないと考え、もっと実態の把握に努めなければならない。
