この記事はThe V-Model in Software Testingの抄訳です。

V字モデルとは、ソフトウェア開発プロセスの一部としてのテスト活動を記述するために使用されているモデルです。

V字モデルは、テスト活動を開発プロセスの中の最終ステップとして位置付ける、ウォーターフォールモデルの延長と捉えることができます。

しかし、ウォーターフォールモデルとは対照的に、V字モデルでは各開発フェーズに対応するそれぞれのテスト活動を定義しています。

V字モデルは、ソフトウェア開発プロセスを過度に単純化していることや、現代のアジャイル開発プロセスに完全に対応できていないなどとして批判されがちですが、しかし同時に、ソフトウェアテストに不可欠な多くの用語と概念を含んでいることも事実です。

したがって、これらの用語とその背後にある概念を活用することで、ソフトウェアプロジェクトにおけるテストの取組みの中で適切な構造を見出すことができます。また、V字モデルは、アジャイルプロジェクトの各イテレーションのモデルとしても使用することができます。

V字モデルとは

V字モデルの基本的な考え方は、開発活動とテスト活動の各フェーズが互いに対応し合っているということです。

つまり、各開発フェーズは、それ自身のテスト活動をもって完了する必要があります。

これらのテスト活動はそれぞれ、ソフトウェアコンポーネントの実装、コンポーネントの統合、完全なソフトウェアシステムへの結合、ユーザーによる納品物の受入という異なる抽象化レベルをカバーしています。

開発プロセスの最後に完成したソフトウェアを一度にテストするのではなく、異なる抽象層に焦点を当ててテストを行うこのアプローチは、テストによってソフトウェアの不具合を誘発し、分析し、発見し、修正することを、より容易にします。

V字モデルは、開発フェーズを「V」の左側の枝として記述し、右側の枝にテスト活動を定義しています。

V字モデルの開発フェーズ（左側）は、ウォーターフォールモデルや開発パイプラインの論理フェーズとして一般的に知られています。ここでは、各フェーズを説明していきます。

まず、ソフトウェアシステムの要件を発見し、整理する必要があります。このプロセスは通常、ユーザーやその他の利害関係者とのセッション、具体的にはインタビューや文書調査によって行われます。収集された情報の分析を通じて、要件をより正確に定義することができます。

定義されたソフトウェア要件は、高レベルの要件文書として永続的に保存されます。

システム設計/機能設計

要求分析の結果に基づき、システムの機能レベルでの設計が行われます。これには、機能の定義、ダイアログやメニューなどのユーザーインターフェイス要素、ワークフロー、データ構造などの定義が含まれます。

この段階で、システムテストのドキュメントも作成可能となります。

振る舞い駆動開発（BDD）のテスト駆動型アプローチを採用する場合、機能（feature）の仕様もこの段階で作成することができます。BDDはコンポーネントレベルの仕様と強く結びついているため、この段階で使用が作成可能であることが意外と捉えられるかもしれません。

しかし、SquishのBDD機能では、BDDを機能レベルの仕様に対しても適用することが可能です。

アーキテクチャ設計

機能設計の定義に続いて、システムアーキテクチャの全体設計とそのコンポーネントへの分離が行われます。この段階で、一般的なコンポーネントの機能、インターフェース、依存関係が定義されていきます。

これには通常、UMLなどのモデリング言語や、普遍的な問題を解決するためのデザインパターンが用いられます。

この段階でシステムのコンポーネントとそのインターフェイスが定義されるため、統合テストの準備を開始することができます。

次のフェーズでは、具体的なコンポーネントの低レベル設計が行われます。

各コンポーネントには、実装する内部ロジック、APIを記述した詳細なインターフェース仕様、また、データベーステーブルがある場合はそれを含めて詳細な定義がなされます。
インターフェイス仕様とコンポーネントの機能記述が存在すれば、コンポーネントテストの準備はその時点で既に着手可能です。
コンポーネントレベルでBDD（Behavior Driven Development）のテスト駆動型アプローチを採用する場合は、個々のコンポーネントの機能（feature）仕様を作成することとなります。

