5.1 テスト組織　★★

5.1.1 テスト組織と独立性　★★

自分で書いた文章の間違いは、自分では気づきにくいので、間違いを見つけるには、第三者に読んでもらうことが有効。

開発チームとテストチームの関係も同様。

・独立したテスト組織の必要性

ISTQBでは、すべてのテストレベルもしくはいくつかのテストレベルは独立したテストチームが実施するほうが良いとされている。

・独立した組織の形態
  • 同じ開発プロジェクト内の独立したテストチーム
  • 同じ会社内にある独立したテストチームで、プロジェクトマネージャや上位管理者の直属組織
  • 顧客、ユーザコミュニティから派遣された独立したテストチーム
  • ユーザビリティ、セキュリティ、標準準拠(ソフトウェアが標準や規定に準拠していることを認定する)など、ある特定のテストタイプを行う独立したテストのスペシャリスト
  • 組織外の独立したテストチーム
・独立したテストの利点と欠点

メリットは以下。

  • 先入観がないため、開発担当者と異なる視点で欠陥を見つけられる
  • システムの仕様策定中や実装中に想定通りかを検証できる

デメリットは以下。

  • 開発チームから隔絶されている（完全に独立の場合）
  • 開発担当者の品質に対する責任感が薄れる
  • 独立したテストチームは、ボトルネックと見られたり、リリース遅延のために避難されがちである

5.1.2 テストリーダとテスト担当者の作業　★

テストリーダ：テストの計画やコントロールを担う

テスト担当者：テストの実務的な活動や作業を実施する

・テストリーダの役割

プロジェクト全体を考慮して、テストの計画を立案し、テストの活動状況のモニタリング、コントロールを実施する。

以下の担当者が担う。

  • プロジェクトマネージャ
  • 開発マネージャ
  • 品質保証マネージャ
  • テストグループのマネージャ

代表的な作業は以下。

  • テストポリシーを含む、テスト戦略やテスト計画など、どのようなテストを実施するのかを定義する。プロジェクトマネージャやその他のプロジェクトのステークホルダと調整しながらテスト系アックを立てる
  • プロジェクトのテスト戦略や組織のテストポリシーの策定、およびレビューを実施する
  • テストの観点から、テストプロセスの提案などを通じてプロジェクトの他の活動(たとえば、ビルド計画など)に貢献する
  • プロジェクトの背景を考慮し、テストの目的とリスクを理解してテストを計画する。これにはテストアプローチの選択、テストにかかる時間、工数、コストの見積り、資源の獲得、テストレベルやテストサイクルの定義、インシデント管理の計画を含む
  • 常にプロジェクトの状況を把握しながら、プロジェクトの状況を考慮して、テストの仕様化、準備、実装、実行を開始し、テスト結果の測定と終了基準を満たしていることの確認を行う
  • 常にプロジェクトの状況を把握しながら、テスト結果やテストの進捗に基づいて計画を必要に応じて修正し、問題を補正するために必要なあらゆる対策を取る
  • テスト対象の仕様とテストの仕様書やテストの実行結果など、トレーサビリティを向上させるため、テストウェアの十分な構成管理を検討してセットアップする
  • テストの進捗を計測や、テストや対象ソフトウェアの品質を検証するため、適切なメトリクスを導入する
  • 自動化の利点や欠点を把握して、どんな作業をどの程度、どのように自動化するかを決定する
  • テストを支援するツールを選び、テスト担当者が使えるようにトレーニングを企画する
  • テスト環境の構築に必要なリソースを管理するステークホルダやプロダクトのマネージャ、開発担当者とテストに適切な環境やリソースを協議しながら、構築するテスト環境及び構築する個数を決定する
  • 適切なタイミングでテスト期間中に収集した情報をベースにテストレポートを書く
