アルファテスト

開発した本人には、操作の前提や回避方法がわかるため、明らかな使いにくさを見逃すことがあります。
アルファテストは、早期の製品を管理された環境で試し、重大な欠陥や仕様の不足を見つける活動です。
ソフトウェア分野では、ISTQBの用語集が、開発側の試験環境で、開発組織の外の役割が行う受け入れテストと説明しています。
製品分野によって呼び方が異なるため、社内での対象と担当を先に定めます。

最初に成立すべき作業を選ぶ

たとえば、店舗向けの発注端末を作る場面を考えます。
商品を探し、数量を入れ、送信し、結果を確認する基本操作を試します。
正常な入力に加えて、通信が途切れる、数量を訂正する、同じ注文を再送するといった場面も用意します。
全機能を広く触る前に、商品を誤発注するなど影響の大きな問題を優先します。

試験には、対象版、機器とデータ、開始状態、期待する結果を記録します。
同じ問題を再現できなければ、修正できたかも確かめにくくなります。
開発担当者が毎回横から助けると、本来の操作条件が変わるため、助けた内容も結果に残します。
試験者には、既知の不具合と、触ってよい範囲を共有します。

欠陥と仕様の疑問を分ける

送信済みの注文が消えるなら、意図した動作との違いを調べます。
一方、店員が送信の成否を判断できないなら、画面の設計や仕様自体を見直す必要があるかもしれません。
すべてを実装ミスとして処理せず、仕様を変える判断と、不具合の修正を区別します。
問題ごとに、影響、再現条件、対応方針を記録します。

修正後は、問題が出た手順を再実施し、周囲の機能へ影響が出ていないかも確認します。
試験の終了条件は、件数だけで決めず、重大な問題が残っていないかと、残した問題を誰が受け入れたかで判断します。
予定日になったことを、品質の条件を満たしたことに置き換えないようにします。

アルファでわからないこと

管理された試験で動いても、実店舗の通信、繁忙期の作業、他機器との併用までは再現できない場合があります。
試せた条件と、現場で確認する条件を分けて引き継ぎます。
好意的な感想が得られても、顧客の購入や継続利用は別の確認です。

利用環境を広げるベータテスト、意図した用途との適合を見る設計妥当性確認と組み合わせます。

参考資料