デモの録画から受け入れチェックリストを作る方法

デモで確かめられるのは実際に示された場面

会議ではフォームが正しく申し込みを送信するように見えました。しかし別の権限での操作、再送信、必須項目の未入力は扱っていないかもしれません。録画は示された内容を確認する資料です。他のシナリオは別に検証します。

チェックリストは事前に合意した要件から作ります。視聴者からの新しい案は役立つ場合でも別に記録します。受け入れ中に範囲が変わると、参加者が別の内容を話し合うことになります。

録画から検証の準備をする

1. バージョンと条件を記録する

   バージョンやビルド、実演者、使用した権限を記します。他の人が再現できる程度にテストデータと環境を説明します。不明な条件には印を付けます。

2. 項目を要件に結び付ける

   合意した動作を示す録画箇所を探します。一つの実演で複数の確認ができても、期待結果は項目ごとに書きます。必須要件が実演されていなければ「未確認」の項目にします。

3. 操作と期待結果を記述する

   「フォームを確認する」とだけ書かず、入力する値、押す箇所、起こるべき結果を記します。不正な入力に対する動作も示します。新しい例外条件は合意した範囲に含まれる場合だけ追加します。

4. 改めて確認する

   合意したバージョンで操作を実行し、実際の結果と証拠を残します。失敗、確認の阻害、データ不足を分けます。修正したら関連する操作を再実行し、新しい日付を記します。

相談申し込みフォームの受け入れ

架空の学習例です。名前、条件、結果は方法の説明用です。

確認できる結果は三つです。必須欄の検証、申し込みの作成、訪問者への確認表示です。操作後の画面だけで確認できるのはその一部です。

検証者が申し込み一覧を見られなければ、作成の確認は「阻害あり」と記録します。実演者の説明だけで合格としません。

確認項目のテンプレート

各行に、どの観察で最終ステータスを決めるかを書きます。

確認ID：
合意した要件：
バージョン／権限／環境：
入力データ：
操作：
期待結果：
実際の結果：
状態：合格／失敗／未確認／阻害あり
証拠とタイムコード：
関連する修正：
再確認日：

実行前にチェックリストを確認する

• 項目が合意済みの範囲を参照している。
• 期待結果を観察または測定できる。
• 録画に映った内容と自分で実行した検証を区別している。
• 失敗を再現できる条件がある。