テストマネジメント

テストマネジメントとは、テスト計画を行い計画に沿ってモニタリングとコントロールを実施して目的を達成することです。
テストマネジメントは、一般的にテストマネージャーが行います。

テストマネージャーは、リソースを確保して、そのリソース活用してプロセスをコントロールして完了するように導きます。
そのため、テストマネージャーはテストプロセスを中心にソフトウェア開発で必要なライフサイクルや成果物を把握して、そのニーズと状況に応じてテスト計画で準備します
テストマネージャーは以下のようなことも留意します。

ステークホルダー

テストマネージャーは、テストで必要なステークホルダーを識別してステークホルダ毎に対応が必要です。
ステークホルダーと役割を以下に記載します。

非機能テストのマネジメント

テストマネージャーは、非機能テストに注意する必要があります。
非機能テストが計画されていないと、リリース後に深刻な品質問題が検出される可能性があります。
非機能テストにはコストがかかりますので、テストマネージャはリスクと制約にもとづいて選択します。

テストマネージャが専門知識を持っていない場合、テストアナリストやテクニカルアナリストに委任できます。
テストアナリストやテクニカルアナリストには、以下の要員を考慮して委任します。

非機能テストは、リスクに応じて優先度付けし、開発ライフサイクルの早い段階で実行します。
テストの早い段階や開発中に行うこともあります。
イテレーティブ開発モデルでは、各イテレーションでの実施が難しくイテレーションから独立させて実施することもあります。

経験ベーステストのマネジメント

テストマネージャーは、経験ベーステストがテスト実施者の経験に基づいて実施されるため、他の技法では見逃すような欠陥を効率よく発見できることを認識しておきます。
テスト実行範囲が判断できない場合やテスト結果を再現できないことに注意する必要があります。

テストマネージャーは、テストセッションではテストチャータをテスト担当者に伝えます。

リスクベースドテストのマネジメント

テストマネージャーは、リスクマネジメントがメイン業務になります。
リスクマネジメントはライフサイクル全体で行い、テストポリシーや戦略ドキュメントにリスク管理のプロセスを記述し、テスト段階に統合します。
成熟した組織はリスク管理をテスト以外の段階でも実施し、重要なリスクに対処します。リスク分析では、システム動作分析やコストベースのリスクアセスメントなどが含まれ、テストチームをリスク分析に参加させます。

軽量な技法には以下があります。

公式で重い技法には以下があります。

テストマネージャーは、リスクベーステストのマネジメントを成功させるに適切なステークホルダをリスク分析に関与するように調整します。
テストマネジャーは終了時に以下を実施します。

要件ベースドテスト

要件ベースドテストは、曖昧性レビュー、テスト条件分析、原因結果グラフなどで優先度を決める技法を活用できます。
曖昧性レビューでは多くの場合、一般的な要件の欠陥チェックリストを使用することにより、（テストベースの役割を果たす）要件の曖昧性を識別し除去します。

運用プロファイルの作成

運用プロファイルは、ユースケース、ユーザ、入力、および出力を組み合わせて活用するモデルベースのアプローチです。
機能だけではなく、使用性、相互運用性、信頼性、セキュリティ、性能もテスト可能になります。

対処的アプローチ

対処的アプローチは、実行の前にテストの分析作業、設計作業、実装作業をほとんど行わない方法です。
テストチームは、提供されたプロダクトに対する対応に焦点を当てて、欠陥の偏在を検出して検出した欠陥からテストを実施します。
対処的アプローチを単独で使用すると主要な機能の欠陥が検出できないリスクがありますので、他の技法と組み合わせることが推奨されています。

テスト戦略

テストマネージャーが作成するテスト計画書は、テスト戦略に基づいて作成します。
テスト戦略は、長期や短期、組織、プロジェクト、開発モデルによってことなります。
テスト戦略には以下のようなものがあります。

リスクベースドテスト戦略

リスク分析に基づいてテスト条件を識別します。
セキュリティリスクが高い場合、セキュリティテストを重点的に計画します。
性能のリスクが高いは場合は、性能テストを重点的に計画します。

分析的戦略

テストベースを分析して、テスト条件を識別します。
リスクベースドテストや要件ベースドテストがあります。

モデルベースド戦略

システムの動作環境・スペック・負荷などをモデル化して、必要なタスクとテストを抽出します。
運用プロファイルなどがあります。

系統的戦略

ソフトウェア品質特性からテスト条件を作成して使用します。
品質特性ベースがあります。

プロセス準拠・規格準拠戦略

規格やプロセスで定義された手順に従います。

対処的戦略

ソフトウェアを受けとってから実施します。
欠陥ベースがあります。

コンサルテーションベースの戦略

アウトソースなどを利用して、専門家の知識を利用して実施します。

