システムテスト済みと言われたら？機器貸出の一連の仕事と未確認を確かめる

予約から返却・請求前までを、同じ一件の仕事として読む

システムテストでは、一つの処理や接続先だけでなく、対象としたシステム全体の振る舞いと能力を仕様に照らして確認します。何ができるかという機能に加え、応答の速さや情報の保護など、合意した品質の条件も関係します。ただし、「全体」という言葉から、あらゆる仕事や品質条件を試したと推測しないことが大切です。

この例で予定する対象は「予約・在庫・貸出・返却・請求を含む対象版のシステム全体」です。どの機器のどの予約を使い、予約から先の状態をどう用意して何と比べたかを、報告の中で追います。

一件の貸出は、予約から請求の前まで、どの仕事を通るのでしょうか。

引当は、利用する機器を予約へ割り当てることです。受渡では、その予約に対応する貸出の状態を扱います。返却では、戻った機器や未返却の状態を、その後の予約や請求前の確認へ結びます。本稿はこの仕事の対応を読む例で、請求書の発行や入金まで確認した実績を作るものではありません。

小さな日付判定を単独で確かめる段階は、単体テストの入力・期待・実結果を読む方法で扱います。処理のつなぎ目を見る結合テストでは、どの値がどこへ渡るかを読みます。本稿では対象のシステム全体として、仕事の流れと品質の条件を満たしたかを確認します。呼び名が似ていても、対象と目的を報告で確かめてください。

対象版・環境・データと、実行した記録を照合する

報告の合格数を見る前に、その結果がどの仕様、どのシステム、どの環境とデータの話かを特定します。前の版や違う開始状態の結果を並べると、一件の貸出を通して確認したかが分からなくなるためです。必要な材料は、今回の範囲と確認する条件に合わせてそろえます。

この貸出の結果は、どの版・環境・データの、どこまでを確認した報告でしょうか。

この節の解説図を原寸で見る

1. 仕様と対象の版を合わせる期待の根拠になる仕様の版は未確認で、実際に試したシステムの版も未確認です。何を正しいと考え、その条件がどの版へ実装されたかを対応させます。資料の表紙に同じ名称があるだけで同一版と判断しません。
2. 試した場所と構成を読む試験環境は未確認です。予約や在庫、返却の状態をどこで確かめ、外部の機器や仕組みを代替しているかを聞きます。代替を使った結果を、そのまま本番の全構成の結果へ広げません。
3. データと開始状態を対応させるテストデータの版は未確認です。予約可能な例では何を空きとし、空きなしの例では何が既に予約され、返却遅れの例では何を未返却として用意したかを照合します。資料を見た印象だけで、在庫数や既予約の内容を補いません。
4. 実行の記録と期待・実結果を読む試験を行った日は未確認で、実行した担当も未確認です。誰がいつ行ったどの項目かを、入力、期待、結果の記録へ結びます。担当欄があることと、その条件で実行されたことは分けます。
5. 不足の理由と次の確認を残す実施した記録を受け取れていない場合は、まず実施したかを質問します。未実施だと分かったら、その理由と確認できない範囲、次に何を用意して誰が返すかを相談してください。結果がない欄を合格や対象外で埋めません。

通常・空きなし・返却遅れを、別の条件として照合する

予約可能な一件だけを通しても、既に空きがない機器や、予定どおりに返らない機器の扱いまでは分かりません。次の三つは別々の条件の案で、修正前後の結果を並べたものではありません。それぞれの入力、開始状態、期待、実結果を対応させ、違う条件の結果を流用しないようにします。

通常の貸出・空きなし・返却遅れでは、どの状態を分けて結果と比べるのでしょうか。

この節の解説図を原寸で見る

予約可能な機器の通常貸出

想定する操作は「利用者が機器と日付を選び予約」。説明用の入力条件は「架空の機器と予約日。固有ID/価格/在庫数は未設定」です。

期待の案は「空き判定から在庫引当、貸出記録、返却予定、請求前の確認へ同じ予約がつながる」です。

この条件の実結果は未取得で、試験を実施したかは未確認です。不具合の記録と再確認結果も未確認です。

予約した機器と期間が、引当、貸出、返却予定、請求前の確認へどう対応したかを読みます。開発会社には、画面が表示された場所だけでなく、同じ予約の状態をどこで確認したか指してもらってください。操作の成功という一言から、後の仕事まで確かめたと判断しません。

同じ期間に空きがない機器

想定する操作は「別の利用者が同じ機器と重なる日付を選ぶ」。説明用の入力条件は「重複日付だけ。競合時刻/件数は未設定」です。

期待の案は「空きなしの案内が出て二重引当にならず、既予約の状態が保たれる」です。

この条件の実結果は未取得で、試験を実施したかは未確認です。不具合の記録と再確認結果も未確認です。

重なる日付を選ぶ前に、既予約がどの状態で存在していたかを確認します。空きなしの案内が出るという想定と、二重に引き当てず既予約を保つという想定は、別の結果として照合します。案内の画面だけで在庫や既予約の状態を推測せず、同じ条件の記録を読めるようにします。

返却が遅れた機器

想定する操作は「返却予定を過ぎて受付担当が状態を確認する」。説明用の入力条件は「予定日を過ぎたという架空条件。延滞料金/契約条件は未設定」です。

