架空の会社が、営業の受注入力と出荷担当の参照を開発会社へ依頼しました。納品候補で一覧画面が開いても、注文U012を保存し、出荷担当が同じ数量を見られるかは未確認です。経営者は、見た目の印象と、合意した仕事ができることを分けて判断します。

受入テストでは、対象の版、利用者の役割、入力資料、期待する結果を先に決めます。開発会社が実施した技術テストの結果も確認しますが、それだけで自社の仕事の確認を代行したとは扱いません。業務担当が、必要な場面を実際の操作で確かめます。

IPAの要件定義資料は、運用やテストも要求へ含める観点を示しています。本稿は受注登録の架空教材で、全システムの品質保証を網羅するものではありません。性能や安全性、法令上の条件などは、合意した別の検証項目も残してください。

この章の根拠：出典1

架空注文U012の数量は10ケースとします。営業が番号U012、商品P01、数量10を入力して保存したら、同じ値が記録に残ることを期待結果にします。次に画面を開き直し、出荷担当もU012の10ケースを参照できるか確認します。

確認表には、入力した値、操作する役割、保存した時刻、実際の結果を残します。「問題なし」だけでなく「U012・P01・10ケースを保存、出荷側の表示も一致」と書けば、後からどこまで確かめたか読めます。別の注文が変わっていないことも照合します。

期待結果は、操作後に都合よく変えません。発注時の条件が足りない場合は、テスト前に発注者と開発会社で補足を合意します。複数の単位や小数を扱う仕事なら、この整数ケースだけで合格とせず、実際の条件を別の例として加えてください。

この教材では数量を1〜500の整数ケースと合意したとします。空欄、文字、501ケースをそれぞれ試し、どの欄がなぜ受け付けられないかを利用者が理解できる表示か確認します。数量の条件は自社で決めるもので、この範囲を一般ルールとして使いません。

誤入力の試験では、画面のメッセージだけでなく保存結果を見ます。保存済みU012が10ケースのとき、空欄のエラーで数量が空になっていないか確認します。入力欄へ値が残ることと、正式な記録へ保存されたことを区別してください。

W3Cの入力検証は、誤りを利用者へ伝え、サーバー側でも検証する参考になります。ブラウザーの警告が出れば全条件を満たすとは言えません。開発会社へ業務の条件が保存側でも守られるかを尋ね、確認した範囲を表へ残します。

この章の根拠：出典2

数量を空欄から12へ訂正して保存したら、U012が12ケースになることを確認します。新規登録なのか、保存済み注文の修正なのかを合意条件で区別します。修正したつもりで同じ注文が2件できると、通常の入力試験が成功していても仕事では困ります。

保存ボタンを連続して押した例も、開発会社が用意する試験場所で確認します。同じ注文を重複登録しない条件、重複候補を知らせる表示、利用者が待つべき場面を確認します。自社の実注文や本番へ大量送信する試験を教材の前提にしません。

出荷担当は参照のみと合意したなら、数量変更を試みても記録が変わらないかを開発会社と確かめます。ボタンの見え方だけでなく、役割ごとの保存結果を確認します。どの利用者で試したかを残すと、役割設定の変更後にも同じ場面を再確認できます。

期待する12ケースが出荷側で10ケースのままだった場合、確認表へ対象の版、入力、表示の違い、確認時刻を残します。営業が保存できても、出荷担当の仕事が止まるなら重要な不足です。経営者と業務担当が、導入前に解消する条件として扱います。

修正を受け取ったら、同じU012の例をやり直し、関係する通常登録と誤入力も確認します。修正済みという連絡だけを合格の根拠にしません。修正した版と、再確認した担当・結果を結び、未確認の項目を明示してください。

IPAの非機能要求の観点も参考にし、許容する応答時間や障害時の扱いが別に合意されているか確認します。業務の受入テストが合格しても、検索順位や売上等の成果を実証したことにはなりません。合格した範囲と残る検証を分けて報告します。

この章の根拠：出典3

発注者の受入テストは、画面の存在ではなく、合意した仕事の結果を確かめるものです。U012の架空例では、10ケースの保存と参照、空欄の案内、12ケースへ訂正した後の保存を分けました。営業と出荷担当の両方が確認することで、受渡しの不足も見つけられます。

期待結果は先に決め、実際の結果と別欄へ残します。重複、役割違い、元の記録への影響も試し、不足は版と操作を付けて開発会社へ返します。修正後の再確認を含め、自社で確かめた範囲と残る条件を読めるようにしてください。

次に、営業と出荷担当へ合意した注文1件を渡し、下のメモから試験行を作ってください。開発会社には安全な試験場所と不足の修正先を確認します。通常の成功だけで終えず、入力違いとやり直しまで照合してから、導入の判断へ進みましょう。