効率よくテストを実施しようと考えると、テスト自動化の導入という方法があります。
プログラム作成直後に自動テストを起動してチェックする、または、リグレッションテスト(回帰テスト)といって既に開発済の機能が以前のまま問題なく動作するかを確認する、といった時にテスト自動化ツールが使用されています。

しかし、現状ではまだツールという位置づけであり、どんなテスト作業でも自動化ができるというわけではありません。

テスト自動化手法

テスト自動化といった場合、プログラム作成されるタイミングで実行されるホワイトボックス系の自動テストと、機能として実装される単位で実行されるブラックボックス系のテストと、大きく２種類あります。

ホワイトボックス系テスト

カバレッジ計測ツール

プログラムソースに記述されている命令文や条件分岐を自動でチェックするツールが存在しています。
カバレッジとは網羅度という意味ですが、ホワイトボックステストでは、プログラムに記述されている命令文、条件判定文をテストしますが、テストを実行した割合をカバレッジとして表現します。全てのテストケースを実行した場合は、カバレッジ100％となります。

Ｃ０	ステートメントカバレッジ（命令網羅）	命令文の実行
Ｃ１	ブランチカバレッジ（分岐網羅）	条件分岐の真偽を実行
Ｃ２	コンディションカバレッジ（条件網羅）	条件を組合せて実行

ホワイトボックステストとしては、全ての命令文と、全ての条件分岐の真偽はテストすべきものですので、Ｃ０とＣ１はカバレッジ100％をテスト終了条件とします。

条件の組合せは、バリエーションが膨大となる可能性があるため、カバレッジ率はプロジェクトごとに決定してください。
例えば、マスタメンテナンスやデータ入力画面では、セレクト項目が10～20程度は存在していると思います。
そのプログラムに選択値が3つある条件分岐が10か所あると仮定すると、
3×3×3×3×3×3×3×3×3×3＝59049
にもなってしまいます。

ところで、カバレッジ計測ツールは実装されたロジックに対するテストになりますので、仕様書には記載があるのに実装し忘れたロジックがある場合は、テスト対象外になります。
また、実装を間違えていた場合、例えば「20未満」とするべきところ「20以下」と実装していたとしても、そのようなミスは検出することはできません。

テストファースト(テスト駆動開発)

プログラムの作り方として、先に仕様書からテストすべき部分を抽出し、そのテストをクリアするようにロジックを組み立てていく、というスタイルです。

どのようなテストができるかを考えることは、仕様書のレビューにもなるため、システム品質を底上げすることにもつながります。
仕様書からテストする必要がある項目を全て挙げて、その中から重要度が高く実装できるテスト項目を選出し、テストロジックを作成するところから始めます。

最初は現在の実装ではテストが失敗するように記述し、それをテストが成功するようになるよう、実装を見直しながらブラッシュアップしていく、という形を取ります。

テストを失敗する段階	レッド
テストをパスする段階	グリーン
ロジックをブラッシュアップする段階	リファクタリング

テスト駆動開発ではテスト項目をロジックに追加するたびに「レッド → グリーン → リファクタリング」を繰り返して、最終的にプログラムとして完成させます。

テスト項目を一つずつクリアしないとプログラム作成を先に進めることができない手法であるため、プログラムの品質は自ずと高まります。
しかし、テスト項目を考えながらのプログラミングは、やはり時間がかかるものですし、中にはプログラム単体ではテストロジックを組み立てられないテスト項目(データベースの更新やインターフェースの確認など)もあります。Ｃ２(条件網羅)もテスト項目を組合せて結果を求めるものです。

したがって、テストファーストでプログラムを作成したからといって、他のテストを実施しなくても良い、というわけではありません。
また、プログラムの仕様変更が発生した場合、テストロジックもメンテナンスしなければなりませんので、工数見積にも配慮が必要です。

ブラックボックス系テスト

現行のテスト自動化ツール

現在、提供されているテスト自動化ツールは「プログラム実行時のオペレーション(項目入力と振舞い)と実行結果を、以前の動作と改修後の動作とを照合する」というものです。
つまり、既に作成されており正常動作するプログラムに対して仕様変更が発生した時に使われるものです。

テスト自動化ツールの実行では、次を準備します。

スクリプトファイル	プログラムのオペレーションを記録
スナップショット	プログラムの操作(変化する)単位に保存
処理結果	プログラム動作後の結果を照合する情報

自動テストは、主にリグレッションテストという「プログラム改修しても改修前と同じ処理結果になっているかの確認」を目的とします。
プログラム改修作業で、改修した部分の実装に注力するため、改修の影響範囲外についての確認作業を省力化させようというものです。

ゼロから作成したプログラムでは、比較元となるプログラムが存在しないので、残念ながらテスト自動化ツールは使用できません。
正しい処理結果は仕様書から導き出せるので、準備資料であるスクリプトファイル・スナップショットを用意できれば、テスト自動化ツールを利用できないわけではありませんが、準備資料の作成が大変な作業負荷となることから、現実的な方法とはいえません。
また、スクリプトファイルやスナップショットは、プログラム改修作業の都度、メンテナンスを継続しておく必要もあります。
大至急でのプログラム改修や、ほんの些細なプログラム改修であっても、プログラムロジックの改修作業だけでなく、テスト自動化ツールで必要な情報の整備も行なっておかないと、その後のプログラム改修作業で使用することができなくなってしまいます。

テスト自動化のまとめ

テストを自動化＝機械化することは、テスト作業での操作ミス等を防止できますし、マシンが自動で実行するものであるため、人間の作業負荷を軽減し、より創造的な作業のための時間を創出することができるというメリットがあります。 しかし現在のところ、テスト自動化は一部分に限って利用することができるという状況です。

カバレッジ計測ツールとテストファーストは、ともにプログラムの作成段階での正確性を担保するものという位置づけで、テストとして不足する部分があるため、やはりプログラム単体テストは実施すべきものといえます。

テスト自動化ツールは、プログラム改修時のリグレッションテストとしては有効ですが、プログラムの新規作成時やプログラム改修で新たに追加された機能のテストとしては未だ利用することはできません。
また、プログラムの改修作業が発生するたび、プログラムのロジックを改修するだけでなく、テスト部分も改修する必要があります。

正確性が向上して時間の有効活用が期待できるプラス面と、自動化だけではカバーできないテスト作業があることと自動化を維持していくために作業負荷が増加するというマイナス面があることを認識した上で、テストの自動化を推進していくといいのではないでしょうか。

関連記事

テストエンジニア
テスト計画
テスト作業のモチベーション
品質見える化
統計検定（３級一週間合格記）
統計教育連携ネットワーク(JINSE)
統計検定：データサイエンス