ソフトウェアテストでのテストレベル別のレビューとは

各テストレベルのレビューの説明に入る前に、V字モデルを例にレビュー対象となる成果物について確認しておきます。

図表1は、開発工程とテスト工程のレビュー対象の成果物を表しています。開発成果物のレビューは、開発工程ごとのアウトプットの質を高めるために実施します。

テストでは各テストレベルのテストの妥当性と網羅性を確認し、テストの誤りや漏れを防止することで、テストという行為そのものの質を担保することを目的としてレビューを行います。

関連記事：V字モデルとは？特徴やメリット・デメリットを解説

主なレビュー対象物と目的を下表に示します。

テストウェアに対するレビューを行わないと、以下のようなリスクがあります。 

• 本来テストで検出すべき欠陥がテスト仕様の不備などの理由でテストされないまま見逃され、リリース後に不具合が発生する
• 手戻り作業や追加修正が発生し、開発工程の遅延や対応コストが増加する
• 機能安全規格（ICE 61508やアンブレラ規格となるISO 26262）や法令などにおいて、テストプロセスやテストウェアへのレビューが定められている場合、レビュー未実施により納品未完や契約違反などになるリスクがある

代表的なレビュー方式の種類と特徴を下表に示します。

プロジェクトの規模や開発体制に応じて適切なレビュー方式を選択します。

以降は各テストレベルのレビューについて解説します。

関連記事：ウォークスルーとは？他のレビュー手法との違いやメリット・デメリットを解説

単体テストはモジュールごとに詳細設計仕様に対する動作を確認するためのテストです。コードの構造的な不具合（ロジックや計算ミス）を検出することが主な目的です。

各機能の分岐や例外条件、さまざまな入力値（境界値、Null、異常値など）に対して、網羅的にテストすることが重要です。

単体テストのレビュー観点

単体テストでの重要なレビュー観点は以下の三つです。

• 全ての分岐・例外処理を網羅しているか
• 異常系（境界値、Null、異常入力）をテストできているか
• テスト実装や実行の前提条件・環境設定が明確か

単体テストのレビュー方法

プログラム担当者やテスト担当者同士でのペアレビュー、もしくはウォークスルー方式で実施されることが多いです。テストコードやテストケースの網羅性、詳細設計仕様との整合性を確認します。

結合テストは複数のモジュールを組み合わせてテストする内部結合テストや、サブシステム間の相互連携を確認する外部結合テストがあります。

モジュール間、サブシステム間のインターフェースの不整合や、連携時の欠陥を検出することが主な目的となります。

結合テストのレビュー観点

結合テストでの重要なレビュー観点は以下の三つです。

• インターフェース仕様のパターンが網羅されているか
• 異常系（通信断、データ不整合、リトライ処理等）のテストケースが含まれているか
• 結合部分特有の依存関係、タイミングが考慮されているか

結合テストのレビュー方法

開発者およびテスト担当者によるインスペクション方式で行われるケースが多いです。

システム間・モジュール間のインターフェース仕様とテストケースを突合してテストの抜け漏れを確認します。

システムテストは機能要件の他、性能や信頼性、セキュリティなどの非機能要件も満たしていることを確認する必要があります。外部システムとのインターフェース仕様や利用環境（OS、ブラウザなど）を満たしていることも確認します。

システムテストのレビュー観点

システムテストでの重要なレビュー観点は以下の四つです。

• 機能要件としての処理（業務フローや画面遷移、操作手順）が正しいか
• 非機能要件（性能、セキュリティ、運用性など）の妥当性が確認できているか
• 異常系（障害、操作ミス、データ誤りなど）に対応できるか
• さまざまな利用パターン(ユースケース)のテストケースがあるか

システムテストのレビュー方法

インスペクションやウォークスルーの方式で実施されることが多く、品質保証部門が参加する場合もあります。

機能要件や非機能要件を満たしているか、シナリオベースや業務フローベースで網羅性がカバーされているかなど、要件に基づき構築されたシステムとしての妥当性を確認します。

受け入れテストは、開発工程の最終的なテストレベルです。

図表5は、要件を実現することの難しさを表した有名な風刺画ですが、受け入れテストでは、完成したシステムが顧客の要求や業務要件を満たしているかどうか、期待通りの品質・機能を備えているかをユーザーの立場で確認します。実運用に沿った使い方をして問題が発生しないかを確認する必要があるため、テスト環境やテストデータについても実運用と可能な限り同じものを使用することが求められます。

引用：Tire Swing Cartoon | University of Oregon

受け入れテストのレビュー観点

受け入れテストでの重要なレビュー観点は以下の四つです。

• エンドユーザーのニーズや顧客が提示した業務要件に合致しているか
• 運用手順通りにシステムが動作し運用・保守できるか
• 運用を想定したテストシナリオに抜け漏れがないか（受け入れテストで顧客からの検収が受け入れられるか）
• 実運用に近い形でテストを実行できているか

受け入れテストのレビュー方法

受け入れテストの結果は顧客による受け入れが承認される(検収)という意味を含むため、原則として、顧客やエンドユーザーを交えてレビューします。

このため、業務観点やユーザー運用視点からシステム全体としてテストケースの十分性や妥当性を確認します。

ここまでウォーターフォール開発を前提とした解説をしてきましたが、アジャイル開発におけるソフトウェアテストのレビューをどのように実施するのかについても触れておきます。

アジャイル開発の代表的な手法であるスクラムでは、各スプリントで「設計→実装→テスト」を繰り返すため、テストウェアの作成・レビューはスプリントの中で「小さく・頻繁に」スプリントレビューの一つとして行います。

• レビュー目的：テストの品質と共通理解の確立
• レビュー方法：ペアレビュー、チーム内確認、開発者との協働、テストコードレビューなど
• レビューのタイミング：スプリント全体を通して随時開催（短時間）

関連記事：アジャイルテストとは？4象限の内容や実践手順を解説

ソフトウェア開発における各テストレベルで検出すべき故障や欠陥、摘出しやすい不具合は異なります。

初期段階である単体テストレベルで検出可能な故障や欠陥を残したまま後工程に進んだ場合、後工程で不具合が多発し、本来テストすべき内容を十分にテストできずに品質が安定しなかったり、後工程になればなるほど、欠陥の解析・修正、再テストなどの手戻り工数が大きくなるため、スケジュールの遅延やコスト増につながる悪循環に陥る可能性が高くなります。

テストレベルごとにテストの主な目的や観点が異なるため、テストレベルごとのテストウェアを確認するレビューは、テストレベルごとのテスト効率に直結するとともに、開発工程全体に対しても、品質の向上に大きく貢献する活動と言えます。 

■参考文献■

• ソフトウェア品質知識体系ガイド（第3版）－SQuBOK® Guide V3－（著者：飯泉紀子、鷲崎弘宜、誉田直美監修、SQuBOK 策定部会　編）
• ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2023V4.0.J02
• 高信頼化ソフトウェアの為の開発手法ガイドブック（独立行政法人 情報処理推進機構　ソフトウェア・エンジアリング・センター）
• オレゴン大学の実験（クリストファー・アレグザンダー他著、西川幸治解説、宮本雅明訳、鹿島出版会） 
• スクラムガイド