社内ツールのテスト手順｜空欄・重複・日付違い・途中停止で集計結果を照合する

生成AIにコードを書いてもらい、CSVを読み込んで部門別に集計する社内ツールができた。自分のサンプルでは動くが、同僚に配ってよいか分からない。この段階で試したいのは、正常な入力に加え、空欄・重複・想定外の形式・途中停止です。入力を意図的に変え、集計値と保存されたデータを照合すると、配る前に壊れ方を確かめられます。

非エンジニアの社員でも、普段の仕事で「この受付は数えてよいか」「この数量は確定しているか」を判断しているはずです。その判断を、入力と期待する結果の組にします。上長に見せる材料も、成功した画面に加えて、何を入力すると何が残ったかを示す記録にしましょう。

テスト用の受付簿と、手計算した正解の集計表を分ける

ここでは、受付番号・受付日・部門・数量を持つCSVから、部門ごとの受付件数と数量合計を出すツールを例にします。以下は説明用の架空データを使う確認方法です。実在する企業の導入事例ではありません。

最初に正常なCSVを作り、表計算や手計算で正解を別に用意します。たとえば、総務の受付が二行で数量が二と三、営業の受付が一行で数量が四なら、総務の数量合計は五、営業は四です。合計だけでなく、どの受付番号を数えたかも控えます。誤った行を足し、別の行を落として、偶然同じ合計になる場合を区別するためです。

次に「ファイルを開く→各列を読み取る→対象行を集計する→結果を保存する」と処理をたどります。前の工程がどの値を次へ渡すかを言葉にしてください。部門が不明な行を除くのか、エラーとして全体を止めるのかで、正しい件数は変わります。まだ決まっていない扱いは、コードを修正する前に業務担当と上長で決めます。

MicrosoftのTest Studioの説明でも、各テストケースに期待する結果を設定し、実際の結果と比べることが示されています。コードを作ったAIに「これで正しいか」と聞く前に、人が判定できる正解を置くのが出発点です。

試験用の保存先を用意し、元のCSVと正解の表をツールが上書きできない場所に残します。外部へ通知する機能があるなら、送信先も試験用に切り替えます。試験を繰り返すたび、前回の出力を片付けるか識別できる名前を付け、今回の結果と混ぜないようにします。

空欄は消去とスペース、重複は同じ受付番号で試す

異常な入力は、正常なCSVを複製して一か所ずつ変えます。日付も部門も数量も同時に変えると、何に反応したのか切り分けられません。ファイル名に変更内容を付け、使ったCSVをそのまま残してください。

必須欄を空にしたとき、欠けた行が黙って消えないか

受付番号を消す、部門を消す、数量を消す操作を別々に試します。さらに、空のセルと、半角・全角スペースだけのセルも分けます。期待するのは、入力の不備が分かり、未確定の値を勝手に補わないことです。数量の未入力をゼロとして扱うかは業務のルール次第なので、空欄とゼロを同じにしてよいか先に決めておきます。

確認するのは警告文だけではありません。不備のある行の番号を示せるか、正常な行は保存されたか、不備のある行は集計から除かれたかを見ます。全体を止める設計なら保存先が変わっていないことまで確かめます。「出力が空だった」ときも、受付がなかったのか、読み取りに失敗したのかを見分けられる表示が必要です。

同じ受付を再投入したとき、件数や数量が増えないか

同じ受付番号の行をCSV内に複製し、取り込んでみます。続いて、正常なCSVを取り込んだあと、同じファイルをもう一度読み込ませます。ファイル内の重複と、過去に保存された受付との重複は分けて試してください。受付番号が同じでも数量が異なる場合に、更新・拒否・警告のどれにするかも確認します。

保存ボタンを続けて押す操作も、試験用の場所で確かめます。画面では一度だけ完了と表示されても、保存先の同じ受付番号が増えていれば不合格です。逆に、数量が同じという理由だけで別の受付番号まで消していないかも見ます。何を同じ受付とみなすかを決め、その単位で元データと結果を突き合わせましょう。

日付・数量・受付番号の表記を変え、値が化けないか見る

形式違いの試験では、見慣れない書式をすべて拒否すればよいとは限りません。受け付ける表記と、拒否する表記を分けて決めます。どちらでもよい状態のまま試すと、出た結果に合わせて正解を後付けしてしまいます。

