進化するERP、今こそ押さえたいテストの要点――単体テスト編

単体テストは、ERP導入における最初のテスト工程です。標準機能では対応できない要件のために追加開発した機能が正しく動作することを確認します。
やっかいなのは、一般的に単体テストは導入ベンダーまたは導入ベンダーから委託を受けた開発会社によって実施される点です。そのため、テストの実施主体ではないユーザー会社からは、実際にどのようなテストが行われたかが見えにくい工程です。
結果として、単体テストの品質が十分でなかった場合に不具合を検知することが難しく、後工程で問題が明らかになることが多くあります。

例えば、結合テストや総合テストで、以下のような問題が発生したご経験はないでしょうか？

＜結合テスト・総合テストでよく発生する問題事例＞
CASE 1：初歩的な不具合が多発する
CASE 2：エラーが発生した際に必要なアクション（原因や対処方法）がわからない

以上のような後工程で発生する問題は、単体テストの不十分さが原因であることが多々あります。

単体テストについて、上記CASE 1、2の原因にもなり得る、やりがちなNG事例を3つ紹介します。「自分のプロジェクトは大丈夫」と思っていても、意外と当てはまるケースがあるかもしれません。
皆さんのプロジェクトでも同じ状況に陥っていないか、改めてご確認ください。

1. CASE 1の原因となり得るNG事例

   A．単体テストで正常終了したことのみをもってOK判定している（結果データの内容を確認していない）

   • データを登録できたことのみを確認し、登録内容が誤っていないかどうかを確認していない
   • エラーなく処理が終了したことのみを確認し、本来処理されるべきデータが一部処理されていない、または逆に処理されてはいけないデータまで処理されてしまっているといった不具合がないかを確認していない
     例：処理されるべきデータは10件だが、処理されたデータが8件しかない、あるいは12件ある など
   • 画面上にデータが表示されたことのみを確認し、名称などの情報が途中で切れていないかどうかを確認していない

   B．複数の処理パターンが存在するにもかかわらず、単体テストで網羅できていない

   • 複数ある処理パターンのうち、最も単純なパターンしか検証していない
   • 複数のデータ編集パターンがあるにもかかわらず、1パターンしか検証していない
     （結果、すべて同じ編集結果になってしまう）
2. CASE 2の原因となり得るNG事例

   C．単体テスト（とその前の設計工程）で異常ケースが洗い出されておらず、検証もされていない

   • 処理が強制終了（ショートダンプ）した場合に、エラーメッセージが表示されるかどうかを確認していない
   • エラー発生時に、対象のデータを特定できる情報が出力・表示されるかどうかを確認していない
   • エラーメッセージの内容がユーザーにとって理解しやすく、原因や対処方法を把握できるものになっているかどうかを確認していない
   • エラー発生時のハンドリングやリカバリー処理が適切に行われるかどうかを確認していない
     （結果、本来はエラー対象データのみをエラーとして扱うべきところ、すべてのデータをエラーとして扱ってしまう）
   • 処理対象がないケースの挙動を確認していない
     （結果、0件処理の際にエラーとなってしてしまう）

ERP本体と外部パッケージを密に連携させる場合は、単体テストの段階から関係システム間のデータ受け渡しや前提条件を擦り合わせる必要があります。
外部パッケージはERPの担当ベンダーとは異なるベンダーが開発するケースもあるため、仕様の擦り合わせにはとくに注意が必要です。単体テストの段階でしっかり仕様を擦り合わせ、検証精度を向上させることが後工程の品質向上に直結します。

後工程で障害が多発する場合、その原因の多くは単体テストにおける確認不足や、異常系を含めたテスト工程の不足にあります。
単体テストの品質を高めることは、後工程での手戻りや障害対応工数の削減につながります。

著者：黒木 仁、川島 靖大