システム開発のテスト。発注者は業務の失敗を確かめる

「テストは完了し、全項目が合格しました」という報告だけでは、発注者はシステムの品質を判断できません。確認した機能、使ったデータ、試していない条件が分からなければ、自社の業務が止まらないか読めないからです。

システム開発のテストでは、開発会社がプログラムや連携の動作を確かめます。発注側は、自社の利用者が実際の業務を終えられるか、入力を間違えた時や外部サービスが止まった時に業務へ戻れるかを確かめます。

成功する操作だけでは、テスト完了と判断できません。権限の違い、入力ミス、数字の不一致、連携停止を含む業務の失敗を先に出し、開発中に直せる時期から発注側も確認します。

システム開発のテストは、開発中の品質確認として使います

テストの目的は、最後に合格印を付けることではありません。仕様の読み違い、設計の抜け、実装の誤りを開発中に見つけ、修正後の動作を確かめることです。発注側が動く画面を早めに見れば、業務の説明が足りない箇所も完成前に見つけられます。

開発中のテストと最終検収は役割が異なります。開発中のテストは、不具合や要件の抜けを見つけて修正へ戻す品質確認です。最終検収は、納品物が契約と受入条件を満たすかを発注側が判定し、合否を記録する手続きです。

開発会社のテストに合格しても、発注側の検収が自動で終わるわけではありません。反対に、発注側が開発途中の画面を確認しても、納品版への最終的な受入判断にはなりません。検収期間、対象となる版、合否の伝え方は、システム開発の検収で確認する内容へ分けて書いています。

発注者が開発中から参加する理由は、コードを検査するためではありません。開発会社が知らない業務の例外、利用者の権限、帳票の数字、外部サービス停止時の手順を渡すためです。発注側が業務上の期待結果を説明し、開発会社が再現可能なテストへ落とします。

テストを開発会社だけへ任せると、仕様書に書かれた正常な操作は確認できても、仕様書へ十分に書けなかった現場判断が残ります。発注側だけでテストすると、内部処理や連携箇所の確認が足りません。両者は同じ作業を重ねるのではなく、技術と業務を分けて持ち寄ります。

単体・結合・システムテストは、確認範囲で読み分けます

単体テストは、計算や入力判定など、プログラムの小さな単位が期待どおり動くかを確かめます。結合テストは、画面から保存処理へデータが渡るか、外部サービスと正しく送受信できるかなど、複数の部品をつないで確かめます。システムテストは、利用環境に近い構成でシステム全体が要件を満たすかを確かめます。

名称を覚えるだけでは、発注判断に使えません。会社や契約によってテスト名が指す範囲は変わるため、報告書では確認した機能、環境、データ、期待結果を読みます。「結合テスト済み」という一行より、注文登録から外部サービスへの送信まで確認した、と対象範囲が書かれているほうが判断できます。

発注者がテストコードの細部を読む必要はありません。重要な業務要件がどのテスト項目に対応し、どの版と環境で実行され、未実施や不合格が何件残っているかを確認します。未実施の項目には、実行できなかった理由、担当者、次の確認日が必要です。

テスト完了報告では、合格数だけでなく対象外も読みます。データ移行、権限、帳票出力、通知、外部連携、障害からの復旧が別工程になっている場合は、誰がいつ確かめるかを工程表へ戻します。対象外のまま本番公開日だけが近づく状態を避けます。

テストの時期は開発方式によって変わります。小さな範囲を順に作る進め方では、完成した範囲ごとに業務確認を繰り返します。工程ごとに成果物を固める進め方では、要件定義時にテスト条件を作り、後半のテスト工程でまとめて照合します。アジャイルとウォーターフォールを発注者の責任で選ぶ方法も踏まえ、発注側が画面を見る時期を契約前に決めてください。

発注者のテストは、実際の業務シナリオから作ります

業務シナリオは、機能名ではなく仕事の開始から終了までを書きます。誰が何を受け取り、どの画面へ入力し、誰が承認し、どの帳票や外部サービスへ結果が渡れば業務が終わるのかをつなぎます。画面単位のテストだけでは、画面をまたぐデータの欠落や二重処理を見落とします。

最初に、実際の利用者が通常業務を通します。経営者や開発担当者だけで操作せず、日常的に受付、承認、訂正、出力を担う社員へ参加してもらいます。業務用語の表示、操作の順番、確認に必要な情報が現場の手順と合うかを見ます。

次に、権限が強い利用者と弱い利用者を分けます。許可された人が処理できるだけでは足りません。権限のない人が顧客情報を閲覧できないか、承認できないか、他部門のデータを書き換えられないかも確かめます。退職者や異動者の権限を外した後の動作も業務手順へ含めます。

