想定例として、受発注管理システムの受け入れテストを担当することになった場面を考えます。開発会社からテスト項目書が届き、画面を一つずつ確認していく。入力欄にデータを入れて、保存ボタンを押して、表示が正しいかを見る。項目はすべて「OK」になった。ところが本番稼働後、現場から「朝の受注集中時間帯に画面が固まる」「複数人が同時に編集すると片方の変更が消える」といった声が上がる。テスト項目書には存在しなかった状況です。
受け入れテストは、仕様書に書かれた機能が動くかどうかの確認だけでは不十分なことがあります。現場の一日の中で、いつ、誰が、どんな順番でその機能を使うかを想像し、そこから検証項目を組み立てる視点が必要です。
仕様書ベースのテストで見落としやすいこと
仕様書に沿ったテストは、機能が単体で正しく動くかを確認するには向いています。しかし業務は単体では動きません。朝一番に前日分のデータを確認する担当者と、日中に新規受注を入力する担当者が同じ画面を同時に使う、月末だけ特別な集計作業が発生する、といった時間帯や業務の重なりは、仕様書だけでは見えにくい部分です。
受け入れテストを設計する際は、まず現場の一日の流れを書き出すことをおすすめします。朝・昼・夕方・月末といった時間軸で、誰が何を行うかを並べてみると、同時アクセスやデータの受け渡しが発生する場面が見つかります。そこが本来重点的に確認すべき箇所です。
「この機能を使うのは一日のうちいつですか。同時に使う人は他にいますか」
この問いを現場担当者に投げかけるだけで、テスト項目書にない確認ポイントが見つかることがあります。
既存の確認手順で足りる場合、開発会社に相談すべき場合
すべてのケースで大がかりなテスト計画を組む必要はありません。既存の確認手順で足りる条件と、開発会社を交えた見直しが必要な条件を分けて考えます。
既存の確認手順で足りると判断できる条件は、利用者が少人数で同時アクセスが発生しにくい、入力内容が単純で分岐が少ない、過去の類似システムで大きなトラブルがなかった、といった場合です。この場合は仕様書ベースのチェックリストに、時間帯別の確認項目を数個追加する程度で対応できることが多いです。
開発会社を交えた見直しが必要と判断できる条件は、複数人が同じデータを同時に編集する、繁忙期と閑散期で利用のされ方が大きく変わる、外部システムとの連携があり片方の遅延がもう片方に影響する、といった場合です。こうした条件がある場合、受け入れテストの段階で開発会社に「想定される同時利用シナリオ」を共有し、テスト環境でその状況を再現してもらう相談をすることをおすすめします。
現場担当者を巻き込んだテスト設計の進め方
受け入れテストを現場の一日から組み立てる場合、情報システム部門だけで項目を作るのではなく、実際に使う現場担当者に一日の動きを聞き取る工程が重要になります。想定例として、物流倉庫の在庫管理システムであれば、入荷担当者・出荷担当者・棚卸し担当者それぞれに「一日のうちどのタイミングでシステムを使うか」を聞き、その重なりを図にしてみます。
聞き取りの際は、抽象的な質問よりも具体的な場面を想像させる質問の方が答えやすくなります。
「先週の月曜の朝、システムを開いてから最初に何をしましたか。その後どんな順番で作業しましたか」
この質問は、仕様書には出てこない作業順序や、担当者が無意識に行っている確認作業を引き出すのに役立ちます。テスト項目書はこうした聞き取りの結果を反映して更新していくと、現場の実態に近い検証になります。
テスト結果の記録と運用改善への引き継ぎ
受け入れテストで見つかった問題は、修正して終わりではなく、どのような状況で発生したかを記録しておくことが大切です。たとえば「朝9時台、受注入力が3人同時に行われた際に表示が遅延した」という記録があれば、運用開始後に同様の遅延が起きた際、原因の切り分けが早くなります。
またテストで問題が出なかった項目についても、どんな条件で確認したかを残しておくと、将来システムを改修する際に「以前はこの条件で問題なかった」という判断材料になります。受け入れテストは一度きりのイベントではなく、運用改善の起点として記録を蓄積する工程と捉えると活用しやすくなります。
- 現場の一日の流れを時間帯別に書き出し、関係者と共有したか
- 同時に同じ機能を使う人がいる場面を洗い出したか
- 繁忙期・月末など特別な業務が発生するタイミングを確認したか
- 外部システムとの連携がある場合、片方の遅延や停止の影響を想定したか
- 現場担当者に具体的な作業順序を聞き取る時間を設けたか
- テスト結果を発生条件とあわせて記録する形式を決めたか
- 開発会社に相談すべき条件（同時編集・繁閑差・外部連携）に該当するか確認したか