• 日付：ハイフン区切りとスラッシュ区切り、存在しない月日、日付以外の文字を別々に入れる。受理した場合は、出力された年月日が入力の意味と一致するかを見る。
• 数量：整数、小数、負数、桁区切りのある数値、単位の文字を付けた数値を試す。許可しない値は、その行を特定できる形で止められるかを見る。
• 受付番号：先頭にゼロのある番号を入れる。出力と保存先の両方で、桁数と文字列が保たれているかを見る。
• CSVの列：列順を変える、必須列を外す、余分な列を加える。別の列を数量として読まず、仕様どおりに受理または拒否するかを見る。

たとえば受付番号が文字列なら、先頭のゼロが消えた時点で数量合計が合っていても不合格です。また、一部の行だけ読み飛ばす設計なら、受け付けた行と拒否した行を合わせて元の入力行に対応付けられる必要があります。合計が小さいという結果だけで、読み飛ばされた行を探させないようにします。

境界にある値も試しましょう。数量に上限を設けているなら上限ちょうどとそれを超える値、対象期間があるなら開始日・終了日とその前後を用意します。先に定めた条件で処理が分かれるかを確かめます。初めから大量の実データを投入するより、小さく違いが分かる入力で、受理した理由と拒否した理由を追える状態を作ります。

取込途中で画面を閉じ、再実行前後の保存先を照合する

次は、正常な入力を使って処理途中の状態を確かめます。試験用の保存先で取込を開始し、処理中に画面を閉じる操作を試してください。ツールに中止機能がある場合は、その操作でも別に試します。画面を閉じたことと、保存処理が止まったことを同じ扱いにせず、保存先や処理の記録で実際の状態を見ます。

再実行する前に、保存済みの受付番号と未保存の受付番号を書き出します。すべて未保存、すべて保存、一部だけ保存では、その後に確かめることが異なります。一部だけ保存される設計なら、処理済みの行を飛ばすのか、元に戻してやり直すのかを確認します。状態が分からないまま再実行して、合計だけを見る試験にしないことが大切です。

同じCSVで再実行したあと、元の受付番号が欠けていないか、同じ番号が二重に残っていないか、数量合計が正解と一致するかを照合します。エラー後に別の正常なCSVを続けて投入し、前のエラー表示や集計値が残らないことも試します。途中状態を確かめる表示や記録がなく、処理が終わったか判断できない場合は、その確認方法を作るところから修正を依頼します。

海外の開発事例として、Replitは2025年12月15日公開のテスト機構の解説で、ブラウザーの操作とコード実行を組み合わせ、データベースの読み取り専用の照会や、画面側・サーバー側のログも確認に使う仕組みを説明しています。ここから取り入れたいのは、見た目と保存状態を別々に確かめる視点です。この海外ベンダーの実装例は、日本企業向けの制度上の合格基準を示すものではありません。

失敗したファイルを残し、修正後は正常なファイルも再試験する

不具合を見つけたら、「うまく動かない」で済ませず、使った版、入力ファイル、操作、期待した結果、実際の結果、保存先で確認した内容を一組で残します。たとえば「同じCSVを再取込したところ、受付番号が二重に保存された」と書けば、どの操作を再現すればよいかが伝わります。AIに修正を依頼するときも、社内で利用を認めた試験データと、この差分を渡します。

修正後は、失敗したCSVを変えずに再試験します。そのうえで、最初の正常なCSVと、すでに合格した空欄・重複・形式違いのケースも通します。重複を防ぐ修正で正しい受付まで除かれる、といった別の不具合が起きていないかを確かめるためです。結果は「合格」「不合格」「未確認」を分け、どの版を試したかを記録してください。

確認方法が固まった反復作業は、自動テストに移す候補になります。前述のMicrosoftの説明も、自動化に完全に依存せず手動テストを併用することを勧めています。実行の仕組みを選ぶ段階では、操作の記録・再実行と自動修復の確認点を整理できます。期待結果までツールの現在の出力に合わせて書き換えないようにしましょう。

上長が見るべきなのは、試験した範囲と、残っている不合格・未確認です。欠落や二重保存が残る場合は、配布を保留して修正後に照合し直します。作者の異動に備えて見本を渡す場面では、入出力の見本と実行条件を引き継ぐ方法へつなげられます。試験を継続する役割や教育まで考える視点は、業務設計と改善を社内で続ける体制づくりにも関係します。

AI化・効率化を進めるときは、まず仕事の手順と工程間のつながりを言葉にし、人が確かめられる正解を置きます。そこから空欄、重複、形式違い、途中停止を試し、修正と再試験を重ねます。作った社員自身が、どの入力で何が残るかを説明できることが、次の利用者に渡す前の具体的な確認になります。