回帰的テスト戦略

テスト自動化などで、回帰のリスクを防ぎます。

テスト見積

テストマネジャーは、見積り技法やテストアナリスト・テクニカルテストアナリストと協力してテスト工数の見積を作成します。
テスト工数の見積りは、テストプロセスの目的を達成できるようにすべてのテストプロセスを小さなタスクに分解して見積もります。
テストプロセスのテスト実行がクリティカルパスで、「コスト」「工数」「期間」を正確に見積もる必要があります。

テストケース数の見積もりは、前提条件や仮定を明記し、見積もりがその時点の情報で作成して、仕様変更などの更新が必要になることも考慮する必要があります。
見積方法として以下があります。

トップダウン見積り

ソフトウェアテスト全体の作業をWBSなどから、詳細な作業に分解して必要な工数を見積もります。

ボトムアップ見積り

ボトムアップ見積りは、テストで発生する成果物の要素を洗い出して、成果物から必要な工数を見積もります。
TPA（Test Point Analysis）やWBSなどがあります。

パラメトリック見積り

パラメトリック見積りは、過去のプロジェクトで作成した見積など何かしらのパラメータを利用して見積る方法です。
メトリクスベースで、利用できるパラメータによって精度が変わります。
ファンクションポイント法やCOCOMO法などがあります。

比率を利用した見積では、開発工数とテスト工数の比率に基づいて見積もることもできます。
イテレーティブなSDLCで過去のイテレーションの平均工数を基に次のイテレーションの工数を予測して見積もります。

外挿

外挿は、ある限られたデータセットから得られたテスト結果をもとに、未知の条件下での性能や結果を推定して見積る方法です。

ワイドバンドデルファイ

ワイドバンドデルファイは、専門家の経験を利用してそこから必要な工数を見積もります。
アジャイルソフトウェア開発では、ワイドバンドデルファイのバリエーションとしてプランニングポーカーがあります。
カードを使用してチームの意見を反映しながら見積もっていきます。

三点見積り

三点見積りは、最良推定値、楽観値、悲観値の3点を利用して必要な工数を見積もります。
見積±誤差を求めることができ、最良推定値を「m」とし、楽観値を「a」とし、悲観値を「b」としたときに以下が計算式になります。

見積=(a+4∗m+b)6
誤差=(b−a)6

最良推定値を「m=6」で楽観値を「a=3」とし、悲観値を「b=15」とした場合は以下になります。

7=(3+4∗6+15)6
2=(15−3)6

7±2人月(5～9人月)と見積もることができます。

テストメトリクス

テストメトリクスは、分析・レポート・テストコントロールで利用します。
メトリクスの測定手順は以下です。

1

目標設定

測定するメトリクスの目標値を設定します。

2

データ収集

テストプロセス中に必要なデータを収集します。

3

データ分析

収集したデータを分析し、メトリクスの値を計算します。

4

レポート作成

分析結果をレポートにまとめ、結果を可視化します。

5

改善提案

メトリクスの結果を基に、テストプロセスの改善提案を行います。

テストの進捗がメトリクスから遅延していると判断した場合、リソースの追加やリリース日の延期やテスト終了基準の緩和などのテストコントロールが必要です。
テストメトリクスは以下のカテゴリに分類されます。

テストメトリクスは少なくても多くても良いわけではなく、必要なものを取得して不要なものは取得しないことが大切です。
テストマネージャがテストメトリクスを取得するときに考慮すべきことを以下に記載します。

テスト進捗のモニタリングには以下があります。

テストプロセス毎で必要なメトリクスを以下に記載します。

テストのビジネスバリュー

テストマネージャは、過剰または過少とならないようにテスト実施数を見極める必要があります。
テストは、組織・プロジェクト・運用に対して定量的と定性的の両面で価値をもたらします。
具体的には以下になります。

テストマネージャーは、品質のコストを意識する必要があります。
同じ欠陥であれば、プロセスの早い工程で見つかったほうが対応するコストが少なくすみます。
リリース後に発見した欠陥を対応するコストは非常に高くなります。
品質コストでは、以下の4つのカテゴリに分類されます。

優れたコストやROIなどコストの計算式を以下に記載します。

評価コスト+内部失敗コスト<外部失敗コスト
テスト欠陥の平均コスト=(テストで検出した欠陥テストで検出した欠陥+リリース後に検出した欠陥)×100
リリース後の欠陥の平均コスト=(リリース前のテストで検出した欠陥リリース前のテストで検出した欠陥+リリース後に検出した欠陥)×100
ROI=((リリース後の欠陥の平均コスト−リリース前のテスト欠陥の平均コスト)×テスト欠陥検出コスト)×100

欠陥の検出率として、DDPがあります。
95%が高い値となります。
計算式は以下になります。