実装フェーズは、特定のプログラミング言語を用いたコーディング作業です。ここまでのフェーズで決定された仕様に従ってソースコードを実装していきます。

検証と妥当性確認

V字モデルでは、テスターは特定の開発フェーズの要件が満たされているかどうかを検証することを求められます。それに加えテスターは、システムがユーザー、顧客、その他の利害関係者のニーズを満たしていることを検証する必要があります。

テストには検証と妥当性確認の両方が含まれます。一般的に、V字モデルのより高いフェーズに位置する要求に対しては、検証よりも妥当性確認が多く実施される傾向にあります。

V字モデルによれば、テスト活動は以下のテストステージに分けられ、それぞれ特定の開発フェーズと関連を持っています：

コンポーネントテスト

コンポーネントテストは、プログラムの最小構成要素であるそれぞれのコンポーネントが正しく機能することを検証するものです。プログラミング言語によって、コンポーネントはモジュール、ユニット、クラスのいずれかに分類されます。これに従って、テストはそれぞれ、モジュールテスト、ユニットテスト、クラステストと呼ばれることになります。

コンポーネントテストでは、コンポーネントの仕様に基づき、入力を与えた後のコンポーネントの出力をチェックします。BDDのテスト駆動型アプローチでは、これらはフィーチャーファイルをもとにしてテストを行います。

コンポーネントテストの最大の特徴は、単一のコンポーネントを、他のコンポーネントとのやりとり、つまりインターフェイスなしに、独立した状態でテストすることです。他のコンポーネントを介さないため、不具合の特定が非常に容易です。

一般的に、テストの実装はテストフレームワークの助けを借りて行われます。例えば、JUnit、CPPUnit、PyUnitやGoogleTest(参考：【Cocoノウハウ】Google Testの単体テストカバレッジをCocoで取得する)などの単体テストフレームワークが使用されることが多いです。テストがコンポーネントのソースコードをできるだけ多くカバーしていることを確認するために、コードカバレッジを測定することも行われます。コードカバレッジ分析ツールには、例えばCocoのようなものもあります。

コンポーネントテストは、機能テストの他に効率性（ストレージ消費、メモリ消費、プログラムタイミングなど）や保守性（コードの複雑さ、適切なドキュメンテーションなど）といった非機能的な側面に着目したテストも行うことができます。Cocoは、コードの複雑さ解析や関数プロファイラを通じて、こういったテストのサポートもすることができます。

結合テスト

結合テストは、独立して開発・テストされたコンポーネントが互いに結合された際に、期待通りに動作することを検証します。テストは、特定の２つのコンポーネント、コンポーネントのグループ、あるいはソフトウェアシステム内の独立したサブシステムだけを対象とすることができます。結合テストは、通常、コンポーネントがすでにコンポーネントテストの段階でテストされた後に実施されます。

結合テストの設計は、機能仕様、システムアーキテクチャ、ユースケース、またはワークフロー記述に基づいて行うことができます。結合テストは、コンポーネントのインターフェイス（またはサブシステムのインターフェイス）に焦点を当て、独立したコンポーネントのテストでは誘発されないような、相互作用によって誘発される不具合を明らかにすることを目的としています。

結合テストは、外部のソフトウェアやハードウェアシステムのような、アプリケーション環境とのインターフェースに焦点を当てることもできます。これは一般的に、コンポーネント結合テストとは対照的に、システム結合テストと呼ばれてます。

ソフトウェアの種類によっては、テストドライバは単体テストフレームワークにもなり得ます。GUIアプリケーションをテストする場合、当社のGUIテスト自動化ツールのSquishをテストに使用することもできます。Squishは、テスト対象のアプリケーション自体だけでなく、サブシステムや外部システム（構成ツールなど）も自動化することができます。

システムテスト

システムテストの段階では、ソフトウェアシステム全体をテストの対象とします。結合テストが技術的な仕様に基づくことが多いのに対し、システムテストはユーザーの視点を意識して作成され、機能的および非機能的なアプリケーション要件に着目したテストが行われます。後者の非機能テストには、性能テスト、負荷テスト、ストレステストが含まれることもあります。

