はじめに
詳細設計書の作成と、それに従ったプログラミング（コーディング）が完了したら、いよいよシステム開発の後半戦、「テスト工程」に突入します。
情シス配属になったばかりの初心者や、他部署からDX推進部門へ異動してきたミドル層の方の中には、「プログラムが書けたなら、もう完成でしょ？」と思う方もいるかもしれません。 しかし、メーカーのシステム開発において「テストをしていないプログラムは、存在しないのと同じ（＝絶対に本番で使ってはいけない）」という厳しい鉄則があります。
テスト工程にはいくつかの段階がありますが、今回は情シスや開発者がメインで実施する「単体テスト（UT）」と「結合テスト（IT）」について、それぞれの具体的な内容と「現場で絶対に意識すべきリアルな掟」を解説します。
単体テスト（UT：Unit Test）
具体的に何を実施するのか？
単体テストは、プログラムの「最小単位（部品ごと）」が、詳細設計書通りに正しく動くかを確認するテストです。現場ではよく「UT（ユーティー）」と呼ばれます。
- 機能のテスト： 「金額欄に100と入力して計算ボタンを押したら、消費税込みの110が表示されるか」
- 異常系のテスト（これが超重要！）： 「金額欄に『あいうえお』という文字を入れたら、システムが落ちずに『数値を入力してください』とエラーメッセージが出るか」「マイナスの数値を入れたらどうなるか」
このように、部品（1つの画面、1つのボタン、1つの計算ロジック）ごとに、正しいデータと意地悪なデータをひたすら入力して結果を確認します。
現場で意識すべきこと：テストは「エビデンス（証跡）」が全て！
単体テストにおいて、情シスの現場で最も重要視される掟があります。 それは「テストを実施したというエビデンス（証跡）を必ず残すこと」です。
「画面で動かして計算結果が合っていたからOK」と、頭の中だけで完結させてはいけません。 テストを行う前の画面、ボタンを押した後の画面、データベースに正しく保存された結果などを、ひたすらスクリーンショット（画面キャプチャ）に撮り、Excelなどのテスト仕様書に貼り付けて保存します。
なぜこんな面倒なことをするのでしょうか？ それは、システムをリリースした数ヶ月後にバグが発覚した際、「開発時点でのテスト漏れだったのか、それともリリース後の別の要因で壊れたのか」を切り分けるための、唯一の命綱（保険）になるからです。「テストしたはずです！」という口頭の主張は、現場では一切通用しないと心得ましょう。
結合テスト（IT：Integration Test）
具体的に何を実施するのか？
単体テストで「部品」が正常に動くことが確認できたら、次はそれらの部品を「繋ぎ合わせて（結合して）」正しく動くかを確認します。現場では「IT（アイティー）」と呼ばれます。
- 画面間の結合： 「検索画面で選んだ商品のデータが、次の詳細画面に正しく引き継がれて表示されるか」
- システム間の連携（インターフェース）： 「今回作った『在庫管理システム』から出力したデータを、既存の『工場生産システム』に読み込ませた時、エラーにならずに処理されるか」
単体ではうまく動いていた部品も、繋ぎ合わせると「データの受け渡しの形式が違った」「タイミングがズレてエラーになった」という不具合が必ずと言っていいほど発生します。
現場で意識すべきこと：「他システムへの影響」を最警戒せよ！
結合テストに入ると、確認の難易度がグッと上がります。DX担当者や情シスがここで特に警戒すべきは、「既存システムや他部署の業務への影響」です。
例えば、新しいシステムから既存のシステムへデータを連携するテストを行う際、間違って「本番で稼働しているシステム」にテストデータを流し込んでしまうという事故が稀に起こります。 もし工場の基幹システムに架空の注文データが混入したら、大混乱（大炎上）を引き起こしてしまいます。
結合テストを行う際は、「今テストしている環境はどこか（本番環境とは完全に切り離されているか）」「テストで使ったダミーデータが、他の業務システムに悪影響を及ぼさないか」を、指差し確認レベルで慎重に行う必要があります。システム間の繋がりを俯瞰して見ることができるかどうかが、プロの情シスとしての分かれ道です。
テストデータの準備という「見えない重労働」
単体テスト・結合テストに共通して、現場の担当者を最も悩ませるのが「テストデータの作成」です。
「1万件のデータを取り込む結合テスト」をするためには、当然「1万件分のダミーデータ（CSVなど）」を用意しなければなりません。しかも、ただ適当な文字を並べるだけでなく「この条件を満たすデータ」「わざとエラーになるデータ」など、バリエーションを持たせる必要があります。
このテストデータ作りのために、Excelのマクロを組んだり、専用のツール（スクリプト）を書いたりすることもしばしばです。テスト工程は、単に画面をポチポチ押すだけではなく、「どうやって効率よく、網羅的にテストできる状態を作るか」という工夫が試される、非常に知的な作業なのです。
まとめ
システム開発におけるテスト工程は、地味で根気のいる作業の連続です。
- 単体テスト（UT）： 部品ごとの動作確認。異常系の確認と「エビデンス（証跡）の保存」が命！
- 結合テスト（IT）： 繋ぎ合わせた時の動作確認。他システムへの影響を警戒し、連携のズレを炙り出す！
情シス部門やDX担当者は、「動くプログラムを作る」こと以上に、「このシステムが絶対に業務を止めないことを証明する」ことに大きな責任を持っています。 「ここまでテストしたんだから、絶対に大丈夫！」と自信を持って言えるだけの証跡と品質を積み上げ、次なる最終関門「ユーザ受け入れテスト（UAT）」へとバトンを繋いでいきましょう！
コメント