・テスト担当者の役割
  • テストリーダが作成したテスト計画をテスト担当者の観点でのレビュー貢献する
  • テスト容易性の観点で、要件、仕様、モデルを分析し、レビューし、評価する
  • テスト戦略や要求に基づいて、テスト仕様を作成する
  • テスト環境のセットアップとテスト実行中の管理を実施する
  • テストの実行に必要なテストデータの入手、および作成をする
  • すべてのテストレベルのテストを実装し、テストを実行してログを取り、テスト結果を評価し、期待した結果との差異を文書化してテストリーダまたはプロジェクトマネージャに報告する
  • 必要に応じて、テストコントロールツールやマネジメントツール、モニタ用ツールを使う
  • テストを自動化する。テストの自動化に開発担当者などエキスパートが必要な場合は、テストチーム以外の人に依頼してもよい
  • 必要に応じて、コンポーネントやシステムの性能を計測する
  • 他の技術者が実施したテストをテスト担当者の観点でレビューする

5.2 テスト計画作業と見積り　★★★

5.2.1 テスト計画作業　★★

日程だけの計画だと計画通りにならない（夏休みの宿題状態）

テストケース実施数やインシデント数の見積りをしない、何をどこまでテストしたら完了とするのか明らかにしないで、納期から逆算した日程だけの計画だと、大抵の計画を守ることはできない。

・テスト計画作業のレベル

大きく分けて、以下2点がある。

  • マスターテスト計画
    • プロジェクト全体のテスト計画。プロジェクト計画書の一部であることもある。
  • 個別のテスト計画
    • システムテスト計画、受入テスト計画といったテストレベルに合わせて作成する場合
    • 性能テスト計画やセキュリティテスト計画といった特定のテストの種類に合わせて作成する場合
・テスト計画書の概要(IEEE Std 829-1998)
  • テスト計画識別番号
    • 文書番号
  • はじめに
    • テストの目的や戦略を明文化
    • テストアイテムをどうテストしていくかを要約する
    • プロジェクト計画書や品質保証計画書など参照先を記述する
  • テストアイテム
    • テスト対象となるソフトウェアのバージョン／リビジョンを記載する
    • テスト環境についても記載する
    • 以下、「テストアイテム」の定義

    • テストを実施する個々の要素。通常、ひとつのテスト対象に対し、多数のテストアイテムがある。

  • テストすべき機能
    • すべてのソフトウェア機能のうち、テストすべき機能をリストアップする
  • テストしない機能
    • テストしないと判断した機能を列挙し、理由を記述する
  • アプローチ
    • どのようなアプローチでテストするのかを記載する
    • 大きくは、品質目標や方針に合わせ、どのようにテストレベルを組み立てるか、各テストレベルはだれが担当するかなど、テストの進め方を記述する
    • 具体的には、実施予定のテストのタイプにはどのようなテスト技法を用いるのか、テストツールは何を用いるのかなどを記述する
    • 以下、「テストアプローチ」の定義

    • あるプロジェクトのためのテスト戦略を実現化したもの。この中には、（テスト実施）プロジェクトのゴールと評価済みリスクを基に決めた決定事項、テストプロセスの開始ポイント、適用するテスト設計技法、テスト終了基準、実施するテストタイプを含む。

  • テストアイテムの合否判定基準
    • テストアイテムごとにテストに合格したか否か、つまりテストを終了してよいかを判断する基準を明示する
  • 中止／再開基準
    • テストの一部またはすべてを中止する際の基準を示す
    • 再開するときの基準も明確にする
  • テスト成果物
    • テストで作成するドキュメント類についてリストアップする
    • テスト計画書もこのリストに含める
  • テストのタスク
    • 準備も含めてテストで必要な作業を列挙する
    • 依存関係のある作業や特殊な技能が必要な作業についても明らかにする
  • 環境要件
    • テストを実施する環境について記述する
    • ソフトウェアが稼働するハードウェア、必要に応じて作業場所についても記述する
  • 責任範囲
    • テストに関わる関係者と各関係者の責任範囲について記述する
  • 要員計画とトレーニング計画
    • テストに必要なスキルを明らかにして要員計画を立てる
    • 必要な技術を身に付けるために必要なトレーニングの計画を立てる
  • スケジュール
    • テストのマイルストーンを決めて、それまでのスケジュールを作成する
    • ツールや施設に使用制限がある場合には、その制約をスケジュールに記載する
  • リスクと対策
    • テストに関わるリスクと対策について記述する
  • 承認
    • この計画を承認する人の名前を記載する
