結合テストの観点の洗い出し方 6つの切り口とテストケースへの落とし込み手順を解説

テストケースを書き始めたものの、気づけば単体テストと似たような項目が並んでいる。レビューで「この観点が抜けている」と指摘され、後から大量に追加することになった。結合テストの準備では、こうした事態が繰り返し起こります。

原因は、テストケースから書き始めていることにあります。先に洗い出すべきなのは「何を確認するか」という観点であり、ケースはその後に導き出すものです。順序を逆にすると、思いついた順に項目が並び、抜けているかどうかを判断する基準すら持てません。

本記事では、テスト観点という考え方の整理から、洗い出しに使う資料、結合テスト特有の6つの切り口、テストケースへの落とし込み方、抜け漏れが起きる原因、そして観点を組織の資産にする方法までを順番にまとめます。

確認したいポイント	結論	詳細
テスト観点とは何ですか？	何に着目して確認するかの切り口	テストケースの前段にあたる着眼点で、観点から条件、条件からケースへと段階的に具体化します。
結合テスト特有の観点は？	つながる部分に着目する	遷移、データ受け渡し、タイミング、権限、異常系、外部連携の6つで整理すると漏れにくくなります。
洗い出しのやり方は？	結合点と観点のマトリクス	設計書から結合点を列挙し、各点に6つの切り口を当てて表を埋めると、抜けが目に見える形になります。
抜け漏れを防ぐには？	観点リストを資産化する	すり抜けた不具合を観点として追加し、次のプロジェクトで使い回す仕組みが最も効果的です。

この記事でわかること

• テスト観点・テスト条件・テストケースの違いと、観点から始めるべき理由
• 結合テストで押さえるべき6つの観点の切り口と、それぞれの具体例
• 結合点と観点のマトリクスから、テストケースへ落とし込むまでの手順
• 同値分割や境界値分析など、値の決め方に使えるテスト技法の考え方
• 抜け漏れが起きる典型パターンと、観点リストを資産化する方法

▼ 開発・品質管理の業務をどこまで効率化できるか整理したい方へ 生成AIを使ったドキュメント作成支援や業務自動化の進め方、支援内容、導入までの流れをまとめた資料をご用意しています。検討の初期段階でも構いませんので、まずは全体像の把握にご活用ください。 ＞ 資料請求はこちら

テスト観点とは何を指すのか

洗い出しの手順に入る前に、言葉の整理をしておきます。観点、テスト条件、テストケースは段階の違う概念で、ここを混ぜたまま作業を始めると議論がかみ合いません。

観点・条件・ケースの違い

テスト観点は、「何に着目して確認するか」という切り口です。「権限による表示の差異」「データ受け渡し時の型変換」といった、抽象度の高い着眼点を指します。この時点では具体的な操作や値は決まっていません。

テスト条件は、その観点を特定の対象に当てはめたものです。「一般ユーザーで受注一覧を開いたときの表示項目」のように、対象と状況まで絞り込まれます。

テストケースは、条件に具体的な値と手順、期待結果を与えたものです。観点から条件へ、条件からケースへと段階的に具体化していく流れを意識すると、どの段階で抜けが起きたのかを特定できます。

なぜケースではなく観点から始めるのか

いきなりケースを書くと、書いた本人の経験の範囲に内容が閉じます。抜けているかどうかを判断する基準がないため、レビューでも「なんとなく足りない気がする」という曖昧な指摘しか出せません。

観点から始めると、切り口の一覧という形で網羅性を確認できます。「この結合点では権限の観点を見ていない」という具体的な指摘ができるようになり、レビューの精度が上がります。

また、観点は他のプロジェクトでも使い回せます。ケースは対象システムごとに作り直しですが、観点は組織の資産として積み上がっていく点も大きな違いです。

単体テスト・システムテストとの住み分け

結合テストの観点を考えるうえで重要なのが、前後の工程との線引きです。単体テストは部品ひとつの内部的な正しさ、結合テストは部品どうしのつながり、システムテストは全体が要件を満たしているかを見ます。

入力チェックのロジックが正しく動くかは単体、その入力値が次の画面や次のシステムへ正しく渡るかが結合、業務全体が要件どおりに回るかがシステムテストの領域です。

この線引きを曖昧にすると、同じ確認を3回繰り返すことになります。観点を洗い出す段階で「これは結合でしか確認できないか」を自問する習慣をつけてください。

