こんにちは。『忘れないで、ギター侍』と申します。
久しぶりに、システム開発関連のことを書こうかと思います。
今回はタイトルにもある「テスト」について書きますが、どちらかというとテストがおざなりだと何が待ち受けているのかという視点をメインに書いてみようと思います。これからIT業界に飛び込もうとする人はここが少しでもわかっていればきっと話がしやすくなります。また、テストの意義がイマイチわからない方はぜひ読んでみていただければと思います。
■テストの種類
本稿では、広く認知されているウォーターフォール型開発モデルをベースとしています。そのうえで、システム開発においてテストは一般的に以下に大別されますので、簡単に概要を記載します。
・単体テスト
…プログラム1本や1画面など、文字通り「単体（1モジュールや1ユニットといった言い方があります）」に対してのテストになります。本稿ではここにフォーカスを当てて後ほどもう少し詳しく書きますが、この単体テストでどれだけのバグを解消できるかが重要になってきます。
・結合テスト
…プログラムを2本以上連結したり、2画面以上を行き来したり、つまり複数モジュールを連結させて行うのがこの結合テストになります。プログラムで設定した値の受け渡しがうまくいっているかなど、スムーズに連結できているのか確認します。
・システムテスト
…システム全体を稼働させ、どう動いてほしいかという要件に対して処理が止まることなく流れるかを見るテストになります。
・受け入れテスト（運用テスト）
…開発環境下で正しく動いていても、いざユーザーの手元で動かしてみるとうまく動かないなんてことにならないように、実際の運用と同じ条件下で正しく動くかテストをします。
■何のためにテストをするの？
できるだけエラーを検知し、バグを取り除き、正常稼働する可能性を少しでも高めるためにテストをします。
システムというからには、止まることなく動いてくれないと困りますが、実際のところ想定外の事象というのは限りなくゼロに近づけることはできても、絶対ゼロというのは難しく、技術に長けたスペシャリストが英知を結集して作っても起こるときは起こってしまうものなのです。例えば空港で搭乗システムが止まったなんてニュースなんかも以前ありましたよね。
言い換えれば、エラーをハンドリングする（エラーを検知して、そのエラーを制御可能な状態に持っていく）ための工程とも言えます。
■テスト観点が甘いとどうなるの？
エラー発生のリスクが高くなってしまうため、ちょっとしたことでシステムが止まってしまう可能性をはらんだまま動くことになります。そして、ひとたび「システム障害」が起きると、たちまち開発現場が慌ただしくなり、業務が爆発的に増加します。
ユーザーとの契約にもよりますが、システム障害によって損害が発生するケースも当然あるわけで、そうなると賠償問題にも発展することもあります。
ここまで大きなものはそれまでのテスト工程をきちんとこなしていればなかなか起こりにくい話ではあるのですが、ここまで発展しなくとも開発チームにはそれなりの責任やタスクが降りかかります。
細かい説明は割愛しますが、
・直接原因分析（システム上で何が起きたのかを究明）
・根本原因分析（開発手法やテスト内容に至るまで、そもそも何が起因して起きた障害なのかを徹底的に探り、結論づける作業）
・対策立案（どうすれば今後起きないようになるのかを検討）
・水平調査（同じ問題をはらんでいるプログラムなどがないか網羅的に調査）
・再発防止策の徹底および実施管理（対策をきちんと講じているか、二度と起きないように恒常的に実施できているかの管理）
といった業務が発生します。ユーザーからすると業務が止まると困るので迅速な問題解決を要求するのは当然ですが、かなり迅速な対応が求められます。
■単体テストの手法と観点
『システム開発 単体テスト』といったワードで調べればいたるところに情報があるので、ここでは簡単に記載します。
【手法】
・ホワイトボックステスト
…一つ一つのロジックをきちんと経由できているかや、正しく条件判定できているかなどをみる、いわばその内部構造を一つ一つ見ていくテストです。網羅的な実施が求められるため、のちに記載する「網羅基準」があります。
・ブラックボックステスト
…ホワイトボックステストと反対に、内部構造を気にせず、プログラムを介した際に求める結果が出るかを確認します。（例えば、Ａというパラメータを与えた際に結果がＢであることが正しい場合、その通りに動作するかを確認します）
【ホワイトボックステストの網羅基準】
・命令網羅
・分岐網羅
・条件網羅
※それぞれの詳細説明は割愛しますが、どれも重要な考え方であり、できる限り漏れなくこれらの基準を満たすことが質の高いテストに繋がります。
■単体テストの重要性
単体テストは実施すべきと判断されるものはすべて実施することが大切です。結合テスト以降で発生するバグが、実は単体テストの考慮不足なんてことはよくある話です。
各テストフェーズは単体テスト⇒結合テスト⇒システムテスト⇒受け入れ(運用)テストの順に高度になっていきます。それだけ動くプログラムや画面数が増え、バグの調査の難易度も上がる傾向にあります。そして、範囲が大きくなれば比例して調査に時間がかかります。
実際の開発現場では一つのシステムを何チームにも分かれて作成することがほとんどです。他チームが作成したプログラムと結合するときに、単体テストしていれば見つかるはずのバグが発生してしまうと、その時点で自チーム起因なのか他チーム起因なのか、まずはその特定から始めないといけません。
単体テストは「ほかのプログラムと結合する前＝自分だけの段階」でバグを見つけることができる唯一のフェーズです。原因の特定が容易なため、本来はここでどんどんバグを見つけて解消し、品質を高めることが後々の工程で活きてくるのです。
様々なケースを想定することから、テストデータやそのためのコードが必要だったりもするのでどうしても所要時間がそれなりに必要にはなるのですが、単体テストをおざなりにしてしまうとかえって後から時間を割くことになってしまうケースがよくあるので、意識することが大切です。
■最後に
どうしても作ることばかりに目が行きがちなシステム開発ですが、安定したシステム稼働には質の高いテストの実施が不可欠です。めんどくさいと思いがちなフェーズで、退屈になる気持ちも痛いほどわかりますが、目先の手間を省いてしまうと後から余計めんどくさいことになりかねないので、その先に何が待ち構えているのかを考えてそのリスクを回避した仕事ができるといいなと思います。
ありがとうございました。
