ソフトウェアテストを学ぶ　その７．受け入れテストについて神妙な面持ちで書いてみた

こんちは。ふっ太郎くらです。

今回は受け入れテストについて神妙な面持ちで勉強したいと思います。

聖なる感じがしますね♡

受け入れテストは・・・

ようなテストです。

受け入れテストは顧客の要求・要望通りシステムや製品が動くことを確認する。

新規に稼働させるシステムや製品であれば、導入からセットアップ、実験運用までを確認する。

機能拡張や不具合修正の適用であれば、導入から変更箇所に限定した確認のみ行う。

これまでの前段のテストのように、ソフトウェアや仕様上の欠陥を検出することが目的では無く、目的に沿って、運用環境化で正常に動くこと、要求通り、ソフトウェアが作られていることを実験運用しながら確認する。

受け入れテストでは、要件定義書をベースに、運用シナリオやユースケースに基づいてテストする。

前段のテストのように、仕様ごとに細かなテストを起こすのではなく、運用ケースに基づいたシナリオや、修正した不具合の発生条件 (再現条件) をシナリオ化してテストする。

かっちりとしたテスト書を作成することもあれば、簡易なチェックリストを作成してテストすることもある。

(モジュールやライブラリの受け入れテストは後者が多い)

顧客環境への導入も含めたテストになるため、以下の機能要件、非機能要件を中心に確認する。

受け入れテストは、操作説明書や導入マニュアルも検証の対象となる。

各種マニュアルに記載の手順に従い、導入、操作が正しく行えることを確認する。

受け入れテストは、開発プロジェクトに直接関係していない顧客が行う。

以下のような方法でテストを実施し、評価する。

テスト方法	確認する人	確認方法
契約による受け入れテスト	顧客	契約締結時に決めた受け入れ条件 (発注条件) に基づいてテストする。医療機器であれば、医療機器等法など。
規定による受け入れテスト	顧客	法律や安全基準に従い適合しているかをテストする。
αテスト、βテスト	現在の顧客将来の顧客 (潜在顧客) プロジェクト外の社内メンバー	市場にソフトウェアをリリースする前に、現在の顧客や潜在顧客、プロジェクト外の社内メンバーに使用してもらい、欠陥や操作性の悪さ等の課題点の抽出を行う。

完全に個人の経験上の話でしかないが、受入テストの結果は・・・

の何れかに分かれる。

(中途半端に動くものは経験上殆ど無かった)

汎用性が高く、一般的に使われているものは問題が少なく、ニッチマーケティングなソフトウェアや製品は、クリティカルなバグが多かった。

前者は、Tcp/IPのプロトコルスタックやCIFSのライブラリーなど。

後者は、一般普及する前のBuletoothのプロトコルスタックやSIP/IMSライブラリなど。

(時代は変わり、今はそれなりに動くと思う)

受け入れテストは顧客要望・要求通りシステムや製品が動くことを確認するテスト。
受け入れテストは仕様との整合性や欠陥の検出が目的では無く、要求通りソフトウェアが使えることの確認が目的。
受け入れテストは主に導入から仮運用までをシナリオ形式でテストする。導入手順書や取説も検証の対象になる。
受け入れテストは顧客が行う。評価方法・内容は、契約や基準、目的によって変わる。
出所が怪しいソフトウェアの受け入れテストは要注意！ (特に海外製)「ちょっと、1，2時間で簡単にテストしてみてよ」と頼まれて、1週間格闘するようなことが普通に起きたりするぞ！欠陥や挙動についてベンダーに問い合わせても、返事が無かったり、逆切れされたりするぞ！

[参考]