内部結合と外部結合を分けて考える

現場によっては、結合テストを2段階に分ける整理もよく使われます。自システム内のモジュール間をつなぐ内部結合と、他システムや外部サービスとつなぐ外部結合です。

両者は着目点が異なります。内部結合では画面遷移やデータの引き継ぎが中心になるのに対し、外部結合では通信の失敗、応答の遅延、相手側の仕様変更といった、自分たちで制御できない要素への備えが焦点になります。

プロジェクトによって呼び方も区切り方も違うため、最初にどこまでを結合テストと呼ぶのかを合意しておくことが、観点の粒度をそろえる前提になります。

洗い出しのインプットになる資料

観点は頭の中から絞り出すものではなく、既存の資料から導き出すものです。根拠のある観点だけを並べれば、レビューでの説明もしやすくなります。使う資料を4つに整理します。

基本設計書と画面遷移図

結合テストの根拠になるのは、主に基本設計書です。画面遷移図からは遷移の観点、機能一覧からは機能間の連携、帳票定義からは出力の観点が導き出せます。

画面遷移図を見るときは、線が引かれている箇所だけでなく、引かれていない経路にも注目してください。ブラウザの戻る操作や、直接URLを入力した場合の挙動は、設計書に明記されていないことが多く、抜けやすい観点です。

インターフェース仕様とAPI定義

システム間や画面と裏側の処理をつなぐ部分の仕様書は、データ受け渡しの観点を洗い出す最大の情報源です。項目名、型、桁数、必須か任意か、コード値の定義がここに書かれています。

特に注目したいのは、型や桁数が送り側と受け側で食い違っていないかです。設計書を読み比べる段階で不一致が見つかれば、テストを実施する前に修正できます。

エラー時の応答仕様も確認します。正常応答しか定義されていない場合、異常系の観点を立てる根拠がないことになるため、設計側への確認が必要になります。

業務フローとユースケース

業務の流れに沿ってテストする方針なら、業務フロー図がそのままシナリオの骨格になります。顧客の業務がどう進み、その中でどの画面と帳票が順に使われるのかを追うことで、実際の利用に近い観点が出てきます。

ユースケースからは、主となる流れと代替の流れ、例外の流れが読み取れます。代替と例外の記述は、異常系の観点を立てる際の直接の材料になります。

過去の不具合記録

見落とされがちですが、効果が非常に高いのが過去の記録です。以前のプロジェクトで結合テストをすり抜けた不具合は、同じ構造の抜けが繰り返される可能性が高いためです。

「マスタを更新したら過去のデータの表示が変わった」「同時に操作したら片方の更新が消えた」といった具体的な事例を観点として蓄積しておけば、次からは意識的に確認できます。

▼ テスト設計の進め方からご相談いただけます 観点の粒度、工数のかけどころ、レビュー体制の作り方など、現場の課題に合わせて実務目線でご提案します。 ＞ 相談予約はこちら

結合テストの観点を6つの切り口で洗い出す

ここからが本題です。結合テストの観点は「つながり方の種類」で分類すると漏れにくくなります。実務で使える6つの切り口を、具体例とあわせて見ていきます。

切り口1：画面間・機能間の遷移

最も基本的な切り口です。正常な遷移だけでなく、戻る、キャンセル、ブラウザバック、直接URLを入力した場合まで含めて観点を立てます。

遷移時に前画面の入力値が引き継がれるか、逆に引き継がれてはいけない値が残っていないかも重要です。同じ画面でも、どこから遷移してきたかによって表示や動作が変わる設計では、遷移元ごとに観点を分けます。

多段階の画面をまたぐ処理では、途中で離脱した場合の状態も確認対象です。中途半端なデータが残るのか、破棄されるのかは、設計書に書かれていないことが多い部分です。

切り口2：データの受け渡しと整合性

画面から処理へ、処理からデータベースへとデータが渡る過程で、桁数、型、文字コード、日付形式、数値の丸め方が保たれているかを見ます。単体では各層が正しくても、境界で欠落や変換が起きます。

登録した内容が一覧や帳票に正しく反映されるか、更新や削除が関連するデータに波及するかも観点です。マスタを更新したときに、過去のトランザクションデータが影響を受けないかは特に見落とされます。

文字種の扱いも観点に含めてください。全角と半角、環境依存文字、絵文字、改行を含む入力が、どの層でどう扱われるか。ここは実際に流してみないと分からない部分です。

