受注システムのテストは何を準備する？注文の登録結果を確かめる手順

「新しい受注システムで、注文が正しく登録されるか確かめたい。でも開発会社に何を用意して渡せばよいか分からない」。受注の仕事を担当する方や、システムを発注する責任者へ。実際の取引先の情報を使わず、試す前の状態・入力する注文・保存後に確かめる結果を、一組にして準備します。

たとえば、最初にテスト用の注文が1件ある状態で、商品8個の注文を新しく登録します。元の1件を残して合計2件になる、というのが試す前に決める結果です。実際に2件になったかは、試した後に別に記録します。試験のためのメール送信や出荷などが動かないかも、始める前に確認します。

この記事を読めば、自社で確かめたい注文を一つ選び、開始状態と入力内容、期待する結果、次の試験に向けた戻し方を開発会社へ相談できるようになります。数量の上限や戻し方が分からない場合は、未確認として質問を残しましょう。

テスト用の注文を作る前に、何を決める？項目と保存ルールを確認する

テストデータとは、システムの動きを確かめるために用意する入力値や、試す前に存在するデータです。たとえば、取引先の一覧、商品の一覧、すでに保存された注文、これから入力する数量が当てはまります。

一方、「8個の注文を追加したら、元の1件を残して合計2件になる」は、試す前に決める期待結果です。実際に何件になったかは、試した後に別に記録します。期待結果を先に実績欄へ書き写さないことが大切です。

PC用図を原寸で開く / スマートフォン用図を原寸で開く

図：試す前の注文、入力、期待する結果を一組にします。

はじめに、発注責任者と開発窓口で、項目名、数量の単位、必須項目、入力できる範囲、同じ注文番号を使った場合の扱いを確認します。決まっていないことは「未確認」とし、確認する相手を残します。

この例では、次の登録ルールを使います。実際のシステムの仕様ではありません。

• 販売先と商品は、用意した一覧にあるものを使う。
• 数量は1〜100の整数個。空欄、小数、範囲外は保存しない。
• すでにある注文番号で新規登録しようとしたら保存せず、元の注文を変更しない。
• 一つずつ独立して試すときは、毎回、最初の注文1件がある状態から始める。

同じ入力でも、使う人の権限や試験日時が違うと、対象機能によって結果が変わることがあります。必要な条件が分からない場合は、開発会社に確認してから試しましょう。

テスト用の取引先・商品と、最初の注文を用意する

まず、販売先と商品をそれぞれ一つ用意します。実顧客の台帳をコピーするのではなく、次のようにテスト用の行を作ります。

表は横にスクロールしてご覧ください。

コードは、それぞれの一覧の行を見つける目印です。次に、試し始める前から存在する注文を一件決めます。

表は横にスクロールしてご覧ください。

販売先C001と商品P001が一覧にあり、注文TEST-EX01が8個で1件ある。これが、以下の各試験の開始状態です。注文に書いたコードと一覧のコードが一致しているか確かめてください。わざと一覧にない商品を試す場合は、用意漏れと混同しないよう、その目的を書きます。

PC用図を原寸で開く / スマートフォン用図を原寸で開く

図：テスト用の初期注文と、参照する販売先・商品の対応。

注文を入力すると何件残る？開始状態と期待結果を一緒に書く

次の11例は、いずれも「開始時にTEST-EX01の8個が1件だけある」「C001とP001が登録済み」という同じ条件から、一つずつ独立して試します。各例の販売先はC001、注文1件につき商品は1種類です。注文番号・販売先・商品・数量は必須とします。11件をまとめて登録するのではなく、毎回、最初の1件に戻してから次の例を試してください。

「下限のすぐ下・ちょうど・すぐ上」と「上限のすぐ下・ちょうど・すぐ上」を並べると、受け付ける範囲の境目を確認できます。P099は、この例では一覧にないことを試すためのコードです。

すべての例で、もともとあるTEST-EX01の8個は変更されずに残る想定です。表は期待結果であり、実際にシステムを試した結果ではありません。実施するときは、使用したシステムの版、確認した人、実際の保存件数や画面の状態を別に記録し、期待と違えば開発会社へ伝えます。

PC用図を原寸で開く / スマートフォン用図を原寸で開く

図：数量の下限と上限、その前後で登録できるかを確認します。

テストのたびに注文を元へ戻すには？実際の戻し方を確認する

