ベータテスト

開発側で動作を確かめても、顧客の機器、通信、日常の手順までは再現しきれない場合があります。
ベータテストは、実際の利用者に近い人が、開発側の試験環境の外で製品を使い、適合や問題を確かめる活動です。
ISTQBの定義でも、開発側の外部の環境で行う受け入れテストとして整理されています。

参加者の条件を選ぶ

たとえば、現場作業員向けの報告アプリを、限られた企業で試すとします。
新製品に詳しい人だけでなく、端末の種類、通信環境、業務量が違う人を含めます。
誰に何を確かめたいかを先に定めると、参加できた人だけで都合よく評価するのを避けられます。
ただし、少数の参加者から市場全体の不具合率をそのまま推定することはできません。

配布前には、対象機能、既知の制限、記録するデータ、支援窓口、終了時の扱いを伝えます。
業務データを使うなら、障害時の回復と代替手段を確認します。
通常業務へ影響する不具合が見つかったとき、利用停止を誰が判断するかも決めます。
試験版と表示しただけで、運用上の責任が消えるわけではありません。

使われた結果を追う

報告アプリなら、起動した回数だけでなく、現場で記録を作り、帰社後に報告を終えられたかを確認します。
途中で中断した場合は、操作の迷い、通信、仕事の都合を分けて聞きます。
報告がない参加者にも、問題がないのか、使う機会がなかったのかを確認します。
不具合を送る手間が大きいと、困ったまま使わなくなる可能性があります。

記録には、製品の版、端末、起きた場面、影響、再現手順を残します。
同じ問題が複数の報告に分かれている場合はまとめつつ、発生した顧客の範囲は保持します。
修正後には再確認を依頼し、直ったことと回避しただけの状態を区別します。

出荷判断の材料にする

試験期間が終わったら、当初の確認事項と、実際に試せた条件を照合します。
重大な問題、残る制限、影響する顧客、対処の予定を示します。
好意的な感想が多くても、重要な業務が完了しないなら提供範囲の縮小や延期を検討します。
逆に、対象外の用途の要望をすべて満たすまで続けると、終了条件が失われます。

管理された環境でのアルファテスト、利用条件全体との適合を見る設計妥当性確認、現地で性能を調べるフィールドテストと役割を分けます。

参考資料