期待の案は「返却未了の表示・次の予約の扱い・請求前の確認対象が分かれる」です。

この条件の実結果は未取得で、試験を実施したかは未確認です。不具合の記録と再確認結果も未確認です。

返却予定を過ぎた条件では、未返却の表示、次の予約への影響、請求前に確認する内容を分けます。延滞料金や契約上の責任は、この例で決めていません。必要なら業務責任者へ自社の扱いと根拠を聞き、その回答を開発会社と試せる条件へ直してください。「返却遅れ」の文字だけで請求額を作りません。

仕事の結果と、速さ・情報の保護・利用しやすさを分ける

システム全体で仕事を通せたかと、合意した品質の条件を満たしたかは、同じ一回の画面確認だけでは判断できません。品質の条件を見るときも、何を求め、どんな状態で測り、何が実際に得られたかを対応させます。「速かった」「安全そうだった」という印象を、そのまま測定や検証の結果へ置き換えないようにします。

予約の仕事が動いたという結果から、速さや権限、利用しやすさまで判断できるでしょうか。

この節の解説図を原寸で見る

応答時間は、要求と測定条件を一緒に読む

求める応答時間は未確認で、測定した応答時間も未確認です。どの操作を、どの始点から終点まで測るか、利用やデータがどんな状態かを合意した条件と照合します。この記事から一律の秒数や利用人数を置いて合格にしません。

権限と情報の保護は、確認範囲と根拠を読む

セキュリティを確認する範囲は未確認です。受付担当と別の役割で何を見たり変えたりできるかなど、必要な確認を仕様と役割に合わせます。正常に予約できた結果だけで、許可されない閲覧や変更を防げたとは扱いません。具体的な確認方法と結果は、開発会社へ確かめてください。

利用しやすさの条件も、必要な操作へ結び付ける

アクセシビリティを確認する範囲は未確認です。対象となる利用者、操作、表示や入力の方法、必要な基準を確認し、その範囲で何を確かめたかを読みます。この例では、特定の基準への適合や、実機・支援技術での試験結果を設定していません。

本番環境と同等と判断できるかも未確認です。代替の仕組みや小さなデータで得た結果は、その条件の結果として残します。本番で必要な条件まで言えるかを開発側に説明してもらい、条件が違って判断できない範囲は確認先と次の行動へ結びます。

報告の不足と業務条件を、答えられる相手へ返す

読めない点があれば、どの条件の何が不足しているかを指して相談します。試験記録の不足は主に開発会社へ、仕事として正しい状態や例外の扱いが決まっていない場合は業務責任者へ聞きます。技術と業務の両方に関係する点は、同じ貸出一件を示して回答を対応させてください。

足りないのは、実行した記録でしょうか。それとも、期待を決める業務条件でしょうか。

実施や結果の記録が不足している場合

「どの版とデータで、空きなしの案内、既予約、在庫の状態を照合しましたか。実結果の場所を指してください」のように聞きます。結果が得られたら期待との比較へ進み、未実施だと分かった範囲は理由と次の確認を相談します。実施したかも分からない範囲は、そのことを明示して結論を保留します。

何を正しい状態とするかが決まっていない場合

返却遅れで次の予約や請求前確認をどう扱うかを、業務側の資料と仕事の流れに合わせて聞きます。条件が決まったら、開発会社と入力、開始状態、期待する結果を具体化します。回答を得ただけで実行や合格にせず、実際の版と環境で何を確かめるかへ結び直します。

この例では、実際の顧客との契約も未確認です。契約上の納品物や受け入れ方は、納品物と検収条件を発注前にそろえる方法で確認してください。試験報告への質問から、個別の請求や支払いの条件を推測しません。

回答と修正を同じ条件へ戻し、受入・本番の判断を分ける

回答や修正が届いたら、元の条件と何が変わったかを読みます。対象の版、使うデータ、期待する状態を変えた場合、以前の結果をそのまま新しい条件へ引き継ぐことはできません。変更した理由と、もう一度確かめる仕事を対応させます。

回答や修正を、どの貸出条件と結果へ戻せばよいでしょうか。

三つの場面をすべて実施したかは未確認で、このシステムテストの合否も未判定です。予定していた条件の数や、報告の合格率だけから、確認できない場面を消してはいけません。実施範囲と残る問題、その業務への影響を読んで判断します。

発注者が受け入れた判断は未確認で、本番へ進める判断も未確認です。開発側のシステムテスト結果を、発注者の業務確認や本番可否へそのまま移しません。業務として受け取れるかを利用者の操作で確かめる段階は、通常・入力違い・やり直しで行う発注者の受入テストにつなげます。

試験前に対象、役割、版と環境、始める・終える条件をそろえる方法は、テスト計画の対象と準備を決める方法で扱っています。本稿は、その計画を作っただけの状態と、条件ごとの実施結果を読める状態を区別するための説明です。

まとめ：一件の貸出と三つの条件で、報告の結果を読む

最初に何を選び、報告のどこを指して質問すればよいでしょうか。

読む順序は、対象と仕事の範囲、版・環境・データ、条件ごとの期待と実結果、実施していないと分かった範囲とその理由、残る問題と次の確認です。品質の条件も、その要求と結果を別に照合します。すべてを一枚の画面や合格率で済ませず、同じ一件を追える記録へ結び付けます。