【ソフトウェアテスト】ソフトウェア開発とテスト活動について②
「【ソフトウェアテスト】テストレベルについて ①」記事に記載のとおり、開発ライフサイクルモデルには形式や期間によってさまざまなモデルがあり、テストを実施するタイミングもモデルによってさまざまです。
先に挙げた開発工程の例である
要件定義→設計→開発→テスト→リリース/保守
を一連の流れとする開発ライフサイクルも、このフローを開発期間の流れとして実施するのはあくまでウォーターフォール型モデルのようなシーケンシャルな開発ライフサイクルであり、イテレーティブ開発モデルやインクリメンタル開発モデルでは、各工程とテストが同時に進行したり、無駄をなくすことを目的としてあえて一部工程を省くこともあります。
V字モデルは各工程とテストが同時進行する例です。
要件定義の段階で要件定義に対するテストを実施、システム設計の時点で設計された内容に対してテストを実施といったかたちで、開発完了後にようやくテストではなく、常に工程の早期段階でテストを実施します。
開発完了後のテストで不具合が検出されると工程の手戻りが発生してしまい、工数に無駄が生じますが、早期にテストを実施することにより、上流工程の段階で不具合や懸念を可能な限り取り去って開発作業の手戻りを少なくし、無駄な工数の増加を防いだり、最終的な品質の向上を目指すことができます。
このようにV字モデルの左側で行う開発活動に対して早期にテストを実施して効率的な開発活動を目指す手法をシフトレフトと呼びます。
イテレーティブ開発モデルやインクリメンタル開発モデルとなると、さらに各工程とテストが早期段階で実施されていきます。
全体的な流れをより細かく迅速に行い、それを細かく繰り返していくサイクルが、現在のソフトウェア開発形式の主流になってきています。
1. テストプロセスについて
ソフトウェアテストの標準規格であるISO/ICE/IEEE 29119では、ソフトウェアテストのプロセスについて、主に以下の3階層のモデルを提示しています。
・組織のテストプロセス
主に組織全体におけるテストの方針や戦略を決定する段階です。テストポリシー、テスト戦略、テスト計画、テスト手順書、テスト環境、テストツールなど、プロジェクトにおけるテストに関する全体の管理を含んでいます。
・テストマネジメントプロセス
テストそのものの計画作成や継続的なモニタリングとコントロールなどを行う段階です。テスト工数やリソース管理、スケジュール管理、リスク管理など、テスト進行に関わる全ての管理を含んでいます。
・動的テストプロセス
実際にテストを実行する段階です。テストケース作成などのテスト設計、テストの実施、結果分析、インシデント管理など、テストの実施に関わる活動を含んでいます。
なお、動的テストプロセスと表現しているとおり、静的解析やレビューなどの静的テスト活動は当該階層には含まれていません。
階層と表現しているとおり、組織のテストプロセスはプロジェクト全体でありテストマネジメントプロセスを包括している、テストマネジメントプロセスはテスト全体であり動的テストプロセスを包括しているといった関係性になります。
2. テストレベルについて
JSTQB FLシラバスにも記載されていますが、テストのレベルは以下の4つに分けられています。
・コンポーネントテスト
単体テスト(Unit Testing)とも呼ばれます。
テスト対象は個々のコンポーネント、ユニット、モジュール、コード、クラス、データなど、コンポーネント単体の動作を確認します。
コードを対象としていること、成果物の動作を確認することから、ホワイトボックステスト、ブラックボックステストでテストされます。
・統合テスト
結合テスト(Integration Testing)とも呼ばれます。
複数のコンポーネントの組み合わせによって想定される動作を対象にテストします。
コンポーネント同士の相互作用やデータ受け渡しの動作確認をすることから、インターフェーステスト、データフローテストなどでテストされます。
・システムテスト
システムが要件定義書や仕様書に記載されている内容どおりに動作するか確認します。
機能テスト、性能テスト、セキュリティテスト、ユーザビリティテストなどが実施されます。
・受入テスト
システム全体やサービスなど開発対象の成果物がユーザーの要件に適合しているかをテストします。
テストとしてはユーザー受入テストが実施されます。
このテストレベルに運用テストが含まれる場合もあるため、システムやサービスが市場リリース基準や法令などに適合しているか、本番環境で使用されるユーザー数に対して正常に動作するか、セキュリティの観点で安全性が確保されているかなども確認対象となるため、負荷テスト、復旧テスト、セキュリティテストなども実施されます。
上記のとおり、レベルの最も初期のものは単体テストであり、テスト対象はコードなどのコンポーネント単体として、ホワイトボックステストが実施される想定です。
ですがこの各レベルはテストプロセスにおいては動的テストプロセスとされており、開発のフェーズとしてより前段階にある要件定義と設計に対してのテストに言及していません。
このため、もっとも初期のテストレベルがすなわちもっとも開発の初期段階で実施されるものというわけではなく、あくまで動的テストとしてもっとも初期の段階で実施できるテストとなります。
3. テストタイプについて
テスト対象として何をテストするかによって、テストタイプも種類を分けて表現されます。
・機能テスト
システムの機能が想定どおりに動作するかを確認します。ブラックボックステストやホワイトボックステストによってテストされます。
・非機能テスト
システムの機能以外の面、性能、セキュリティ、ユーザビリティなどを確認します。負荷テストやセキュリティテストなどシステムの可用性を確認したり、受入テストとして実際のユーザー利用状況を想定したテストなどが実施されます。
・構造テスト
機能テストよりもより内部構造にフォーカスしたテストタイプです。単体テストなど各モジュール自体のテストのほか、コードレビューなどの静的テストも対象となります。
・回帰テスト
追加や改修によって既存機能に意図しない変更や動作が生じていないかという点がテスト対象になります。スモークテストでそもそも動作するかを確認したり、リグレッションテストで過去不具合の再発確認や既存動作の無影響確認が実施されます。
4. 追記
ソフトウェア開発ライフサイクルは開発活動自体の形式を表現しており、テストプロセスはテスト活動全体がどのようなプロセスで進行しているかを示しており、テストレベルは開発のどの段階でどのようなテストが実行されるかを記述してます。
また、テストタイプは何をテスト対象とするかについての記載です。
所属している企業や開発チームによって名称や捉え方などが違う場合もあり、ライフサイクルの形式とプロセスとレベルとタイプのそれぞれが必ず実際の状況と合致しているとは限りませんが、ソフトウェアテスト規格のISO/ICE/IEEE 29119に準拠してテストを進行することで、体系化された手法を用いて効率よく高品質なテスト活動を目指すことができます。