初めての結合テスト｜テストケース作成と実施で学んだこと

はじめに

みなさんこんにちは！
第一開発事業部の德永です。
初めてテスト仕様書の作成と結合テスト実施の業務を担当させていただいたので、実際にやってみて実感したことや難所、その解決法などを記録用としてまとめていきたいと思います。

目次

1. 結合テストとは
2. 工夫したテストケース作成方法
3. テストケースを作成する上で苦戦したこと
4. 実際にやってみて実感した「結合テスト」の難しさ
5. 次回へのアクション：こうすればもっと良くなる！
6. 終わりに

1. 結合テストとは

結合テスト（IT：Integration Test）とは、単体テストで確認した個々の機能を組み合わせて、システム全体として正しく動くかを確認する工程のことです。

今回の私の業務に当てはめると、「作成したAPIが単体で動くか」ではなく、「APIが叩かれた後にLambdaやSQS、S3といったAWSの各リソースと正しくデータの受け渡しができているか」を確かめるのが目的でした。

2. 工夫したテストケース作成方法

記載項目としては、1ケースにつき以下の5つを用意しました。

• 概要:どのような検証をするのか（例：特定パラメータを指定して全項目の取得確認）
• 詳細:具体的なテスト概要（例：期待通りのレスポンス（配列）が返却されること、ERRORログが出力されていないこと）
• 前提条件:テストをする前に必要な前提条件（例：テストデータがDBに作成済みであること）
• 手順:テスト手順（例：対象APIにリクエストを送信 → レスポンス確認 → CloudWatch Logsでエラーログの有無を確認）
• 合格基準: (例: レスポンスが期待値と完全一致し、ERRORログが出力されていないこと）

テストケースを作成する上で工夫したこと

今回が初めてのテストケース作成だったため、いきなり手順や合格条件を書き始めるのではなく、まずはテスト観点（何を検証するのか）の洗い出しを行い、観点レビューをいただいてから詳細を記載するようにしました。

なぜ観点レビューから始めたのか

一貫して書かずにステップを分けた理由は、何を網羅すべきか自信がなかったためです。どの程度の粒度でテストケースを書くべきかの基準を知りたかったので、先に観点レビューを挟んだことで基準が明確になりその後の作業をスムーズに進めることができました。

目標としたのは、「テスト実施者が手順と合格基準を見たときに、迷わず実施できる状態」です。

その上でテストケースの詳細を書く際は仕様書を起点に『何が正常な挙動か』を確認しながら進めるようにしました。

3. テストケースを作成する上で苦戦したこと

次に直面した壁についてご紹介したいと思います。

テストで網羅すべきケースや前提条件などはスムーズに理解できたものの、合格条件を書く際にログ出力の有無やエラー判定を間違えてしまうことが多かったです。

例えば異常系テストでLambdaのログが出ることが正しいのにログが出ないと記載してしまったり、逆にログが出る前に処理が止まるのが正解なのに「ERRORログが出ること」と書いてしまったり……。

出力のタイミングやAWSサービスの繋がりへの理解不足を痛感しました。
実装したAPI単体の動きは掴めていても、その裏側にあるシステム全体の処理の流れがまだ自分の頭に入っていなかったことが原因だと思います。

気付いたこと

「ログにERRORが出る」のか「そもそもログが出る前にプロセスが落ちる」のか🧐

これはシステムの構造を理解していないと正しく定義できない部分なのでは？と自力での構造理解や調査にかなりの時間を費やしてしまいました。

ですが、後になって「そもそもテストケースって仕様書を元に作るものだよね……？」という当たり前のことに気づきました。

遠回りしてしまいましたが、まずは仕様書に立ち返って冷静に「何が本当に正常な挙動なのか」を判断することが一番の近道だと学ぶことができました。

4. 実際にやってみて実感した「結合テスト」の難しさ

API単体を動かすのはそこまで難しくありませんでしたが、結合テストでは複数のサービスが組み合わさるため実施中にも苦戦することがありました。

特に反省したのは、「合格条件と完全一致できているか」を確認する視点が抜けていたことです。

リクエストも正常に飛び、ログも出ているので「合格」だと思って進めていたら、実はレスポンスの内容が期待値とわずかに誤差があった……という手戻りが発生してしまいました。

期待レスポンスは、「このデータが返却メッセージとして返ってきますよ」とあらかじめ確定させているものです。
そのため、実際の結果と1文字残らず完全一致させなければなりませんでした。

テストは「正常に動いた」を基準とするのではなく、「合格条件を全て満たして初めて合格」を基準として確認を行うということを今回のテスト実施で学ぶことができました。

バグ調査で意識したこと

エラーが出るとつい焦ってしまいますが、まずは落ち着いて以下のステップで問題の切り分けを行うようにしました。

1. 自分の操作ミスを疑う： リクエスト内容やURLに間違いがないか再確認（うっかりミスは意外と多いです！）。
2. ログを確認する： ネットワークのタイムアウトか、権限不足か、実装ミスなのか。

エラーにもいろいろな種類があるので自分で実装コードを修正できるものもあれば、インフラ側の設定など自分だけでは対応できないものもありました。

ここでは一人で全てを解決しようとせずにどこでどんな問題が起きているか、またどのように修正したら直りそうかという予測を上長に報告することを心がけました。

コミュニケーション回数を以前より増やしたことで「これは自分がやるべき修正なのか、それとも誰かに依頼すべきなのか」という迷いがなくなったと感じています。もし個人で修正できない範囲であれば早めに修正依頼を出し、その待ち時間に他のテストを進める。というように、タスクを整理しながら効率的に作業を進めることができました。

以前までは「担当範囲は全て自分で解決しなきゃ！」という考えがあり、一人で抱え込んで焦ってしまうことが多かったです。

ですが、開発はチームで行なっているものなので自分なりの考えを共有した上でチームを頼るという内面的な成長も徐々に感じることができました。

修正案を提案したりエラー箇所を指摘することに自信がありませんでしたが、「調べた結果こういう予想をしました！」と報告する勇気を持ったことでいち早く自分の中の悩みやモヤモヤしている部分を解消し、頭を切り替えて次の作業に移行できるようになりました。これは私にとって本当に良い経験になりました！

5. 次回へのアクション：こうすればもっと良くなる！

今回の経験を踏まえ、次は以下の2点を意識したいです。

• テストケースを書く前に図解する！
  → 仕様書の構成図を見るだけでなく、自分で「データの流れ」や「リソースの役割」を図に描き起こしてみます。そうすることで、理解が曖昧な部分がはっきりし合格条件も書きやすくなるはずです。
• 仕様書を読む段階から「リソースの繋がり」を意識しておく！
  → これまではコードを動かすことに集中していて、リソース間の繋がりまで意識が向いていませんでした。これからは仕様を把握する段階から『各リソースにどんな変化が起きるか』を頭に入れておくことで、テストケース作成をよりスムーズに進められるようにしたいです。

6. 終わりに

初めてテスト仕様書の作成から実施までを一通り経験してみて、一番の学びはテストは単なる確認作業ではなく、バグの洗い出しであると実感できたことでした。

最初は手順通りに動くことを確認することに必死でしたが、合格条件の不備やデータのズレに直面する中で、「どうすれば不具合を見逃さないか」「どこに不整合が隠れているか」という視点を持つ大切さに気づけました。

「処理の流れとリソースの繋がりを意識する視点」を今後の開発にも活かして、より品質の高いものづくりができるように頑張ります。

最後まで読んでいただき、ありがとうございました！