受け入れテストをどこまでやるのか？

1.受け入れテストの悩みどころである「受け入れテストをどこまでやるのか」

ベンダーが作成した成果物に対し全てをテストするのであれば、品質はある程度確保できるかもしれません。しかし、それではテストケースが多くなり時間がかかりますし、ベンダーがテスト済みの項目に対して、受け入れテストでまた同じことを行って作業の重複によるムダが生じてしまうことにもなります。現実問題として、受け入れテストに十分な時間を割ける余裕がなく、テスト項目数をできるだけ少なくしたい、というケースが多くあります。稼働してから不具合を起こしたくはないものの、テストの時間を節約したいという場合、どのような対応を考えればよいのでしょうか。

2.特に重要な機能を重点的にテストする

テストにあまり時間をかけられないというのですから、全ての機能を念入りにチェックする余裕はありません。そうであれば、重要な機能を重点的にテストするよりほかに方法はありません。従って「特に重要な機能」をいかに適確に洗い出すか、がポイントになります。絶対に不具合を出してはならない機能、自社の強みを阻害する機能など基準を定めて、洗い出すことが必要になります。

次に、「特に重要な機能」を定めたら、どのようなテストを行うかを決めることが必要です。大きな漏れや抜けがないことを確認するという観点に立てば、日常の運用業務は元より、四半期や半期でしか行わない特定の業務などは、テスト範囲に採用することが必要だと思います。ここでの基準は、特に重要な機能が誤動作を起こし、致命的な事態に陥るリスクを軽減させる、という観点に立っています。

3.実運用環境で実データを使ってテストする

ベンダーは、テストデータを使って開発・テストを行うことが多いため、受け入れテストでは実際に扱うデータを使ってテストをするようにしましょう。また、他システムに連携する機能があった場合、開発中は擬似的な接続先を設定したうえでテストを行い、本番で実際の他システムに接続することがありますが、これがうまくいかない場合があります。その不具合を発見する機会は受け入れテストしかありません。従って、開発環境と実運用環境の違いに着目し、そこに絞って受け入れテストを実施するというのも効果的です。ここでの基準は、開発環境から実運用環境に移行した際に顕在化するリスクを軽減させるという観点に立っています。

システムの稼働直前、受け入れテストに十分な時間を割ける余裕がないときに、いかに適切なテストを実施すべきか、ということを幾つか考察した例でしたが、これらはリスクを想定しそれに沿ったテストの指針を導き出した、いわば必要最小限のものです。受け入れテストの対象から外れたものは、システムの稼働直前よりもっと前のフェーズで検証されていることが前提になります。それをベンダーで行うのか、ユーザーで行うのかはケースバイケースですが、もしベンダーが行うとしたら、ベンダーが行うテストの内容をユーザーと合意し、そのテスト結果を発注者として確認することが重要だと思います。

［SE］2020年2月12日

ApaRevo 活用コラムトップ