テストといってもいろいろある
サッカーからの教訓で，テストは開発メンバー全員の仕事と書きましたが，それぞれのメンバーが行わなければならないテストは一言ではくくることができないくらい，いろいろな種類があります。
では実際にテストはどのようなことをどんな順序で行っていくのでしょうか。その疑問に答えてくれるものの一つが，開発工程とテストとの関係を表す「Vモデル」です（図2[拡大表示]）。Vモデルでは，開発工程に対応した形でテストの種類を決めています。
テストに工程を設けるのは，テスト対象への視点を整理することでテストが混乱しないようにするためです。例えば，メソッドのパラメータの組み合わせパターンのテストと，システムとしての使い勝手を評価するためのテストでは，テスト担当も違えば，テスト環境やテスト実施方法も違います。また，工程を分けてより早くテストを始めることで，問題の切り分けを楽にするという意味もあります。
では，図2の下の部分から各工程のテストを順番に見ていきましょう。
静的テスト（コード・レビュー）
まず，最初に行うのが「静的テスト（コード・レビュー）」です。リスト1[拡大表示]を見てください。あるプログラムに書かれたJavaのコードの一部です。注目は2行目。doubleのような浮動小数点数を扱った場合，正確に答えがズバリ出るという保証はありませんよね。したがって，5行目のif文で，aと1が等しいかどうかを判定するにはやや無理があります。思った通りには動かない場合があるからです。
このように，コンパイルは無事通ったとしてもバグになる（もしくはバグになりやすい）コードになっているのをチェックするのが静的テストです。たくさんのif文が入れ子構造になっているかどうかなどをチェックするメトリックス分析などの作業も含まれます。
静的テストは，自分自身あるいは開発者同士でコードをレビューしあって行います。静的解析用のテスト・ツールを使い，コンパイルするときに一緒に確認してしまうのもよいでしょう。
単体テスト
次に行う「単体テスト」では，モジュール内のコードが正しいロジックかどうかをチェックします。ソースコードに対するテストの網羅度合いを測定したり，モジュール・レベルの機能仕様や予期しない例外について確認したりします。
通常，単体テストはコードを書いた本人が行います。コーディングした直後であれば，書いた内容を理解した状態でテストするので，バグを見つけた後のデバッグも時間がかからないからです。最近では，xUnit（Java言語ならJUnitが有名ですね）のようなテスティング・フレームワークを使うことが多くなってきました。
結合テスト
「結合テスト」では，大きく分けて2種類のテストを実施します。
一つ目は，関数の呼び出しや他のクラスへのメッセージングなど，モジュール間のつながりが正しいかどうかをチェックするテストです。もう一つは，GUIまで結合した状態で，ソフトウエアに実装された機能が仕様書と合っているかどうかをチェックするテストです。この二つは，ソフトウエアの規模が小さければ同一工程として行いますが，規模が大きい場合は，前者を「コンポーネント・テスト」とフェーズ分けする場合もあります。
普通，結合テストは，結合する対象の関数が全部自分で書いたものならば自分自身で行えるでしょう。しかし，チーム内の別の人が書いたモジュールとの結合であれば，事前にメンバー間でテストする部分を分担しておきます。分担をし忘れると，誰もテストしていなかったなんてことになるからです。ユーザーがソフトウエアを使うまで欠陥が見つからない原因は，このような分担漏れにある場合が非常に多いのです。なお，結合テストの段階からテスト・チームがテストを行う場合もあります。
システム・テスト
「システム・テスト」は，開発の最終段階で，ユーザーの元に届くものと同じ状態でソフトウエアをテストして，製品としての品質を評価するテストです。システム・テストには様々な種類がありますが，基本はユーザーがそのソフトウエアを使う状況/手順に沿って動作させることにあります。
例えば業務システムの場合，会社内で複数の人が行う業務の流れをシミュレートするようなシナリオを，本番と同様のデータ量，同様のトランザクション，同様の環境でテストします。
また，セキュリティ面のテスト，障害が発生した後の対応についてのテスト，ネットワーク/周辺機器/制御対象のハードウエアなど，本番運用で使う機器と接続してチェックするテストも行います。システム・テストは，テスト専門チームが行う場合が多く，またそのほうが良いとされています。
受入テスト（ユーザー受入テスト）
本番運用直前に行う最終的なテストが「受入テスト」です。受託開発では「ユーザー検収」と呼ぶこともあります。受入テストでは，本番環境で，実際に使う人自身が本番稼働して良いかどうかを判断します。
少なくともこの段階までに，もはやバグが出ないようシステム・テストまでのテストをしっかり行っておく必要があります。なぜなら，簡単なバグでもバグ修正が新しいバグを生み出す恐れがあり，本番運用時期に影響が出るからです。バグが出たときは，慎重に判断し修正するのは致命的なバグに限定する必要があります。
以上，テストの工程とその中で行うテストを説明しましたが，ソフトウエア・テストを実施していく流れが見えてきたでしょうか。以降は，ソフトウエア・テストを行うための，より具体的な技術について説明していきましょう。
ソフトウエア・テストに必要な五つの技術/知識
図3[拡大表示]は，ソフトウエア・テストを行うために必要な五つの知識や技術を分類したものです。
まず最初に必要なのは，なにはともあれテスト固有の技術ですね。固有の技術以外にも開発全般の技術を広く浅く（適度に深く）身に付けておく必要があります。詳細は後述します。続いて必要なのが業務知識です。これは，要件や機能をテストするために必要です。設計図の知識というのは，UMLやER図などの知識です。これらの図面を読めないとソフトウエアがどのように設計されているかを理解できず，テスト設計の効率が落ちてしまいます。
また，OS，ハードウエア，ネットワークの基本知識も必要です。最適なテスト環境を準備するためです。一つのテスト環境で何人ものテスト担当がテストを行う場合，テスト環境のミスは人数分の工数を無駄にすることになります。
プログラミングの知識は，単体テストのレベルのテストを設計/実施するためには当然必要です。単体テスト以降のテストでも，テスト用プログラムやスクリプトを書くためにプログラミングの知識は必要です。特に，結合テストでテスト設計を効果的に行い，バグを修正したあとの回帰テスト＊6のために影響範囲を分析するためにも，ある程度のプログラミング知識が必要になります。
 |
| 湯本 剛（ゆもと つよし） 株式会社豆蔵 ES事業部 |
では，前述したテスト固有の技術としては，どんなものが挙げられるでしょう。大きく分類すると，
(1)テスト設計技術
(2)テストの実施を効率化する技術
(3)テスト・ベースをレビューする技術
(4)バグ報告の技術
の四つに分けられます。以降は，これらを細かく解説していきます。
（次回に続く）
