ソフトウェアのテストレベルは4種類
ソフトウェア開発における評価作業は、4段階のテストレベルに分けて実施されるのが一般的です。まず、個々の機能を確認する単体テストに始まり、複数の機能を組み合わせて検証する結合テストが行われます。
その後、全体の挙動や性能を確かめるシステムテスト、最終的な導入判断を行う受け入れテストの流れで進行します。各工程にはそれぞれ目的と検証対象が明確に定められており、順を追って進めることで欠陥の早期発見や品質の安定化が期待できるでしょう。
ここからは、各テストレベルを以下の項目に沿って解説します。
● 主な担当者
● 各テストの利点
● 各テストの課題
● よくある欠陥
【ソフトウェアのテストレベル】単体テスト（ユニットテスト）
単体テストは、開発した機能を最小単位で検証する作業であり、テスト工程のなかで最も早い段階に実施されます。主な目的は、設計どおりに処理が行われるかを確認し、プログラム内部のバグを早期に発見・修正することにあります。
■主な担当者
システムエンジニアやプログラマーが中心となって実施します。プログラムの構造や仕様に深く関与する工程であるためです。
コードを開発した担当者が、自らの開発したプログラムが意図どおりに機能しているかを細かく検証し、故障の有無を確認する作業が求められます。
■単体テストの利点
開発段階で欠陥を素早く把握できる点が強みです。機能ごとに動作を確認するため、原因箇所の特定が容易になり、修正にかかる手間を抑えられます。
開発者が自ら検証することで、プログラムの理解がより深まり、設計上の見落としにも気付きやすくなります。繰り返し実施することでより精度の高い検証が可能となるでしょう。
■単体テストの課題
開発者自身が担当するケースが多く、確認作業が形式的になったり、業務の忙しさから十分に実施されなかったりする場合があります。不適切に実施して「問題はない」と見なすと、本来この段階で検出できた欠陥が後工程に残ってしまいます。
その結果、結合テスト以降の工程で想定外の修正作業が発生し、全体の進行に悪影響を及ぼすケースも考えられるでしょう。
■よくある欠陥
設計書と一致しない処理や、意図しない挙動が見つかることが少なくありません。たとえば、仕様にない機能が組み込まれていたり、記述ミスによる誤ったロジックが組まれていたりするケースが挙げられます。
また、入力から出力までの情報の流れに不整合が生じる「データフローの乱れ」も頻発する傾向があります。
【ソフトウェアのテストレベル】結合テスト（統合テスト）
個別に動作確認を終えた複数の機能を組み合わせた際に、正しく連携するかどうかを検証する工程です。開発したモジュール同士が期待どおりに情報をやり取りし、想定された動作が実現されるかを重点的に確認します。
■主な担当者
開発に携わったシステムエンジニアやプログラマーに加えて、テストの設計と実行を専門とするテストエンジニアが関与します。モジュール間の接続部分やデータ連携の検証を行うため、仕様を把握している開発者とテスト手法に精通した技術者の連携が必要です。
■結合テストの利点
実施することで複数の機能が連動した際の振る舞いを確認でき、構成する要素同士の連携に潜む欠陥を早期に把握できます。処理の流れやデータのやり取りに不整合がないかを確かめることにより、単体テストでは見過ごされがちな誤りを見つけやすくなります。
また、画面や外部システムとの接続部分も検証できるため、システム全体としての完成度を高める効果も期待できるでしょう。
■結合テストの課題
中間工程にあたるため、プロジェクトの設計方針や開発体制によって内容が変わる傾向にある点が課題として挙げられます。検証項目が偏ったり、確認すべきパターンが漏れたりするおそれが生じます。
一方で、過剰に網羅しようとすることで必要以上に時間やリソースを費やすケースも少なくありません。こうした無駄や不足を防ぐには、検証範囲と目的を事前に定め、計画段階から設計精度を高める姿勢が欠かせません。
■よくある欠陥
機能間のやり取りに関連するバグが多く見受けられます。たとえば、送受信するメッセージの形式が一致していなかったり、データの形式や値に誤りが含まれていたりするケースが代表的です。
また、呼び出し順の乱れやタイミングのずれによって処理が正常に進まない事態も発生します。異なるコンポーネント間で交わされる情報の意味や単位に対する誤解が、意図しない挙動を引き起こす原因となるケースもあります。
【ソフトウェアのテストレベル】システムテスト
開発したソフトウェアが業務要件を正確に満たしているかを確認する工程です。個別の機能を検証する段階を経て、今度は全体の動作を実際の運用に近い環境で評価します。
業務シナリオに沿った一連の処理が正しく流れるか、複数端末や外部システムとの連携に問題がないかといった点を総合的に確認します。性能や安全性など、非機能面も含めて評価することで、納品前の最終的な完成度を判断します。
■主な担当者
幅広い観点から動作を確認する必要があるため、主にテスト業務に特化したエンジニアが中心となって進めます。実際の運用環境を再現しながらシナリオに沿って検証するため、テスト設計や実行に習熟した担当者の関与が不可欠です。
場合によっては、開発を担当したシステムエンジニアやプログラマーがテストに参加することもあり、仕様理解に基づいた視点からの確認が求められる場面もあります。
■システムテストの利点
設計された要件に対して正確に動作しているかを確認することで、機能面だけでなく操作性や安定性といった実用性まで幅広く検証できる点がメリットです。個別の検証では見つかりづらい欠陥も発見しやすくなり、導入後のトラブルを未然に防げます。
■システムテストの課題
本番環境に近い状態を整える必要があるため、事前の準備が不十分だと計画どおりに進行しない場合があります。結合テスト段階で解決されなかった欠陥が影響し、テストそのものが中断されるケースも見受けられます。
また、複数の関係者が関与することで調整が難航し、進行が滞ることも少なくありません。こうした混乱を防ぐには、各工程の完了確認と環境整備を丁寧に行うことが重要です。
■よくある欠陥
処理全体の流れを通じて見つかる欠陥が多く報告されます。代表的な例としては、以下のとおりです。
● 計算結果が誤っている
● 機能が意図どおりに動作しない
● 動作しないまま処理が終了してしまう
システム間のデータ連携において、形式や単位の食い違いによる誤動作もよく見られます。セキュリティ要件への対応漏れや利用者向けマニュアルと実際の挙動の不一致も課題となることもあります。
【ソフトウェアのテストレベル】受け入れテスト
開発されたシステムが、業務の要件を満たしているかを確認する最終段階のテストレベルです。実際の利用を想定したシナリオに沿って操作し、仕様どおりに機能が動作するかをユーザー目線で判断します。
■主な担当者
実際にシステムを利用する側の視点でテストを実施するため、クライアントのシステム部門や業務部門の担当者が主な実施者となります。業務フローに即した操作を通じて、運用上の問題がないかを確認する役割を担います。
なお、テスト項目の策定や実行サポートにはテストエンジニアが関与し、必要に応じて技術面での支援をするのが一般的です。
■受け入れテストの利点
運用環境を想定して実施するため、実務レベルでの適合性を見極められる利点があります。事前に設定された受け入れ基準に基づいて評価を実施することで、期待値とのずれを客観的に把握しやすくなるでしょう。
テスト方針や評価軸が明確であれば、判断の精度が高まり、導入後のトラブルを未然に防ぐ効果も期待できます。
■受け入れテストの課題
要求事項を満たしているかという視点で検証が行われるため、評価軸が抽象的になりやすい傾向があります。そのため、テストの目的や受け入れ条件をあらかじめ明確に設定しておくことが不可欠です。
また、実施中に発生する差異が仕様の不備か追加要望かを判断する際には、丁寧な確認が求められます。業務担当者が主導するケースも多いため、テスト全体を的確に管理する体制づくりもポイントです。
■よくある欠陥
システムが実際の業務要件を満たしていないことが原因で、欠陥が発見される場合があります。たとえば、業務フローに沿って処理が進まない、ルールどおりに計算されないといった問題が典型例です。
また、契約や法令上の条件に適合していないケースやセキュリティ面での脆弱性、高負荷時の性能低下なども見落とされがちです。非機能面を含めた細やかな確認が求められます。
JSTQBが定義するソフトウェアのテストレベル
一般的に認知されているテストレベルは、先述の4分類となります。ただし、ソフトウェアテスト技術者資格認定の国際的組織「ISTQB」の加盟組織であるJSTQBの定義では、テストレベルの分け方が少々異なることをご存じでしょうか。
JSTQBの定義によれば、統合テスト（結合テスト）は「コンポーネント統合テスト（結合テスト）」「システム統合テスト（結合テスト）」に細分化されます。それぞれのテストの概要を紹介しましょう。
■コンポーネント統合テスト（結合テスト）
複数の構成要素を組み合わせた際の動作や連携が設計意図に沿っているかを検証する工程です。単体で確認された機能同士が連携する場面で発生し得る欠陥や、データの受け渡しにおける齟齬などを早期に発見することが目的です。
主に内部インターフェースの整合性や連携時の異常系処理の確認が中心となります。個々の機能が正しく動作していても、連携によって問題が生じる可能性があるため、注意しなければなりません。
■システム統合テスト（結合テスト）
複数のサブシステムや外部サービスが連携した際に、全体として正しく機能するかを確認する工程です。各システム間のインターフェースが仕様通りに動作し、データの受け渡しに問題がないかを検証します。
異なるベンダーや開発チームが担当するシステムを組み合わせる場合も多いため、想定外の不整合が生じるリスクに備えるために不可欠な取り組みです。
V字モデルとW字モデルの違いと活用法
開発とテストのプロセスを最適化するためのモデルとして「V字モデル」と「W字モデル」があります。ここからは、それぞれの概要に加えて、メリットとデメリットを紹介します。
■V字モデルとは
ソフトウェア開発と検証の対応関係を視覚的に示した手法で、工程の流れを「V」の字で表現する点が特徴です。左側では要件定義から設計、実装といった開発工程が進行し、右側では単体テストから受け入れテストまでの検証工程が対応付けられます。
それぞれの開発フェーズに対して検証フェーズが明確に対応しているため、品質を意識した設計が可能となり、トレーサビリティの確保にも有効です。
＜V字モデルのメリット＞
開発とテストを対にして可視化することで、各工程の目的と役割が明確になる点がメリットです。設計段階で必要なテスト内容を素早く洗い出せるため、テスト準備に着手しやすく、実行時の立ち上がりもスムーズに進みます。
また、工程ごとに必要なスキルが明確になり、適切な担当者を配置しやすくなるため、作業分担が効率的に行えるのも利点です。全体の進捗も把握しやすく、納品までの道筋が見えやすい構造といえるでしょう。
＜V字モデルのデメリット＞
工程ごとの設計を重視するため、開発中に新たな要望が発生した際には柔軟な対応が難しい点がデメリットとして挙げられます。また、変更への対応コストが高くなりがちな点も課題のひとつです。
さらに、要件定義や基本設計といった初期段階でのミスに気づかずに進行すると、後工程でその影響が全体に広がるおそれもあります。
■W字モデルとは
V字モデルをさらに発展させ、開発とテストをより密接に連携させた開発手法です。各開発工程に対して、対応するテスト設計をあらかじめ組み込むことで、開発の初期段階から品質を意識した取り組みが可能になります。
レビューや総合テストなどの工程が追加されることで、システム全体としての整合性も高められます。開発と検証を並行して進める点が主な特徴です。
＜W字モデルのメリット＞
開発とテストを同時並行で進めるため、後工程での修正発生を抑えやすく、結果的に手戻りの少ない効率的な開発が可能な点がメリットです。テスト設計を早期に始めることで設計ミスや仕様の不整合にいち早く気づけるため、全体の品質アップにも役立つでしょう。
テストエンジニアが上流から関与するため、実施段階での理解が深まり、テスト工程そのものもスムーズに進行させられる点もメリットとして挙げられます。
＜W字モデルのデメリット＞
導入する際の課題は、初期段階から高い専門性を求められる点にあります。設計段階での不備を見抜くには、経験豊富なテストエンジニアの存在が不可欠です。テスト観点からの検証を成立させるには、高度なスキルが求められます。
また、開発とテストを同時に進める体制が必要となるため、チーム全体としての技術力や連携体制が十分でない場合、モデルの運用自体が難航する可能性があります。
各テストの進め方
各テストにはそれぞれ異なる目的と役割があり、進め方にも特徴があります。単体テストからシステムテスト、受け入れテストに至るまで、適切な順序と手法で進めることで、バグの早期発見や品質の安定につながります。テストの進め方は、以下のとおりです。
● テストの計画を立てる
● テストケースを作る
● テストを実施する
● プログラムを修正する
● テスト結果を分析し報告する
各工程について解説します。
1：テストの計画を立てる
テストの計画では、目的や対象範囲、実施方針を明確に定め、全体の方向性と重点領域を整理します。加えて、以下の項目もあわせて考えます。
● 進行のスケジュール
● 体制
● 使用ツール
● リスク対策
早めに見通しを立て、関係者間の認識を揃えましょう。
2：テストケースを作る
計画に基づき、実行すべき検証内容を具体化する工程です。対象となる機能を過不足なく評価できるよう、観点を網羅的に洗い出し、検証方法や入力値、期待される結果を整理します。
また、効率的なテストが実現できるように、手順や優先度も明確に定めましょう。最終的には、これらを文書化したテスト設計書を作成し、後続の工程で一貫した品質確認を可能にします。
3：テストを実施する
事前に構築した検証環境を用いて、テスト設計書に従って順に検証を進めます。各項目の実施後には、動作状況を客観的に証明するためのエビデンスを取得し、成果として残します。
記録には正常系・異常系の結果を漏れなく反映させ、正確な状況判断ができるように整理しましょう。検証結果を丁寧に記録することで、品質評価や問題の特定にも役立ちます。
4：プログラムを修正する
テストで欠陥が確認された場合は、まず原因を調査し、問題の発生箇所と影響範囲を明確にします。そのうえで、該当部分のソースコードを適切に修正し、動作に支障がないよう調整を加えます。
修正後は再度テストを実施し、欠陥が完全に解消されたことを確認してから完了とします。安易な修正を避け、根本的な原因に対処しましょう。
5：テスト結果を分析し報告する
すべての検証と修正を終えた後は、テスト結果を整理して関係者に共有します。報告後に追加の依頼や指摘があった場合は、それをもとに再度検証を行い、品質の向上につなげましょう。
なお、実際に行ったアンケートでも、サービスをリリースする前に十分なテストが重要だと感じる人は多く「とても思う」と回答した割合は66.6%にのぼりました。「やや思う」と答えた人も24.6%と高く、全体の9割以上が事前のテストを重視しています。
（調査データ引用元：https://prtimes.jp/main/html/rd/p/000001581.000044800.html）
安心して利用できるソフトウェアをリリースするためにも、きちんとテストを実施しましょう。
まとめ
ソフトウェアの品質を維持・向上させるには、適切なテストを実施することが欠かせません。単体・結合・システム・受け入れという4段階のレベルを通じて、バグの早期発見に努めましょう。
とくに商用リリースを前提とした環境では、曖昧なテストではなく、実運用に即したシナリオ設計と根拠に基づく評価が必要です。こうした高度な検証を外部に委託したい場合は、専門集団の力を借りるのが有効です。
ポールトゥウィンでは、JSTQB認定を取得したプロが在籍しており、あらゆる製品特性に応じたテスト戦略を提案できます。Webサイトやアプリ、IoT、組み込み系など、多様な検証実績がある点も強みです。
ソフトウェアテストのパートナーをお探しなら、ポールトゥウィンにお任せください。