入力ミスは、現場で実際に起こり得る形を使います。必須項目の空欄、同じデータの重複、日付の前後関係、形式の違う文字、上限を超える数量を入力し、保存を止めるのか、警告するのか、修正画面へ戻すのかを確認します。エラーメッセージが出るだけでなく、入力途中の内容を失わず業務へ戻れるかも見ます。

外部連携では、正常に送れる場面だけを確認しません。接続先が応答しない場合、送信途中で時間切れになった場合、送信結果を受け取れない場合に、二重登録を防げるかを確かめます。自動で再送するのか、担当者が管理画面から再開するのか、外部サービス側の記録と照合するのかを決めます。

重要な数字は画面の見た目で判断しません。実際の業務で承認済みの元資料を使い、入力値、明細、小計、税、合計、外部システムへ渡った数字を順に照合します。端数処理や取消し後の金額も、自社の会計・請求ルールに合う期待値を発注側が渡します。

要件定義の段階で業務シナリオと期待結果を書けば、開発会社は実装前からテストへ使えます。経営者が要件定義で受入条件を決める方法を参照し、作る機能だけでなく、失敗時に業務へ戻る条件も仕様へ入れてください。

テストデータと担当者は、実装が終わる前に決めます

テストデータは、開発会社が適当に作った名前と数字だけでは足りません。自社で実際に扱う項目の組み合わせ、空欄になり得る項目、過去データに残る表記の違い、承認や取消しが必要な状態を含めます。通常のデータと失敗を起こすデータを分け、期待する結果も対にして記録します。

本番データを検証環境へ移す場合は、コピーする前に利用権限、個人情報、取引先との取り決めを確認します。実在する顧客情報を使う必要がなければ、項目の関係を保った検証用データを用意します。誰がデータを作り、誰が内容の妥当性を承認し、テスト後に誰が削除するかまで決めます。

開発会社は、検証環境、テスト手順、実行結果、画面やログの証拠を用意します。発注側は、実際の業務手順、期待する数字、参加する利用者を用意します。事業責任者は、見つかった問題が公開を止めるのか、修正期限を置いて進められるのかを判断します。

テスト担当者の予定は、開発完了後に探し始めません。締め処理や繁忙日を知る社員、権限ごとの操作を担う社員、重要数字を承認する社員の時間を工程表へ入れます。担当者が休んだ場合の代理も置き、回答待ちで修正が止まらないようにします。

実行結果には、テストした日、環境、システムの版、担当者、入力データ、期待結果、実際の結果、証拠を残します。同じ項目名でも版が違えば結果を引き継げません。開発会社から新しい版が届いたら、修正対象と確認が必要な周辺機能をひも付けます。

不具合には業務への影響を書きます。「重要」「軽微」だけでは、発注側と開発会社で意味がずれます。顧客が手続きを完了できない、金額が一致しない、権限のない利用者が閲覧できる、担当者が手作業で回避できる、という業務上の状態を記録し、修正順を決めます。

修正完了の連絡を受けたら、同じ入力で再確認します

開発会社から「修正しました」と連絡が来ても、課題をすぐ完了へ移しません。不具合を見つけた版、操作、入力、期待結果、実際の結果を残し、修正版で同じ操作を行います。修正前に失敗した場面が期待どおりになった証拠を付けて再確認を終えます。

修正箇所だけが動けば十分とも限りません。金額計算を直した場合は、明細、合計、帳票、外部連携へ同じ数字が渡るかを見ます。権限判定を直した場合は、許可された利用者の操作まで止めていないかを見ます。開発会社には、修正が影響する範囲と追加で実行したテストを説明してもらいます。

再確認で別の問題が見つかった場合は、元の不具合と分けて記録します。原因が同じか、別の仕様不足かを開発会社に調べてもらい、修正する範囲と日程を更新します。課題番号を分けても、同じ版、業務シナリオ、公開判断との関係は追える状態にします。

公開日が近づくと、未解決の問題を残して進む判断も出ます。発注側は、影響する利用者、失敗した際の回避手順、修正予定日、監視する担当者を確認します。顧客情報の漏えい、重要数字の不一致、業務を完了できない問題を、件数が少ないという理由だけで後回しにしません。

テスト完了報告を受け取った日に、自社で実際に処理した業務記録も一つ開いてください。業務の開始から終了までを報告書のテスト項目へ対応させ、権限違反、入力ミス、外部連携停止、重要数字の照合が含まれるか確認します。

対応する項目がなければ、業務記録からテストシナリオを作り、利用者、テストデータ、期待結果、担当者、確認日を開発会社と決めます。不合格項目には修正版の受領日と再確認日を置きます。

テスト完了報告を読む目的は、専門用語を採点することではありません。自社の業務が成功した時だけでなく、失敗した時にも止まらず戻れるかを、開発中から確かめることです。業務の失敗を説明できる発注者なら、開発会社の技術テストを事業上の品質判断へつなげられます。