・テスト計画作業

テスト計画を立案するにあたり、以下のような要素を考慮する必要がある。

  • 組織のテストポリシー
  • テストの範囲
  • テストの目的
  • リスク
  • 制限／制約
  • 緊急度
  • テスト容易性
  • 使用するリソース

テスト計画は作成したら終了ではなく、プロジェクトを進めながら育てるもの。よって、テスト計画作業はプロジェクトが継続し続ける限り継続される活動で、すべてのライフサイクルプロセスで活動を行う。

テスト実施中もテスト計画にフィードバックし、リスクの変化を認識しつつスケジュールなどを調整する。

5.2.2 テスト計画策定　★★★

システム全体に対するテスト計画と、システムの一部に対するテスト計画がある。

両者に共通の活動には以下がある。

  • テストのスコープとリスクを特定し、テストの目的を識別する
  • テストに対する包括的なアプローチの定義。アプローチの中には、テストレベルの定義や開始／終了基準の定義も含まれる
  • ソフトウェアライフサイクル（取得、供給、開発、運用、保守）での活動にテスト活動を統合し協調させる
  • 次に挙げる活動をスケジューリングする
    • テスト分析
    • テスト設計
    • テスト実装
    • テスト実行
    • テスト結果の評価
  • 定義した様々な活動に対してリソースを割り当てる
  • テストドキュメントに関して、次に挙げる事柄を決定する
    • テストドキュメントの量
    • 詳細度
    • 構成
    • 使用するテンプレート
  • モニタリングやコントロールするために、次に挙げる項目に対するメトリクスを決定する
    • テストの準備
    • テストの実行
    • 欠陥の解決
    • リスク問題
  • テスト手順の詳細度を決定する。その際、テストの準備や実行の実現性を確保するのに十分な情報を得るために、どの程度テスト手順を詳細化すればよいのかも検討する

5.2.3 開始基準　★★

代表的な開始基準は以下。

  • テスト環境がテストに利用できるように準備してあること
  • テストツールがテストに利用できるように準備してあること
  • テスト可能なコードが利用できるようになっていること
  • テストデータが利用できるようになっていること

5.2.4 終了基準　★★

代表的な終了基準は以下。

・カバレッジで測定できるもの

コードカバレッジ、要件や仕様に対するテストカバレッジ、リスクに対するテストカバレッジなどのように、「全体」の値が分かり、どこまでテストを実施したかが分かれば終了基準を示すことができる。

・欠陥密度や信頼性の見積値

例えば、信頼度成長モデルを使って終了基準にする。

・コスト

テストにかけるコストがなくなったら終了という基準。品質とコストのバランスを考慮した結果としてコストを優先した場合が考えられる。

・残存リスク

例えば、未修正の欠陥やカバレッジの不足領域がどの程度あるかを基準にする。

・出荷時期などのスケジュール

出荷時期が来たら、それでテストを終わらせるという基準。納期と品質のバランスを考慮した結果として納期を優先した場合が考えられる。

5.2.5 テスト見積り　★★

テスト工数を見積もるには様々な方法があるが、ISTQBでは以下2つのアプローチを紹介している。

  • メトリクスをベースにしたアプローチ：過去のプロジェクトや類似のプロジェクトのメトリクスや、業界や組織で持っている代表的な値を基にテスト工数を見積もるアプローチ
  • 経験をベースにしたアプローチ：作業の実行者やエキスパートの経験による見積りを基にテスト工数を見積もるアプローチ

両者一長一短なので、できれば両方を見比べるのが良い。

テスト工数を見積もる場合に考慮すべき要素として、次のようなものがある。

・プロダクトの特性
  • テストケースを作成する際の基礎とする仕様(テストモデル、テストベース)やその他の情報の品質
  • プロダクトのサイズ
  • 問題ドメインの複雑性
  • 信頼性やセキュリティに対する要求
  • ドキュメンテーションに対する要求