切り口3：タイミングと順序

見落とされやすいのが時間軸の観点です。バッチ処理とオンライン処理が重なった場合、日付をまたいだ場合、月末や年度末といった条件を明示してケースを作ります。

複数のユーザーが同じデータを同時に操作したときの挙動も、結合テストでしか確認できません。排他制御が設計どおりに働くか、後勝ちになるのか、エラーになるのかを確かめます。

処理の順序に依存する仕様がある場合は、あえて想定と違う順序で操作する観点も立てておきます。現場では、想定外の順序で操作されることが日常的に起こります。

切り口4：権限とロールによる差異

業務システムでは、同じ画面でもロールによって表示項目や操作可否が変わるのが一般的です。管理者、一般、参照専用など、定義されたロールごとに観点を分けて用意します。

ここで重要なのが、表示の制御と実行の制御を分けて見ることです。ボタンが非表示になっているだけで、直接リクエストを送れば処理が通ってしまうケースは珍しくありません。

所属部署や担当範囲によってデータの見える範囲が変わる設計なら、その境界も観点になります。他部署のデータが見えてしまう不具合は、影響が大きく発見も遅れがちです。

切り口5：異常系と境界

正常系だけを並べた設計は、結合テストとしては不十分です。必須項目が空のまま次へ進んだ場合、上限を超える件数を登録した場合、処理の途中で通信が切れた場合を観点に加えます。

エラーが起きたときの挙動も確認対象です。適切なメッセージが出るか、データが中途半端な状態で残っていないか、ログに追跡できる情報が出力されているか。復旧の可否まで含めて見ておきます。

すべての異常系を網羅しようとすると際限がないため、業務が止まるもの、データが壊れるものを優先し、表示崩れの類は後回しにするという優先順位づけが現実的です。

切り口6：外部システム連携

外部との接続がある場合、正常応答だけでなく、エラー応答、タイムアウト、想定外の形式のデータが返ってきた場合を観点に立てます。相手側の都合で起きる事象は、こちらで制御できないぶん備えが必要です。

連携先がテスト環境を用意できない場合は、スタブで確認する範囲と実機で確認すべき範囲を分けて管理します。どこまでが未検証なのかを明示しておかないと、本番で初めて問題が出ます。

リトライの仕様がある場合は、二重に処理されないかも観点です。再送によって同じ注文が2件登録される、といった不具合はこの観点がないと見つかりません。

▼ 観点の抜け漏れが不安な段階でも相談できます 「この切り口で足りているか」「工数をどこに厚く配分すべきか」といった判断も含めて、実務目線でご相談を承っています。 ＞ 相談予約はこちら

観点をテストケースに落とし込む

切り口が出そろったら、具体化していきます。結合点との掛け合わせ、条件への分解、値の決定、件数の調整という4段階で進めると、抜けも重複も減らせます。

結合点と観点のマトリクスを作る

最初にやるのは、対象範囲にある結合点をすべて列挙し、縦軸に結合点、横軸に6つの観点を置いた表を作ることです。画面からAPI、APIからデータベース、登録から一覧反映といった、処理が受け渡される箇所が結合点にあたります。

この表を埋めていくと、「この結合点では権限の観点を見ていない」といった抜けが目に見える形になります。すべてのマスを埋める必要はなく、該当しない箇所は対象外と明記しておけば十分です。

表の段階で関係者に見せてレビューを受けると、ケースを書いた後よりはるかに少ない工数で抜けを潰せます。ここに時間をかけるほど、後工程が楽になります。

テスト条件に分解する

マトリクスの各マスを、具体的な対象と状況に落とします。「受注登録画面から一覧への反映」×「データ整合性」なら、「金額に小数を含む場合」「文字数が上限いっぱいの場合」といった条件に分解していきます。

この段階で、1つの条件に複数の確認内容を詰め込まないよう注意します。失敗したときに原因を特定できなくなり、再実施の範囲も広がってしまいます。

技法を使って値を決める

条件が決まったら、実際に使う値を選びます。ここで役立つのが体系化されたテスト技法です。JSTQBのシラバスでは、同値分割法、境界値分析、デシジョンテーブルテスト、状態遷移テストといった技法が整理されています（出典：JSTQB「テスト技術者資格制度 Foundation Level シラバス」）。