通常の注文を試す前に、この例のルールでは注文が2件になると期待します。実際に何件になったかは、試した後に確認します。次に数量空欄の例を試すときは、追加した注文を持ち越さず、最初の1件へ戻してから始めます。そうすれば、空欄の入力後に「新しい注文は保存されず、元の1件が残るか」を確認できます。

PC用図を原寸で開く / スマートフォン用図を原寸で開く

図：次のテストを始める前に、注文を最初の状態へ戻します。

たとえば、最初にある注文 TEST-EX01 が8個、1件だけの状態から始めます。新しい番号 TEST-N01 で8個を登録した場合、元の注文を残して合計2件になることを期待します。次の試験の前に、追加分を戻して開始時の1件にそろえます。

次に数量を空欄にした注文を試す場合、新しい注文は保存されず、元の1件が残る想定です。既存の番号 TEST-EX01 で12個を新規登録しようとする場合も、この例のルールでは重複として保存せず、元の8個の注文1件が残る想定です。それぞれ開始状態を1件にそろえ、実際にどうなったかを記録して期待結果と比べます。

実際のシステムで試験用の注文を戻す方法と担当は、開発会社に確認してください。ブラウザーを閉じるだけで、システムに保存された注文が消えるとは限りません。

メール送信、出荷、請求などが動く設定では、試験用の注文でも影響が出る場合があります。試験する場所と連携の状態が分からなければ、確認できるまで実行を待ちます。戻す権限がない場合も、自分で戻せたことにせず、担当者へ依頼しましょう。

同じ注文を戻さずに続けて試す場合は、開始状態が変わります。連続した操作を確認したい場合は、順序と開始条件を別のシナリオとして書きます。

開発会社に何を渡す？自社の1ケースと未確認事項をまとめる

まずは、自社で確認したい入力の仕事を一つ選びます。そして、次の内容を開発会社と確認します。

PC用図を原寸で開く / スマートフォン用図を原寸で開く

図：開始状態、入力、期待する結果と戻し方を開発会社へ伝えます。

表は横にスクロールしてご覧ください。

数量の上限が未合意なら、まず仕様を確認します。一覧にないコードは「用意し忘れた」のか「存在しないことを試す」のかを区別します。日時や在庫が結果に影響する仕事なら、それらの開始値も確認してください。

この11例は、新しい注文の登録を小さなテスト用データで試すものです。大量データでの速度、複数明細、同時登録、注文の取り消し、出荷から請求までの一連の流れを確認したことにはなりません。必要な場面は、実際の業務に合わせて別の試験として整理します。

まとめ：同じ条件をそろえて、結果を比べられるようにする

用意するのは、入力する値だけではありません。テスト用の取引先・商品と最初の注文をそろえ、入力後に何が残るはずかを決め、次の試験の前に戻す方法まで確認します。

PC用図を原寸で開く / スマートフォン用図を原寸で開く

図：入力した注文と保存一覧を照合します。

試した後は、画面に表示された注文番号・商品・数量と、保存された注文一覧を照合します。元の注文が残っているか、新しい注文が追加されたかを確認し、実際の結果を記録してください。期待した結果と違う場合は、入力内容・画面の表示・確認した時刻を添えて、開発会社の担当者へ伝えます。保存先や確認方法が分からなければ、その場で担当者に尋ねましょう。

まずは一つの注文から始めてください。「最初にある注文」「入力する内容」「保存後に残るはずの内容」を並べ、分からないところは未確認のまま開発会社に尋ねます。その一組があれば、同じ条件で試し、期待との違いを次の相談につなげられます。

試験結果をもとに受け入れるか判断する段階では、発注者の受入テスト確認表も参考にしてください。

入力・担当・例外の整理で迷う場合は、相談窓口へ、準備したテスト用データと未確認事項を添えて相談できます。実際の支援範囲は個別に確認します。

出典と適用範囲

• ISTQB Test Analyst syllabus v4.0 §1.3.5：https://istqb.org/wp-content/uploads/sdm-uploads/ISTQB-CTAL-TA-Syllabus-v4.0-EN-4.pdf — テストデータの目的、前提条件、機密性、有効・無効な入力を検討する考え方。本文の数量と注文は記事で用意した例です。
• IPA ソフトウェアテスト見積りガイドブック 用語解説「ブラックボックステスト」 — 境界値分析をデータ設計技法の一例として挙げている。本文の数量範囲は説明のために設定した条件です。
• PostgreSQL 18：制約の説明 §5.5.5 — データの参照先の存在を保つ仕組みの例。紙やCSVに同じ仕組みが自動的に備わることを意味しない。