・開発プロセスの特性
  • 組織の安定度
  • 使用するツール
  • テストプロセス
  • 関係者のスキル
  • 時間のプレッシャー
・テストの出力結果
  • 欠陥の数
  • 修正に要する工数

5.2.6 テスト戦略、テストアプローチ　★★

テストアプローチとは、テスト戦略を特定のプロジェクトに対して策定し組み込むこと。

テスト計画やテスト設計においてテストアプローチを定義する。

テストアプローチは一度策定したら終わりではなく、テストを実施していく過程において改良していく。

主に考慮すべき要素は以下。

  • プロジェクトの状況
  • プロジェクトのリスク
  • 危険性
  • 安全性
  • 使用可能な資源
  • スキル
  • テクノロジー
  • システムの性質(カスタムメイドなのか、COTSなのかなど)
  • テスト目的
  • 法規制

テストアプローチを定めることにより以下が決まる。

  • どのようなテスト技法を採用するか
  • どのようなテストタイプを適用するか
  • 各テストレベルの開始・終了基準をどの程度にすればよいのか
  • テストプロセスをどのように組み立てればよいのか

代表的なテストアプローチを以下に記載する。下記を単独で使用するだけでなく、組み合わせで使用することもできる。

・分析的アプローチ

優先度が最も高い分野を重点的にテストするリスクベースのテストは、このアプローチに含まれる

・モデルベースアプローチ

故障率(例えば信頼性成長モデル)や、使用法(例えば運用プロファイル)に関する統計的情報を使う確率的テストは、このアプローチに含まれる

・方法論的アプローチ

フォールトをベースにしたテスト(例えば、エラー推測、フォールト攻撃)や、チェックリストをベースにしたテスト、品質特性をベースにしたテストは、このアプローチに含まれる

・プロセス準拠／標準準拠アプローチ

ある業界固有の標準に基づいたテストやアジャイルなどのプロセスに基づいたテストは、このアプローチに含まれる

・動的で経験則に基づいたアプローチ

事前に計画するのではなく、発生した事象に対応し、テストの実行と評価を同時に行う探索的テストは、このアプローチに含まれる

・コンサルテーションベースのアプローチ

テストチーム外のビジネスドメインのエキスパートや技術的エキスパートの助言や指導を受けた部分から優先的にテストカバレッジを上げていく方法が該当する

・回帰的アプローチ

既存のテストを再利用したり、回帰テストを高度に自動化したり、標準化されたテストスイートを活用する方法が該当する

5.3 テスト進捗のモニタリングとコントロール　★★

5.3.1 テスト進捗モニタリング　★

策定した計画をモニタリングし、テストを成功へ導くためにコントロールする手法について説明する。

テスト結果の可視化のための、テストサマリリポートも触れる。

テスト進捗モニタリングの代表的なメトリクスは以下の通り。

・テストの準備作業が完了したパーセンテージ
・テスト環境準備で完了したパーセンテージ
・テストケースの実行
・欠陥情報

欠陥密度 = 欠陥の数 ÷ プログラムの規模

・要件、リスク、コードにおけるテストカバレッジ
・プロダクトの品質に対するテスト担当者の主観的な信頼度
・テスト作業のマイルストン
・テストに要するコスト

5.3.2 テストレポート　★★

IEEE Std 829-1998では、テストサマリレポートとして記述すべきアイテムの例として、以下8項目を挙げている。

  • テストサマリレポート識別番号(Test summary report identifier)
  • 要約(Summary)
    • テストで行った作業全般の要約。一目でテスト作業内容がわかるように簡潔に記述する。
  • 変更(Variances)
    • 変更内容を記述する。変更の流れを表すことで、テスト作業のプロセスを反省し、次のテスト計画立案に役立てる。
  • 総合評価結果(Comprehensive assessment)
    • テスト作業自身の評価。テスト計画に沿って行えたこと、うまくいかなかったことを分析して説明する。
  • 結果の要約(Summary of results)
    • テスト結果の要約。発生したインシデントすべてに対して、解決した場合は解決策も含めて要約し、未解決のものは未解決として列挙する。
  • 評価(Evaluation)
    • 各テストケースの実行結果を踏まえ、全体を通した評価を記述する。実行によって発見された製薬内容も記述する。
  • 活動の要約(Summary of activities)
    • 例えば、テスト担当者、規模、作業時間などを記載し、次のテスト計画立案の重要な情報とする。
  • 承認(Approvals)
    • 承認者の名前を記載し、責任の所在を明確化する。