同値分割は、同じ扱いになると想定される値をグループにまとめ、各グループから代表を1つ選ぶ考え方です。境界値分析は、そのグループの境目とその前後を狙います。桁数や金額の上限がある項目では、この2つだけで効率よく値を絞れます。

条件の組み合わせによって結果が変わる場合はデシジョンテーブル、ステータスが遷移する業務では状態遷移の考え方が向いています。技法を使う目的は、少ないケースで多くの欠陥を見つけることにあります。

組み合わせが爆発しないようにする

条件を掛け合わせていくと、ケース数はすぐに現実的でない数になります。すべての組み合わせを試す必要はなく、影響の大きい組み合わせに絞るのが実務の考え方です。

2つの要因の組み合わせを網羅する手法を使えば、全組み合わせより大幅に少ない件数で、多くの不具合を検出できるとされています。ツールも公開されているため、条件が多い場面では検討する価値があります。

それでも件数が多い場合は、観点ごとの優先度を見直します。業務への影響が大きい結合点に厚く、影響の小さい箇所は薄く配分するほうが、限られた期間では効果的です。

抜け漏れが起きる原因と防ぎ方

観点の洗い出しがうまくいかない理由は、いくつかのパターンに集約されます。事前に知っておけば避けられるものばかりなので、着手前に確認しておいてください。

単体テストの焼き直しになっている

最も多いのが、入力チェックや計算ロジックの確認が並び、連携の確認がほとんどないという状態です。工数はかかっているのに、結合テストでしか見つからない不具合を見逃します。

回避策は、観点を立てるたびに「これは2つ以上の要素をまたいでいるか」と問うことです。1つの画面や1つの処理で完結する確認は、単体テストに戻します。

正常系に偏っている

設計書は正常な流れを中心に書かれているため、そこから素直に観点を起こすと正常系ばかりになります。異常系は意識的に追加しない限り出てきません。

対策として、観点リストに異常系の切り口をあらかじめ入れておきます。「入力が空のとき」「上限を超えたとき」「途中で失敗したとき」という定型の問いを用意しておけば、機械的に検討できます。

担当者の経験に依存している

経験が豊富な人ほど良い観点を出せますが、その人の記憶に依存した状態は組織としては脆弱です。担当が変わった途端に品質が落ちます。

出てきた観点は必ず文書として残し、なぜその観点が必要なのかも1行添えておきます。理由が書かれていれば、次の担当者が取捨選択の判断をできます。

設計書に書かれていない仕様がある

現場でよくあるのが、暗黙の仕様が設計書に反映されていないケースです。この状態では、設計書だけを根拠に観点を立てても実態とずれます。

対処は、開発担当者や業務担当者へのヒアリングを組み込むことです。「設計書に書かれていないけれど、気をつけている点はありますか」という問いから、重要な観点が出てくることがあります。

そこで見つかった内容は、テストケースに足すだけでなく設計書側にも反映します。テスト工程で仕様の抜けが見つかるのは、本来は前工程の問題だからです。

▼ 品質管理のプロセス見直しからご相談いただけます テスト設計の型化、レビュー体制の整備、AIを使った効率化まで、現場の課題に合わせて進め方をご提案します。 ＞ 相談予約はこちら

網羅できていることをどう説明するか

「十分に洗い出せたか」は主観で判断しがちです。追跡できる仕組みと定量的な材料を組み合わせることで、説明できる状態に近づけます。

要件や設計項目との紐づけ

最も効果があるのが、要件や設計項目のIDを観点とテストケースに紐づけることです。要件一覧と突き合わせれば、どの要件が何件のケースで確認されているかが機械的に分かります。

ケースが0件の要件があれば、それが抜けです。逆に、どの要件にも紐づかないケースがあれば、過剰か、設計書に記載漏れがあるかのどちらかになります。この突き合わせだけで主要な漏れは潰せます。

観点リストでチェックする

前述の6つの切り口を観点リストとして持っておき、結合点ごとに「この切り口は検討したか」をチェックしていく方法も有効です。検討したうえで対象外とした場合は、その理由を書き残します。

「検討していない」と「検討して対象外とした」は意味がまったく違います。この区別を記録しておくと、レビューでの議論が建設的になります。

定量的な目安を参考にする

