3 ソフトウェアテスト見積りでの成功と失敗例
3.4 テスト戦略の重要性
3.4.2 テスト戦略
それぞれのテストレベルに対応する要求と、要求が満たされていない場合のリスクに基づいて、
それぞれのテストレベルで最も重要な欠陥を出来るだけ迅速に効果的に検出できるように「テス ト戦略」を設定します。
特に、主にベンダが主体でユーザと協力して実施することが多い低位レベルテストの戦略と主
【開発工程】
要求定義
【ソフトウェア製品】
要求定義書 基本設計
基本設計書 パッケージ設計
パッケージ設計書 プログラミング
ソースコード 予
防 活 動
検知活動
(=品質不良の発見)
・レビュー
・ウォークスルー
・シミュレーション
・プロトタイピング
・など
テスト 低位レベルテスト
・単体テスト
・統合テスト 高位レベルテスト
・システムテスト
・受入れテスト
・など 修正活動
欠陥の混入を抑止する。
例)
・文書化標準の開発・適用
・標準手法の開発・適用
・技法(設計など)の 開発・適用
品質保証活動(予防、検知、修正)が果たすべき効果
【予防活動】
・開発者に対し、彼らの 仕事がどの標準を満たすべき かを明確に指し示す。
・開発がその標準を用いて チェックできることを明確に 指し示す。
【修正活動】
・成果物に発見された欠陥を 追跡し、その欠陥が将来発 生しないように予防する。
【検知活動】
・プロセスの品質を表す指標 の設定(標準の設定)および 測定
・テストチームにとって、
標準に従って成果物やサー ビスをテストできること。
にユーザが主体でベンダと協力して実施することが多い高位レベルテストの戦略とを緊密に調和 させ、全体のテスト戦略を最適化することが重要です。例えば、ユーザ視点のUIなどのテスト を低位レベルテストに組入れて、欠陥をできるだけ早期にできるだけ安く検出したり、低位レベ ルテストのテストケースと高位レベルテストのテストケースとが重複したりするのを避けたりと いった事項が該当します。
ソフトウェアテスト見積りの精度(妥当性)を向上するために、プロジェクトの見積り時点で、
テスト戦略を定め(決定できない事項はそのことを明示して)ユーザとベンダ相互に合意した上 で、これをソフトウェアの開発サイクル前提条件として見積りにインプットとすることが重要で す。
以下、3.1~3.3 節に記載する事例から、テスト戦略で考慮する事項をリストアップして整理し ます。
(1)テスト技法の選択
テスト戦略の設定に関して重要な視点は、テスト技法の選択であり、テスト技法の選択に基づ いてテストの目標を設定することになります。テスト技法は、テストベース(要件定義、基本設 計、詳細設計など)からテストケースを引き出す構造化されたアプローチであり、特定の欠陥の 検出を目的としています。テスト技法については、本ガイドブックの第 2 章および 4.3 節に紹介 しています。テスト技法を利用することにより、アドホックにテストケースを設定するよりも遙 かに効果的に欠陥を検出できるようになり、同じテスト対象システムのテストでも、選択するテ スト技法によってテスト量(テストケース数など)は異なります。
成果物をいかに徹底的にテストするか否かという観点で、テスト技法を選択するとともに、品 質目標値(テスト密度、検出欠陥密度、テスト網羅率など)として設定します。これは、テスト 量(テストケース数など)の見積もりに一番大きく関係します。
3.1~3.3 節では、品質目標値に関して留意するべき事項が紹介されており、次に整理します。
・品質目標値(テスト密度、検出欠陥密度、テスト網羅率など)は、テスト対象システムの特質 などを見極め(分析・評価)、その結果を見積りの入力情報にすることが必要です。尚、テスト 対象システムの業務設計や処理方式設計などを配慮したテスト設計では、各自に設定した品質目 標値に固守することなくテスト量(テストケース数など)を再見積もりすることも必要です。
・システム全体に影響する重要機能は、障害によるリスクを整理して、テスト優先度およびテス ト密度の差別化などを考慮しておくこが必要です。
(2)テストプロセスの設定
システムの品質を強化するために、高位レベルのテストプロセスを正しく管理すること、およ び報告とコミュニケーションによってプロジェクトの他の部分(設計・実装工程および低位レベ ルテスト)との調和をとることが重要です。
3.1~3.3 節で紹介している事例でも現れていますが、経験的には、良いテストプロセスの重要 性に対する認識は、低位レベルテストよりも高位レベルテストにおいて高いのが実情です。しか
61
しながら、低位レベルテストのプロセスは高位レベルテストのプロセスと密接に関連しているの で、高位レベルテストの視点から低位レベルテストの目標を定めて、低位レベルテストのテスト プロセスを設計し、実施し、評価することが重要です。テストプロセスは、ソフトウェアテスト の生産性の見積りに一番大きく関係します。
3.1~3.3 節では、テストプロセス設計に関して留意するべき事項が紹介されており、次に整理 します。また、事例で紹介しているものの他に、テストプロセスを設計する視点として留意する 事項として 2 点(③および④)を挙げています。
① 非機能要件のテスト戦略
・非機能要件(性能など)のテスト設計では、現行処理状況(投入データ数と処理デー タ数との因果関係)も調査した上で、性能測定の基準数値(最大処理件数)を決めます。
なお、データ量の延び率を見積もる上で、利用部門などの参加(レビュー含め)が必須 です。
・期間の制約条件がある場合(テスト期間が短いなど)、データ制約条件がある場合(テ ストには整合性の取れた大量のデータが必要であるなど)は、設計・実装工程の品質作 り込み(レビューなど)コストとテスト工程の確認テストとを配慮することが必要です。
また、「早期のテストデータの作成」や「単体テストや統合テストなどの早い段階での 大量データでの確認(DB 間整合性を求めず)」といったタスクの検討を考慮するなどの 工夫が必要です。
・非機能要件の確認テストは、「機能要件面の確認への傾注傾向」、「手間がかかる」など の理由から、開発の状況(予算超過状態など)に左右され、おろそかになることが多く 見受けられます。テスト戦略においてその重要度を認識しておくことが必要です。
・対外接続テストなど外部(他社)とやり取りする確認テストは手間がかかり、かつ計 画も簡単に変更できないといった制約があります。テスト戦略の中で逼迫した状態であ っても、「安易に計画変更してはならない作業」であることを特定しておくことが必要 です。
② テストプロセスの設計
・テスト設計において、テストケースの実施順序およびテスト実施手順を決めておくこ とは、データの重複性の排除、テスト実施の効率化、テスト環境の共有および結果確認 の容易さなど、テスト効率の向上が期待できるので考慮しておく必要があります。
・テスト設計において、テストの重複を見極め単一データでの項目消化量を増加させる ことは、データ量を削減するなどテストの生産性の向上が期待できるので考慮しておく 必要があります。
・プログラム欠陥はソースレビューのチェック方法を策定し、徹底することで削減でき る。テスト見積り(プログラミング工程)では、ソースレビューと単体テストの両面で 残存欠陥密度を見積もることも重要です。
・試験手順書作成の範囲および記述の深さなどは、テストのプロセスの標準として、見 積り時点で決めておくことが必要です。また、テスト戦略ではテストプロセス標準に対 して、テスト対象システムへのテーラリング方針を策定し、見積り前提条件として明文 化するなど、ユーザと合意しておくことが重要です。
・テスト設計においてデータの処理順序を考慮してテストケースの実施順序を決めてお くことは、データの重複性の排除、テスト実施の効率化、テスト環境の共有および結果 確認の容易さなど、テスト効率の向上が期待できるので考慮しておく必要があります。
③ 欠陥をその混入源に一番近いところで発見し、修正コストを最小化し、且つ、出来るだ け早期にシステムの品質についてソフトウェア開発プロジェクトにフィードバックする必 要があります。
・全体レビューやテストを高位レベルテストから低位レベルテストにシフトする。
・最も重要な欠陥をできるだけ早期に、できるだけ安く検出するために、レビューの長所 および弱点、テストの長所および弱点を特定して、レビューの弱点をテストで、テスト の弱点をレビューで補完するように、レビューのレベルとテストのレベルを相互に調整 する。
・テストファースト(9)を実践する。
④ 設計・実装工程でできるだけ欠陥を減少させることに重点を置くべきです。
・検出した欠陥を開発者に早期にフィードバックする。
テストで検出した欠陥によりソフトウェアに内在する弱みの傾向を早く、設計および実 装工程にフィードバックする。
・テストファーストを実践し、要求と設計を確認するために、テストシナリオを用いる。
設計や開発に先立って、ユースケースなどに基づきテストシナリオを作る。これらのテ ストシナリオは、後の段階でソフトウェアのテストに適用されるものでなければならな い。
・テスト担当者のテスト能力を養い、テスト管理者、テスト技法スペシャリスト、技術者 などの職務を持ったテストの専門家を養成し、適切にテスト組織に組入れる。
・「テストできるか?」という質問に答えられるように試験性(10)に留意してシステムを設
(9) アジャイル開発プロセスで用いられている手段ですが、設計または実装に先立って、テスト設 計を行うことによって、これから設計またはプログラム実装するものが満たすべき条件を網羅的 に洗い出すことができます。これは、設計者または開発者の誤解を防ぎ、設計の考慮もれを予防