5.3.3 テストコントロール　★★

モニタリングで明らかになった計画との差異を補正し、計画通りに事が進むようにすること。

テストコントロールの例は以下。

・テスト進捗モニタリングの情報をベースに意思を決定する
・あるリスクが発生した場合、（たとえばスケジュール遅延）テストの順位を見直す
・テスト環境の利用の可否状況により、テストスケジュールを変更する
・修正をビルドに反映する前に開発者自身による再テスト（確認テスト）を実施することを開始基準とする

5.4 構成管理　★★

5.4.1 構成管理の定義　★★

構成管理：欠陥のある部品が製品に入り込まないように管理するための仕組み。製品を構成する部品などのリストを作成、管理、維持する。

ISO10007「品質マネジメントシステム-構成管理の指針」で定義されている。

簡単に言うと、「構成管理は、ある時点（バージョン）の製品の部品が一意に特定できるように管理し、記録すること。」

5.4.2 構成管理の目的　★★

構成管理の目的は以下のように定義されている。

『構成管理』の目的は、構成の特定、構成制御、構成状況の記録と報告、および構成監査を行って、作業成果物の一貫性を確立し維持することである。

5.4.3 テストにおける構成管理　★★

テストアイテムのバージョンやテストウェア（テスト計画、テスト手順、テストスクリプト、テスト環境、テスト結果など）を管理する。

上記はすべてバージョン管理し、すべてが関連付けられている状態にしておくことが必要。また、テストアイテム（テスト対象となるソフトウェア）とテストウェアとのトレーサビリティを確立しておくことも大切。

5.4.4 テスト構成管理の対象　★★

例えば管理対象は以下の通り。

  • テスト対象となるソフトウェア
  • ソフトウェアの動作環境（OS、ハードウェアなど）
  • テストウェア（スクリプト、データなど）
  • 欠陥（故障、インシデント）
  • テスト結果
  • ドキュメント（テスト計画書、仕様書、マニュアル、評価仕様書、テスト手順書、報告書など）

テスト対象となるソフトウェアや仕様書などは開発側で管理されているが、テスト担当者側でもバージョン、版番号などをテストウェアと関連付けて記録しておく必要がある。

5.4.5 テスト構成管理の手順　★★

通常の手順は以下の通り。

  1. 構成管理対象を決める
  2. 構成管理方法を決める
  3. 記録を残す
  4. きちんと管理し、必要なときに参照できるようにする

5.5 リスクとテスト　★★

テストにおいて考慮すべきリスクを、プロジェクトリスクとプロダクトリスクに分けて考える。

また、リスクを考慮したテスト設計技法として、リスクベーステストを説明する。

5.5.1 リスクの定義　-

リスクとは、「イベント、危険、脅威、発生する状況等の見込みと、その望ましくない結果、あるいは可能性のある問題」。

5.5.2 プロジェクトリスク　★★

プロジェクトリスクとは、「プロジェクトを遂行する際に影響を与えるリスク」のこと。

ヒト、モノ、カネのどの観点にも潜んでいる。

・ヒト
  • テストを行う組織やメンバー
    • スキル不足やトレーニング不足
    • 人員配置や配置されたメンバーをどう評価するかといった人事や考課に関わる問題
  • テストに関わる他のプロジェクト内外の組織
・モノ
  • ソフトウェア
  • ハードウェア
  • ドキュメント
・カネ

予算および実績コスト、コストを管理するための見積りやスケジュールなど

以下、プロジェクトリスクの例を挙げる。

・スケジュールに関するリスク
・テスト環境整備に関するリスク
・テストマネジメントに関するリスク

5.5.3 プロダクトリスク　★★

プロダクトリスクとは、「ソフトウェアやシステムで失敗する可能性のある領域」とある。

