前回、新しいアプローチとして「テストレベルの分割」「開発した本人以外がテスト」「レビュー」「複数の視点の組み合わせ」「全体」の5つを提示しました。今回は、「テストレベルの分割」と「開発した本人以外がテスト」について詳しく説明します。

テストレベルの分割 -テストレベルとテストタイプ(視点の種類)の再構築-

テストレベルとは、コンポーネント(単体)テスト、統合(結合)テスト、システムテストのように、開発において組織的に管理するためのテスト作業の段階を指します。

おなじみのV字モデルは、開発フェーズとテストレベルの妥当性確認(Validation)の関係を表したものです。テストタイプとは、テスト対象の品質特性(機能性、信頼性、使用性、保守性、移植性、効率性など)に応じて適用するテストの種類を指します(表1)。ISTQBの用語集ではこのテストタイプの例として、信頼性テスト、有用性テスト、回帰テストなどが紹介されています。

表1 品質特性とテストレベルの関連付け例

テストタイプ

テスト環境

担当

ISO/IEC 9126 品質特性

機能性

信頼性

使用性

効率性

保守性

移植性

コンポーネントテスト

開発

実装担当者

 

 

統合テスト

開発/ステージング

アーキテクト、品質保証担当者

 

システムテスト

本番(原則)

要求管理者、品質保証担当者

実際のテストレベルとテストタイプの関係では、1つのテストレベルに、ある特定のテストタイプが対応付けられることが多いようです。例えば、「ストレステストやボリュームテストなどはシステムテストのテストレベルで行うもの」と考えられているようにです。ですが、テストレベルごとにどのようなテストタイプが必要なのかは、教科書通りに割り当てれば良いというものではなく、テスト対象によってテスト計画段階で検討しなくてはなりません。システムパフォーマンスに影響する場合はシステムテストではなく、その前の統合テストの段階で評価するといったように、事前に適用するテストタイプを決めるというアプローチを取らなくてはならないのです。

本稿記載のテストに関する用語は、基本的に「ソフトウェアテスト標準用語集(日本語版)Version 1.1,ISTQB(JSTQB訳)」に準じています。

開発した本人以外がテスト

「人間は間違いを犯す生き物だ」と言われる通り、自分が犯した間違いを自分自身で見つけるのは、どちらかというと苦手です。ソフトウェア開発でも、コードに限らず、要求仕様であれ機能仕様であれ、自分自身の誤りを探すのは難しいものです。このため、ドキュメントレビューやコードレビュー、テストケースのレビューを行うことで、当事者自身では見つけられないミスや論理的な矛盾といった不具合を摘出するわけです。

この時に、成果物を作成した人とは異なる人がレビューすると効果的なことはすでにわかっています。それもかなりの効果が上がります。

開発フェーズの早い段階からテストのプロセスを導入するアプローチとしてV字モデルを変形したWモデル(※1)がありますが、ここで示されていることは、「テスト設計のレビューへの適用だけではなく、テスト計画自体を開発の早期に始めるアプローチを取る」ということです(図1)。これによって開発におけるテストの重要性を再認識できるだけではなく、V字モデルに比べて開発フェーズとテストレベルの関係性がより明確になります。

※1 The W-MODEL Strengthening the BondBetween Development and Test,Andreas Spillner

図1 Wモデル

執筆者プロフィール

大西建児 (Kenji Onishi)
株式会社豆蔵 シニアコンサルタント。国内電機メーカー、外資系通信機器ベンダーで培ったテストや品質保証などの経験を生かし、テスト手法や技術の普及、発展に取り組む。NPO法人ソフトウェアテスト技術振興協会(ASTER)副理事長。JaSST’08東京 共同実行委員長。著書に「ステップアップのためのソフトウェアテスト実践ガイド」(日経BP社)などがある。

『出典:システム開発ジャーナル Vol.3(2008年3月発刊)
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。