判断材料のひとつとして、規模あたりのテストケース数や検出バグ数を参照する方法もあります。IPAが公開する「ソフトウェア開発 分析データ集 2022」では、累計5,546プロジェクトの定量データをもとに、結合テストと総合テストの規模あたりの数値が四分位で整理されています（出典：IPA「ソフトウェア開発 分析データ集 2022」）。

ただし、そのまま当てはめるのは危険です。IPAは検出バグを現象数と原因数に分けて集計しており、数え方を変えれば密度は変わります。テストケースの数え方も、1シナリオを1件とするか確認項目ごとに1件とするかで数倍の差が出ます。

比較する前に、自社の集計単位をそろえることが前提になります。数値は目安であって合格基準ではない、という位置づけで扱ってください。

レビューの観点を決めておく

洗い出した観点のレビューにも、見るべき点を決めておくと質が安定します。網羅性、粒度の統一、根拠の明示、優先度の妥当性の4点をチェックリスト化しておけば、担当が変わっても水準を保てます。

レビューは、ケースを書き終えた後ではなく観点の段階で行うほうが効果的です。手戻りの量がまったく違います。

観点を組織の資産にする

観点の洗い出しは、毎回ゼロから行う必要はありません。一度作った観点を蓄積し、次のプロジェクトで使い回せる形にすることが、長期的には最も効果の大きい投資になります。

観点リストをテンプレート化する

本記事で挙げた6つの切り口を土台に、自社のシステム特性に合わせた観点リストを作っておきます。業務システムなら権限と帳票、Webサービスならブラウザとデバイスの違いといった具合に、重点は組織ごとに異なります。

最初から完璧を目指さず、数十項目から始めて構いません。使いながら追加していくほうが、実際に役立つリストになります。

不具合から観点を追加する

リストを育てる最良の材料は、実際にすり抜けた不具合です。リリース後に発覚した不具合について、「どの観点があれば見つけられたか」を振り返り、リストに追加していきます。

この作業を各プロジェクトの終了時に30分でも設けておけば、数年でかなり実用的なリストになります。個人の経験が組織の知識へ移っていく、唯一の現実的な方法です。

生成AIを補助として使う

近年は、設計書や画面遷移図を渡して観点の候補を生成AIに出させ、人が取捨選択するという使い方も増えています。網羅的に候補を並べる作業は機械のほうが速く、抜けの発見には役立ちます。

ただし、出力をそのまま採用するのは避けてください。設計書に書かれていない前提を補って生成することがあり、実態と異なる観点が混ざります。叩き台として扱い、根拠との突き合わせは人が行う運用が安全です。

効果が出やすいのは、既存の観点リストを読み込ませて粒度の不統一や重複を指摘させる使い方です。レビューの一次チェックに使えば、人が見るべき論点に集中できます。業務全体の効率化の考え方は業務効率化アイデア55選の記事でも整理しています。

書ける人を増やす

最終的に品質を左右するのは、観点を考えられる人が何人いるかです。レビューを通じて複数人が観点を共有する運用にしておけば、経験の差は徐々に埋まっていきます。

新しく参加したメンバーには、まず観点リストを使ってマトリクスを埋めてもらい、経験者がレビューする形が学習効率の面でも有効です。育て方の考え方はAI研修の目的と選び方をまとめた記事も参考になります。

まとめ

結合テストの観点の洗い出しは、テストケースを書く前に「何に着目して確認するか」を整理する工程です。観点、テスト条件、テストケースという段階を意識すると、どこで抜けが起きたのかを特定できるようになります。

洗い出しの材料は、基本設計書と画面遷移図、インターフェース仕様、業務フローとユースケース、そして過去の不具合記録です。根拠のある観点だけを並べることで、レビューでの説明もしやすくなります。

観点は、画面間の遷移、データの受け渡し、タイミングと順序、権限とロール、異常系と境界、外部システム連携の6つの切り口で整理すると漏れにくくなります。結合点との掛け合わせをマトリクスにすれば、抜けが目に見える形になります。

そして、洗い出した観点を毎回捨てないこと。すり抜けた不具合から観点を追加し、リストとして育てていく仕組みがあれば、個人の経験に依存しない品質が実現できます。

▼ テスト設計と品質管理の改善を、社内に定着する形で進めませんか 株式会社ネクストスケールでは、業務の棚卸しからドキュメント運用の設計、AI活用による効率化と社内への定着支援までを一貫してご支援しています。まずはお気軽にご相談ください。 ＞ 相談予約はこちら