ブログ

まず、次のような事項を決めます。

• 期間：どれくらいの日数をかけるか
• 担当者：誰がテストを行うか（実際にシステムを使う現場担当者を含めるのが理想）
• 範囲：どの機能・業務を対象とするか
• 合格基準：どのような状態であれば合格とするか
• 不具合の報告方法：誰に、どの形式で報告するか

受入テストの期間は、開発スケジュールの終盤にしわ寄せされて短くなりがちです。プロジェクトの初期段階から、受入テストの期間と担当者の工数を確保しておきましょう。

テストシナリオとは、「どの操作を、どの順番で行い、どのような結果になれば正しいか」をまとめたものです。機能を一つずつ触るだけでなく、実際の業務の流れに沿ってシナリオを作ることがポイントです。

たとえば受注管理システムであれば、「顧客から注文を受ける → 受注を登録する → 在庫を確認する → 出荷指示を出す → 請求書を発行する」という一連の流れを通して確認します。

シナリオ作成は開発会社が支援してくれることも多いですが、業務の実態を最もよく知っているのは発注者です。開発会社任せにせず、自社の業務の視点で内容を確認しましょう。

シナリオに沿って操作し、結果を記録していきます。確認した内容は「合格」「不合格」「保留」などに分けて、チェックリストに残しておくと後の判定がスムーズです。

問題を見つけたら、開発会社に報告します。報告の際は、次の情報をそろえると原因の特定が早くなります。

• 発生した画面・機能
• 行った操作の手順
• 期待していた結果と、実際の結果
• 発生日時、使用した端末やブラウザ
• 画面のスクリーンショット

「動かない」「おかしい」だけの報告では、開発会社が再現できず、対応に時間がかかってしまいます。

修正されたものを再度テストし、問題が解消されたことを確認します。すべての確認が終わったら、事前に決めた合格基準に照らして合否を判定します。

要件定義書に記載した機能がすべて実装されているかを確認します。要件定義書を手元に置き、一つずつチェックしていくと漏れを防げます。

個々の機能が動いても、業務の流れの中で使いにくければ意味がありません。前後の作業とのつながりや、画面遷移の自然さを確認します。

テスト用の整ったデータだけでなく、実際の業務で扱うデータ（桁数の多い金額、長い名称、特殊な文字など）で試すことが重要です。可能であれば、本番に近いデータ量でも確認しましょう。

通常の操作だけでなく、「入力を間違えた場合」「途中で操作をやめた場合」「月末や年度末など特殊な時期の処理」など、例外的なケースの動作も確認します。

文字の読みやすさ、ボタンの配置、エラーメッセージの分かりやすさなどを確認します。現場担当者に実際に操作してもらうと、設計段階では気づかなかった使いにくさが見えてきます。

利用者の役割ごとに、見られる情報や操作できる機能が正しく制限されているかを確認します。情報漏えいや誤操作を防ぐうえで、見落とせないポイントです。

請求書、集計表、CSV出力など、システムから出力されるデータの内容・レイアウト・計算結果を確認します。特に金額の計算や端数処理は、手計算や既存の帳票と照らし合わせて検証しましょう。