システムの受入テスト、何を確認する？

テストする人は、対象業務を理解している必要があります。授業管理なら、時間の空いている一人に任せるのではなく、登録受付、授業調整、経理などの担当者が候補になります。

結果を取りまとめる人と、受入に影響する問題を決められる人も必要です。操作する人に、範囲変更や運用リスクの承認権限があるとは限りません。

開始前に、ソフトの版、対象機能、準備条件を合意します。未実装の連携を模擬するなら、その制約を記録し、実際の流れ全体を確認済みとは扱いません。

受入基準は、観察できる結果にします。「変更が便利」より、受講者と講師の予定に新しい授業が表示され、元の授業が合意した状態になる、と示す方が確かめられます。

要件分析とは？開発の方向性を明確にする最初のステップ

よくある流れから始める

架空の例として、担当者が受講者をパッケージに登録し、授業を予約し、出席を記録して、残回数を確認します。関連する工程とデータを通すため、「保存」だけを押すより多くを確認できます。

各場面に、初期条件、役割、操作、期待結果を設けます。「登録成功」だけでは、どの状態、予定、データを照合すべきか分かりません。

記入例：

• 場面番号：CLASS-01。

• 役割：授業調整担当者。

• 条件：受講者に有効なパッケージがあり、一回分が未使用。

• 操作：条件を満たす授業を予約し、確定する。

• 確認結果：受講者、講師、状態が正しく記録され、回数の確保・消化が合意したルールに従う。

• 証拠：操作前後のデータと必要な画面画像。

この例の回数消化ルールが、どの施設でも同じとは考えないようにします。プロジェクトの実際のルールは業務側が示します。

影響する例外を加える

通常の流れに続き、期限切れ、残回数なし、講師の予定重複、権限不足、再送を試します。

記録後の取消、講師変更、日程変更、誤入力の修正も確認します。状態とデータの関連付けがどのように管理されるかが見えてきます。

すべての場面を無限に並べることはできません。影響と頻度から優先し、未確認の範囲を残します。結果は、実施した範囲と条件と合わせて読み取ります。

パッケージ種別、受講者の状態、権限、重要な例外など、実際に近い構造のデータを用意します。正常なケースだけでは、日常業務を反映しにくくなります。

情報漏えいを抑えるため、架空データや適切に加工したデータを優先します。実データが必要なら、試験環境に合う承認と管理を行います。

実際のメール送信、決済、外部システム更新が起きないか確認します。試験操作が意図しない影響を与えないよう、技術担当が対策を設定します。

参加者には、操作できるだけの説明も必要です。使い方を知らなければ、不具合よりも説明不足を反映した結果になることがあります。分かりづらさは、使いやすさや教育の課題として記録します。

問題が出たら、場面、アカウントの役割、時刻、手順、実際の結果、期待結果を記録します。画像や録画には必要な情報だけを含めます。

「日程変更できない」だけでは不十分です。「CLASS-03で、未実施授業を有効な日へ変えると成功表示になるが、講師の予定は旧時刻のまま」と示す方が具体的です。

要件との差、新しい要望、未確定事項、操作上の難しさを分類します。資料と期待結果をもとに話し合い、すべてを不具合、あるいは追加作業と決めつけません。

修正後は、問題のあった場面と影響する関連部分を再確認します。開発側の「対応済み」という連絡だけで閉じないようにします。

各回の前に版と変更点を知らせ、古い版で試さないようにします。データが初期化されたら開始条件を準備し直します。回ごとに証拠を残すと、未解決の問題と後から生じた問題を区別できます。

合格、不合格、未実施、試験の制約をまとめます。残課題には担当、対応、再確認時期を設けます。

利用を妨げない課題もありますが、受け入れる判断は権限者が行い記録します。重要業務を妨げる条件は、合意した基準で対応します。

受入と稼働開始は関連しますが、同一の判断ではありません。テスト結果に加え、データ、説明資料、支援窓口、切替条件も見ます。

新システムの稼働開始で業務への影響を抑えるには

計画時から、担当者、重要な場面、受入基準を決めましょう。受入時に具体的な根拠で評価し、意見の違いを解決できます。

システム開発前に準備すること

Fenixのシステム開発プロセスについて