DDP=(テストで検出した欠陥テストで検出した欠陥+リリース後に検出した欠陥)×100

フェーズ内阻止

フェーズ内阻止は、ソフトウェア開発プロセスの中で、欠陥が発生したフェーズと同じフェーズ内で検出と修正をすることです。
ISTQBでは、メトリクスと定義されています。
同じ欠陥であれば、プロセスの早い工程で見つかったほうが対応するコストが少なくてすみますので、フェーズ内阻止が行えるようにテストマネジャーはコントールします。

分散テスト、アウトソーステスト、インソーステスト

プロジェクトが大きなテストでは、外部への委託など(アウトソースやオフショア対応）で、地域、時間帯、文化、言語の違いによるコミュニケーションの問題が発生します。
テストマネージャーは、テストチームが連携できるようにマネージメントすることが重要になります。

分散テスト

テスト活動が複数の地域で行われる場合

アウトソーステスト

プロジェクトチームが複数の地域にいて、同じ企業ではない

インソーステスト

プロジェクトチームは同じ地域に存在するが、同じ部署ではない

業界標準適用のマネジメント

テストマネージャーは業界標準の理解も必要です。
テスト計画書など業界標準のテンプレートも用意されています。
業界標準の一覧を以下に記載します。

国際標準

国際的な標準を目指す

国内標準

国際標準を国レベルで適用したものなど

ドメイン固有の標準

国際標準や国内標準を特定のドメインに適合

ISO（国際標準化機構）

各国の標準化機関で構成され、多くのソフトウェアテスト標準を推進

ISO 9126

ISO 9126は、ソフトウェアの品質を評価するための国際標準規格です。ソフトウェア品質を6つの主要な特性に分けて定義し、各特性に対して詳細な評価基準を提供します。機能性、信頼性、使用性、効率性、保守性、移植性の6つです。

ISO 12207

ISO 12207は、ソフトウェアライフサイクルプロセスに関する国際標準のフレームワークです。ソフトウェアの取得、供給、開発、運用、保守に至る一連のプロセスを標準化し、効率的かつ効果的なソフトウェアライフサイクル管理を支援します。

ISO 15504

ISO 15504は、プロセス評価モデルと呼ばれるソフトウェアプロセスの評価に関する国際標準です。この規格は、ソフトウェアプロセスの成熟度や能力を評価し、改善するための枠組みを提供します。

ISO 25010

ISO 25010は、ソフトウェア製品の品質と品質モデルに関する国際規格です。

IEEE（Institute of Electrical and Electronics Engineers、電気電子学会）

IEEEは、米国に拠点を置く専門家組織
世界100カ国以上から国の代表が参加

IEEE 829

IEEE 829は、ソフトウェアテストのドキュメントに関する国際規格で、テスト計画、テスト設計、テストケース、テストレポートなどの標準フォーマットを提供しています。

IEEE 1028

IEEE 1028は、ソフトウェアのレビューに関する国際規格です。ソフトウェアの品質向上を目的とした一連のレビュー手順を定義しています。レビューには、インスペクション、テクニカルレビュー、ウォークスルー、マネジメントレビュー、監査のレビュータイプがあります。
レビュータイプ以外にも参加者の役割や開始と終了基準などが記載されています。

IEEE 1044

IEEE 1044は、ソフトウェア障害報告のプロセスと、その障害の分類に関する国際規格です。この規格は、ソフトウェア障害の報告、追跡、分析、および防止のための一貫したアプローチを提供します。障害報告書、障害分類、障害管理プロセスがあります。
「認識」→「調査」→「対応」→「処理」のプロセスで行われます。

BS 7925-2

BS 7925-2は、英国の国内標準で特定の技術ドメイン固有の標準があり、ソフトウェアテスト、ソフトウェア品質、ソフトウェア開発に関連しています。コンポーネントテストに特化しています。

DO-178B（EU版はED 12B）

DO-178Bは航空関連システムでは米国連邦航空局の標準で、民間航空機で使用するソフトウェアに適用されます。この標準は、ソフトウェアの致命度に基づいて構造カバレッジ基準を規定しています。

Title 21 CFR

Title 21 CFRは、医療システムドメインの米国食品医薬品局（FDA）標準で、一定の構造的および機能的なテスト技法を推奨しています。

PMBOK

PMBOKは、PMIが実施しているヨーロッパで一般的に使用しているプロジェクトマネジメントフレームワークです。

PRINCE2

PRINCE2は、ヨーロッパで一般的に使用しているプロジェクトマネジメントフレームワークです。

ITIL

ITILは、ITグループが自分の所属する組織に価値あるサービスを確実に提供できるようにするフレームワークです。

← 開発プロセスの問題
テストマネジメントの問題 →