単体テスト
システムの開発中に、システム品質の確認を目的として、さまざまな段階でテスト(検証)が実施されます。「単体テスト」はテスト段階の最初に位置付けられます。
例えば、パッケージ導入の場合は「不足機能を補うために開発されるアドオンプログラムがプログラム設計書通りに機能するか」を確認します。
プログラムの不備により想定した実行結果が得られない(バグがある)場合、プログラムの修正を行うことでバグを解消します。最終的に、バグを検出する頻度など、事前に定めた完了基準を満たすことでテストが完了します。
単体テストを行うためには、プログラム設計書が正しく、具体的に書かれていることが前提となります。
なぜなら、プログラム設計書をもとに、必要と思われるチェック項目を網羅した単体テスト仕様書が作成され、テスト用のデータが準備されるからです。そのためにも、プログラム設計書のレビューは、単体テスト実施には不可欠です。
なお、単体テスト仕様書の作成と単体テストの実施はシステム開発会社の責任のもとで行われることが一般的です。
特に、システム開発を発注する場合、発注者側が単体テストに参加することはなく、システム開発会社から単体テスト結果報告書を受け取る形式が一般的です。
具体的なテスト方法は次に示す要素などによって変わります。
- システム開発会社の考え方
- システム開発手法(ウォーターフォール型、アジャイル型など)
- システムの種類(データベースを核としたシステム、Webシステムなど)
- プログラムの機能(バッチ処理プログラム、画面処理プログラムなど)
どんなテスト方法を選択するかについても、単体テストの実施と同様に、システム開発会社が主体となって行われ、発注者側が関与することはほとんどありません。
ただし、「単体テストが完了したプログラムであってもバグが無いとは言い切れない」ことを留意しなければなりません。システム開発会社がどれだけ入念なテストを行ったとしても、バグが残り、本番稼働開始後に不具合として現れることもあります。このような潜在的なバグに対応するため、契約不適合責任の明確化や、保守契約の締結も検討する必要があります。
なお、単体テストに合格したプログラム同士、パッケージシステムや他システムのプログラムとを組み合わせておこなう「結合テスト」が、後続のテストとなります。
あわせてこの用語と記事をチェック