プロダクトリスクの例は以下の通り。

  • 故障の起きやすいソフトウェアの出荷
  • ソフトウェアやハードウェアが個人や会社に対して損害を与える可能性
  • 貧弱なソフトウェア品質特性
  • 貧弱なデータの完全性と品質
  • 予定の機能が動作しないソフトウェア

テストをプロダクトリスクの事前予防策として用いることを「リスクベースのアプローチ」としており、洗い出したリスクに対して以下のように対処する。

・適用するテスト技法を決める
・テストを実行する範囲を決める
・重大な欠陥をなるべく早い時期に検出するため、テストの優先順位を決める
・テスト以外でリスクを減らす方法があるか検討する

5.5.4 リスクベーステスト　★★

リスクベーステストとは、プロダクトが故障を起こし、インシデントとなる可能性を最小限にするために「リスクベースのアプローチ」を取り入れたテスト方法。

そのためには、さらにリスクの分析と評価、リスクの重要度付け、リスク軽減策の策定のようなリスクマネジメントの視点が重要になる。

以下にリスクベーステストの進め方を示す。

  • リスク分析：プロジェクトリスクとプロダクトリスクに分ける

5.6 インシデント管理　★★★

5.6.1 インシデントとは　-

ISTQBの用語集によると、インシデントとは以下のように定義されている。

発生した事象の中で、調査が必要なもの

要するに、期待した結果と実際の結果が異なるということ。

5.6.2 インシデント管理の必要性　-

インシデントの対応が終了するまでのステップは、おおよそ次の通り。

  1. インシデントが発生したことを認識する
  2. インシデントを記録する
  3. インシデントとの原因を調査する
  4. 影響範囲を分析し、インシデントを分類する
  5. 修正が完了するまで待機する
  6. 修正が終わったことを確認する

5.6.3 インシデントの記録　-

インシデントを記録するのはテスト担当者だけでなく、開発担当者や顧客の場合もある。

5.6.4 インシデントレポートの目的　★

ISTQBの用語集によると、インシデントレポートの定義は以下の通り。

発生したあらゆるインシデント（テストの最中に調査を必要とする事象など）を報告するドキュメント

インシデントレポートの目的は以下の通り。

  • 開発担当者やその関係者に対して、システムの動作不良などの問題を明らかにし、原因を特定して解決していくことができるように情報を提供する。
  • テストリーダに対して、テスト実行中のシステムの品質や、テストの進捗を追跡する手段を提供する。
  • テストプロセス改善のためのヒントを提供する。

5.6.5 インシデントレポートの構成　★

IEEE Std 829-1998によるインシデントレポートの構成は以下の通り。

  • テストインシデントレポート識別番号(Test incident report identifier)
  • 概要(Summery)
  • 詳細(Incident Description)
    • 入力(Inputs)
    • 期待される結果(Expected results)
    • 実際の結果(Actual results)
    • 異常(Anomalies)
    • 日時(Date and time)
    • 実行手順(Procedure step)
    • 環境(Environment)
    • 再現手順(Attempts to repeat)
    • テスト担当者(Testers)
    • オブザーバー(Observers)
  • 影響範囲(Impact)

5.6.6 インシデント管理のプロセス　★★★

インシデント管理のプロセスには、以下の2種類があり、それぞれメリット／デメリットがある。

  1. インシデントレポートの状態遷移に着目する場合
  2. インシデントレポートのワークフローに着目する場合

ツールを利用する場合は、1が良い。例を以下に示す。

  • オープン
    • 解決に着手したことを表す
  • 分析／割当
    • レポートの内容を分析し、開発担当者にレポートを割り当て、修正を行う。
  • 却下
    • 開発担当者が調査できない内容、つまり情報が足りなかったり誤った情報が書かれている場合には、レポートを却下する。
  • 再テスト
    • 開発担当者が問題を修正した場合、確認テストを実行する。
  • 失敗
    • テストがうまくいかなかったとき、つまり、問題が解決されていない場合、開発担当者に差し戻す。
  • クローズ
    • 問題が解決されている場合、そのインシデントレポートをクローズする。

Follow me!