コンポーネントとコンポーネントの結合はすでにテストされていますが、機能的なソフトウェア要件が満たされていることを検証するためには、システムテストが不可欠です。一部の機能は、完全なソフトウェアシステムを実行しなければテストすることができません。システムテストの作成には、通常、エンドユーザーのドキュメントやリスク分析文書のような追加資料が含まれます。

システムテストのテスト環境は、可能な限り実際にアプリケーションが動作する環境に近づける必要があります。可能であれば、同じハードウェア、オペレーティングシステム、ドライバ、ネットワークインフラ、または外部システムを使用し、本番システムの挙動を再現するようにする必要があります。ただし、システムテストで発生した不具合が本番システムに影響を与える可能性があるため、本番環境をテスト環境として使用することは避けましょう。

システムテストでは、手動でのテスト実行を避けてテスト工数を削減するために、テストの自動化の検討が必要になることがあります。

画像認識や光学式文字認識を利用することで、SquishはあらゆるGUIアプリケーションのテストを自動化し、非GUIプロセスを起動してテストに利用することができます。

GUIによるアプリケーション出力の検証に加え、SquishはGUIと非GUIオブジェクトの両方で利用可能なアプリケーション内部データにアクセスすることができます。

複数のアプリケーションのテスト、たとえ異なるGUIツールキットであっても1つの自動テストでテストすること、組み込みデバイスのテスト、データベースシステムなどの外部システムへのアクセス、手動での検証や妥当性確認を含む半自動テストなど、システムテストのニーズのほとんどを満たしています。

受入テスト

受け入れテストは、例えば、まだリリースされていないソフトウェアのバージョンに対する内部的なテストである場合もあります。多くの場合、この内部受け入れテストは、製品管理、営業、サポートスタッフなど、開発やテストに関与していない人たちによって行われます。

一方で受け入れテストは、開発を依頼した企業やソフトウェアのエンドユーザーが行う、外部テストであることもあります。

顧客受け入れテストでは、ソフトウェアの最終リリースが高レベルの要件を満たしているかどうかを判断するのは、部分的または完全に顧客の責任となる場合もあります。テストの実施後は結果を文書化し、開発会社と顧客との間で議論するために報告書が作成されます。

顧客受け入れテストとは対照的に、ユーザー受け入れテスト（UAT）は、最終的なソフトウェアリリース前の最後のステップとなる場合があります。これは、ソフトウェアが本当に想定するワークフローを提供するかどうかを検証するための、ユーザー中心のテストです。これらのテストは、ユーザビリティの側面や一般的なユーザーエクスペリエンスまでカバーすることがあります。

受け入れテストにかける労力は、ソフトウェアの種類によって異なります。単一のクライアントのために開発されたカスタム開発に対しては、大規模なテストとレポートが行われることもあります。一方で、既製品のソフトウェアの場合はこのテスト段階にかける労力は少なく、受け入れテストは、インストールといくつかのワークフローをチェックする程度で済むこともあります。

受け入れテストは一般的に手動で行われるテストであり、特にこれらのテストは開発プロセスの最後に一度だけ実行されることが一般的あるため、そのごく一部しか自動化されていないことが多いです。しかし、受け入れテストはワークフローとユーザーによるアプリの操作に重点を置いているため、GUIテスト自動化ツールSquishを使用して受け入れテストを自動化することをお勧めします。SquishがサポートしているBDD(振る舞い駆動テスト)は、プロジェクトにかかわるすべてのステークホルダーの共通言語や仕様として使用することができます。また、ソフトウェアのライフサイクルにおける複数のバージョンに対する受け入れテストや、アジャイルプロジェクトにおける多くのイテレーションに費やされた労力を考慮すると、中長期的には、テスト自動化は多くの工数の削減を期待することができます。

お問い合わせ

SquishをはじめとするQtのQA(品質保証)ツールにご興味がおありの方は、Qt JapanのEメールアドレス：japan@qt.ioまでお気軽にご連絡ください。概要のご説明から詳細な技術的相談、また無料のツールトライアルのご案内もいたしております。