Recommended
More Related Content
Similar to 【JSTQB_ALTM】シラバス第2章
Similar to 【JSTQB_ALTM】シラバス第2章 (20)
【JSTQB_ALTM】シラバス第2章
- 1. 2.1:イントロダクション • Advanced Levelにおける「テストマネージャ」の定義 • 職名や職務レベルが組織ごとに異なることを考慮し、 下記職種の総称をテストマネージャとする • テストマネージャ • テストリーダー • テストディレクタ
- 2. 2.2:状況に応じたテストマネジメント ・テストマネージャの責任 • リソース（要員・ソフトウェア・ハードウェアなど）を活用して 付加価値をもたらすプロセスを実行すること • プロセス＝テスト活動 • テスト活動が付加価値をもたらすには？ • PJ または プロダクト全体の成功に貢献すること • 深刻な故障を防ぐこと →テストマネージャは上記に基づいて、テストプロセスを 計画＆コントロールしていく
- 3. 2.2.1:テストステークホルダーについて • テストステークホルダーとは？ • 「テスト活動/成果物」または「プロダクトの品質」に関心を持つ人 1. 開発者、開発リーダー（マネージャー）、DBアーキテクト • テスト結果に応じて対応する必要がある 2. マーケティングアナリスト、ビジネスアナリスト • 搭載する機能及びその品質レベルを決定する 3. 上級管理職、プロダクトマネージャ • テスト結果に基づいて意思決定を行う 4. プロジェクトマネージャ • （テストマネージャと協力して）テストの計画とコントロールを行う 5. テクニカルサポート • ユーザーおよび顧客をサポートする 6. ユーザー • プロダクトorサービスを利用する
- 4. 2.2.1:テストステークホルダーについて • テストプロセスの有効性＆効率性の最適化のため、以下を理解する必要がある 1. ステークホルダとテストの関係性 2. テストチームがステークホルダのニーズに応える方法 3. テストが影響を受ける、開発ライフサイクル活動及び成果物 4. テストが影響を与える、開発ライフサイクル活動及び成果物
- 5. 2.2.2:その他のソフトウェア開発ライフサイクル活動と成果物 • ソフトウェアテストとは？ • 「テスト以外の開発活動で作成された成果物」の品質を評価する活動 • 故に、ソフトウェア開発活動の中の1つに位置づけられる • テストマネージャは、以下を理解してテストを計画/ガイドする必要がある • テスト以外の活動がテストに与える影響 • テストがテスト以外の活動に与える影響
- 6. 2.2.2:その他のソフトウェア開発ライフサイクル活動と成果物 • テストが密接に結びつくソフトウェア開発ライフサイクル活動 # 活動内容 テストとの関係性 1 要求エンジニアリング及び要求管理 ・要件の変更を認識し、変更に応じてテストをコントロールする ・テストスコープおよび工数見積もり時に、要件を考慮する 2 プロジェクトマネジメント ・テストのスケジュール要件とリソース要件をPjMに伝える ・PJ計画の変更に対応する 3 構成管理、リリース管理、変更管理 ・テスト対象プロダクトの配布プロセスの検討 ・TAおよびTTAに対し、バージョン管理の確実な実行を指示 4 ソフトウェア開発と保守 ・欠陥マネジメント（第4章にて説明）への参加 ・テスト対象の配布内容や日程の調整 5 テクニカルサポート ・テクニカルサポート部門への、テスト結果の提供 ・テストプロセス改善のための、運用フェーズでの故障の分析 6 技術ドキュメント作成 ・テストに必要なドキュメントの、タイムリーな提供 ・上記ドキュメント内の欠陥マネジメント
- 9. 2.2.3:テスト活動とその他のライフサイクル活動の連携 • 例）Vモデルのシステムテストにテストプロセスを適用した場合 # PJフェーズ システムテストプロセス 1 プロジェクト計画 テスト計画 2 要求仕様 テスト分析・設計 3 システムおよびアーキテクチャ設計仕様 4 コンポーネント設計仕様 5 コーディング・コンポーネントテスト テスト実装活動 6 コンポーネントテスト 7 コンポーネント統合テスト 8 システムテスト テスト実行 テスト終了基準の評価および結果のレポート 9 システムテスト終了後 （受入テスト） テスト終了作業
- 10. • テスト実行およびレポートは、使用する開発モデルの影響を受ける（1/2） • 例）イテレーティブモデルの場合 • 次イテレーション開始前に以下を行うことが効率的 • 現イテレーションの、完全なテストレポートの作成 • イテレーション前のレビューセッション • 各イテレーションをミニPJとして扱うことで、前イテレーションで発生 した事象（課題）について修正と調整を行える • ただしイテレーションは時間的制約があるため、この工数を省くの が合理的な場合がある • とはいえ課題を早期に発見/修正しなければ、再発の可能性も 2.2.3:テスト活動とその他のライフサイクル活動の連携
- 12. • PJや組織によっては、Foundation Levelで定義されたテストレベルに加えて、 以下のようなテストレベルを定義できる ※赤字部 • 単体テスト • 統合テスト • システムテスト • 受入テスト • ハードウェア-ソフトウェア統合テスト • システム統合テスト • フィーチャ相互作用テスト • 顧客プロダクト統合テスト 2.2.3:テスト活動とその他のライフサイクル活動の連携
- 13. • 各テストレベルで明確にする必要があるもの 1. テスト目的 2. テストのスコープとテストアイテム 3. テストベース（＆カバレッジ測定手段） 4. 開始基準/終了基準 5. テスト成果物 6. 適用可能なテスト技法 7. 測定指標やメトリクス 8. テストツール 9. リソース 10.責任者 11.（組織や標準への準拠） 2.2.3:テスト活動とその他のライフサイクル活動の連携 全テストレベルで明確に定義し、 テストレベル間のギャップ（重 複・漏れ）を避けるのがベスト
- 14. 2.2.4非機能テストのマネジメント • 非機能テストを行わないと、リリース後に深刻な品質問題が検出される可能 性がある • しかし費用がかかるため、リスクや制約に基づいて、 実行する非機能テストを選択する必要がある • 非機能テストにはさまざまな種類がある • 特定のアプリに全ての非機能テストが適しているとは限らない
- 15. 2.2.4非機能テストのマネジメント • テストマネージャが、非機能テスト計画に必要な知識を 持っていない可能性もある • その場合、テスト計画の一部をTTA（or TA）に委任する必要がある • 委任の際は、以下を考慮してテスト計画する様指示する 1. ステークホルダの要件 2. 必要なツールの使用 3. テスト環境 4. 組織的要因 5. セキュリティ
- 16. 2.2.4非機能テストのマネジメント • テストマネージャのその他の重要な考慮事項 • 「非機能テストを開発ライフサイクルに統合する方法の検討」 • 機能テスト完了後→非機能テストの流れは一般的に誤り • Why？→重要な非機能欠陥の検出が遅れる可能性があるため • 故に、リスクに応じた優先度付け/順序決めの必要がある • イテレーティブライフサイクルにおける非機能テスト • 期間が「単一イテレーション」＜「 非機能テスト設計＆実装」 の場合、非機能テストを、イテレーションとは独立した活動と して整理する必要がある
- 17. 2.2.5 経験ベースのテストのマネジメント • 経験ベースのテストのメリット • 他の技法では見逃す場合がある欠陥を効率的に検出できる • 他の技法の完全性をチェックする役割を果たすことができる • 経験ベースのテストのマネジメントに関する課題（特に探索的テスト） • 課題：テスト中に達成するカバレッジの決定が困難になる • 理由：結果記録の軽量化、テストの最小限な事前準備
- 18. 2.2.5 経験ベースのテストのマネジメント • 経験ベースのテストのマネジメント方法① • テスト作業の分割（テストセッション） • テスト作業を30～120分に分割 • 時間を区切ることで作業を絞り込み、 一定レベルのモニタリングとスケジュールを提供する • 各セッションでは、テストチャータをカバーする • テストチャータを事前にテスト担当者に伝達 • チャータにより、セッションでカバーするテスト条件を示す • 集中力の向上および担当者間の重複の回避が可能に
- 19. 2.2.5 経験ベースのテストのマネジメント • 経験ベースのテストのマネジメント方法② • 従来的な（事前に設計した）テストセッションへの、 「自律的かつ自発的なテスト」の統合 1. 事前に定義した「テスト手順、入力、期待結果」以上のものを探求 する権限を、テスト担当者に付与する 2. テスト実行当日、自律的テストセッションを割り当てる • このようなテストセッションで、欠陥や今後のテスト対象領域 を検出した場合、事前に定義したテストを更新する
- 20. 2.3 リスクベースドテストとその他のテストの優先度付けと工数配分のアプローチ • テストマネジメントの普遍的な課題 • テストの適切な選択、割り当て、優先度付け • テスト作業の有効性＆効率性の最適化のためのテストケースの順序付け • 「リスクの識別と分析」が、この課題の解決に役立てることができる
- 21. 2.3.1 リスクベースドテスト • リスクとは？ • 悪い（望ましくない）結果やイベントをもたらす可能性 • リスクの特徴 • いつでも発生しうる • 顧客、ユーザー、ステークホルダたちの 「プロダクト品質」 or 「PJ成功」に対する認識に悪影響を与える
- 22. 2.3.1 リスクベースドテスト • リスクは大きく2つに分けられる 1. プロダクトリスク（or品質リスク、プロダクト品質リスク） • プロダクト品質に影響が及ぶリスク • 例）バグ 2. プロジェクトリスク（or計画リスク） • プロジェクト成功に影響が及ぶリスク • 例）リソース不足
- 23. 2.3.1 リスクベースドテスト • リスクは大きく2つに分けられる 1. プロダクトリスク（or品質リスク、プロダクト品質リスク） • プロダクト品質に影響が及ぶリスク • 例）バグ 2. プロジェクトリスク（or計画リスク） • プロジェクト成功に影響が及ぶリスク • 例）リソース不足 ↑ リスクベースドテストで着目するもの
- 24. 2.3.1 リスクベースドテスト • リスクベースドテストでは「プロダクト品質リスク分析」にて 品質リスクを識別して評価する • テストチームは、品質リスクの軽減のためにテストを行う • 「品質」に含まれるもの • 顧客、ユーザー、ステークホルダの満足度に影響するもの • 影響するもの＝機能、動作、特性、属性
- 25. 2.3.1 リスクベースドテスト • システムの品質リスクの例 • レポートでの不正な計算 • ユーザー入力に対する応答の遅れ • 画面とフィールド（＝UI）のわかりにくさ • 以下を行うことで、品質リスクを軽減したことになる • リリース前にその欠陥に対応する機会を提供 • テスト条件下でシステムが正しく動作したことの確認
- 26. 2.3.1 リスクベースドテスト • リスクベースドテストの目的 ・「品質リスクレベルを受入可能なレベルに引き下げる」 • リスクベースドテストで行うこと 1. プロダクト品質リスクを使用してテスト条件を選択 2. テスト条件に合わせてテスト工数を割り当て 3. 作成されたテストケースの優先度付
- 27. 2.3.1 リスクベースドテスト • リスクベースドテストを構成する4つの活動 1. リスク識別 2. リスクアセスメント 3. リスク軽減 4. リスクマネジメント • テスト担当者は、プロダクト品質リスクと故障に関する専門性から 1と2に積極的に関わる必要がある
- 28. 2.3.1.1 リスク識別 • 【再掲】リスクベースドテストを構成する4つの活動 1. リスク識別 2. リスクアセスメント 3. リスク軽減 4. リスクマネジメント
- 29. 2.3.1.1 リスク識別 • リスク識別とは？ ・リスクを洗い出す活動 • リスクの識別方法 1. 専門家へのインタビュー 2. 第三者によるアセスメント（評価） 3. リスクテンプレートの使用 4. プロジェクトの振り返り 5. リスクに関するワークショップ 6. ブレインストーミング 7. チェックリスト 8. 過去の経験
- 30. 2.3.1.1 リスク識別 • リスク識別は、プロダクトリスク以外の副産物を生み出すこともある • プロダクトorプロジェクトに関する全体的な疑問点 • 要求仕様や設計仕様などの参照ドキュメントの問題 • プロジェクトリスク
- 31. 2.3.1.2 リスクアセスメント • 【再掲】リスクベースドテストを構成する4つの活動 1. リスク識別 2. リスクアセスメント 3. リスク軽減 4. リスクマネジメント
- 32. 2.3.1.2 リスクアセスメント • リスク識別後に、リスクアセスメントを開始する • リスクアセスメントでやること 1. 識別したリスクの調査、分類 • 各リスクを、性能、信頼性、機能性などのタイプに分ける 2. 各リスクに関連する可能性や影響の判定 • 顕在化の可能性 • 顕在化した場合の影響 3. 各リスクのその他の特性の評価 4. リスク所有者の割り当て
- 33. 2.3.1.2 リスクアセスメント # 「可能性」に対する要因 （リスク発生しやすくなる） 「影響」に対する要因 （リスク発生時の影響が大きくなる） 1 技術及びチームの複雑性 影響を受けるフィーチャの使用頻度 2 チーム内の衝突 ビジネス目標の達成に対するフィーチャの重要性 3 供給者側との契約の問題 イメージの悪化 or 業務の喪失 4 ツールと技術 財政的、環境保護的、社会的損失or責任の可能性 5 劣悪なマネジメント orリーダーシップ 民事上または刑事上の法的拘束 6 リソースやマネジメントのプレッシャー 妥当な回避策の欠如 7 早期な品質保証活動の欠如 故障の判明による否定的な評判 8 高い変更率、初期欠陥率 安全性 • リスクの「可能性」＆「影響」それぞれに対する要因
- 34. 2.3.1.2 リスクアセスメント • リスクレベルは、定量的または定性的に評価できる（1/4） • 「可能性」「影響」が定量的に評価できれば、2つを掛け合わせることで 定量的なリスク優先度値を計算できる • しかしリスクレベルは通常、定性的である • 「可能性」のパーセンテージや「影響」の金額の表現は難しい • だからといって、「定性評価＜定量評価」というわけではない • 定量評価を不適切に使用すると、実際のリスクに対する理解とリス クマネジメントの度合いを誤ってしまう
- 35. 2.3.1.2 リスクアセスメント • リスクレベルは、定量的または定性的に評価できる（2/4） • リスクレベルの定性評価の活用方法 • 定量評価と組み合わせる（掛け算or足し算） 例）
- 36. 2.3.1.2 リスクアセスメント • リスクレベルは、定量的または定性的に評価できる（3/4） • 定量×定性評価によって算出された「総合的なリスクスコア」は リスク優先度値として示す場合がある • しかし、この数字は順序尺度としての、 定性的かつ相対的な評価点として解釈すべきである
- 37. 2.3.1.2 リスクアセスメント • リスクレベルは、定量的または定性的に評価できる（4/4） • 「可能性」と「影響」は、ステークホルダの主観に依存する • 故に、リスクレベルの意見がステークホルダ間で異なる場合がある • それでも（何らかの方法で）リスクレベルの合意が必要 • また、リスクスコアがテストのガイドとして使えるよう、 リスクレベルが正しい範囲に適用されていることのチェックが必要 そうでなければ、リスクレベルはリスク軽減活動のガイドとして機能しない
- 38. 2.3.1.3 リスク軽減 • 【再掲】リスクベースドテストを構成する4つの活動 1. リスク識別 2. リスクアセスメント 3. リスク軽減 4. リスクマネジメント
- 39. 2.3.1.3 リスク軽減 • リスクレベルがテストに与える影響 # 影響を受けるもの 説明 1 テスト開発と実行の工数 ・高リスク→精緻なテスト技法を活用（ペアワイズなど） ・低リスク→精緻でないテスト技法を活用（同値分割など） 2 テスト開発と実行の優先度 「リスクレベルに基づいたテスト技法やカバレッジの程度」を規 定している安全保障基準もある 3 テストに関する意思決定 ・PJ成果物（テスト含）のレビューの適用 ・テストの独立性の度合い ・テスト担当者に求められる経験度合い ・確認テストと回帰テストの実行度合い
- 40. 2.3.1.3 リスク軽減 • テストチームはPJ期間中、品質リスクやレベルに影響する 追加情報がないかをウォッチする必要がある • 品質リスク分析の調整とそれに伴うテストの見直しを定期的に行う • 主な調整内容 • 新しいリスクの識別 • 既存リスクレベルの再評価 • リスク軽減活動の有効性の評価
- 41. 2.3.1.3 リスク軽減 • プロダクトリスクは、テスト実行前に軽減が可能 • 例）リスク識別時、要件に関する問題を検出した • リスク軽減活動として、要求仕様の徹底的なレビューを実施 • より少ないテストで残存する品質リスクを軽減できる（可能性 がある）
- 42. 2.3.1.4 ライフサイクルにおけるリスクマネジメント • 【再掲】リスクベースドテストを構成する4つの活動 1. リスク識別 2. リスクアセスメント 3. リスク軽減 4. リスクマネジメント
- 43. 2.3.1.4 ライフサイクルにおけるリスクマネジメント • リスクマネジメントは、ライフサイクル全体で行うのが理想 • テストポリシーや戦略ドキュメントがある場合、以下の記述が必要 1. プロダクト/プロジェクトリスクを テストでマネジメントする包括的なプロセス 2. リスクマネジメントを全テスト段階にどのように統合し、 どのように影響を及ぼすか
- 44. 2.3.1.4 ライフサイクルにおけるリスクマネジメント • 「リスクに対する認識が全体に浸透している組織」ができること（1/2） 1. テストフェーズ以外でもリスクマネジメントを行う 2. 重要なリスクは、初期のテストレベルで対処する • 「性能」が主な品質リスク領域とした時、性能テストをシステムテ ストの早期に実行するだけでなく、単体テストでも実行する など 3. リスクの識別だけでなく、リスクの原因や顕在化時の結果も識別する • 発生した欠陥に対しては原因分析を行い、欠陥の早期予防のために プロセスを改善する 4. リスクの軽減は、開発ライフサイクル全体を通じて行う
- 45. 2.3.1.4 ライフサイクルにおけるリスクマネジメント • 「リスクに対する認識が全体に浸透している組織」ができること（2/2） 5. リスク分析では、関連する活動を考慮して以下を分析する • システム動作分析 • コストベースのリスクアセスメント • プロダクトリスク分析 • エンドユーザーリスク分析 • 損害賠償リスク分析 6. テストチームがテスト以外でもプロダクト全体のリスク分析に参加する
- 46. 2.3.1.4 ライフサイクルにおけるリスクマネジメント • リスクベースドテストの実行順序パターン • 縦型探索：高リスク→低リスクの順でテスト実行する • 横型探索：高低関係なく、全リスクアイテムを最低1回はカバーする • 縦型横型どちらにしても、全テスト実行前に時間を消費する可能性がある • その場合、残存リスクについて、意思決定を行う • テストの延長 • 残存リスクの移転（ユーザーやCS、運用スタッフへ）
- 47. 2.3.1.4 ライフサイクルにおけるリスクマネジメント • 洗練されたリスクベースドテストがもたらすもの • 「リスクの残存度合いに基づいた、開発状況のモニタリングとコントロ ール」をステークホルダへ提供 • その為には、ステークホルダが理解できる方法で、 テスト結果を報告する必要がある
- 48. 2.3.2 リスクベースドテストの技法 • リスクベースドテストの技法は複数ある • その中には全く非公式なアプローチもある • 例）探索的テストで品質リスクを分析するアプローチ • 欠陥の「影響」よりも「可能性」に、過剰に注目してしまう • テスト担当者のスキル＆経験＆好みに依存する 非公式なアプローチが、リスクベースドテストの利点を 完全に実現することはほとんどない
- 49. • リスクベースドテストの利点を実現するためには... • 「軽量のリスクベースアプローチ」を採用する • 「軽量のリスクベースアプローチ」の一例 • 実用的リスク分析とマネジメント（PRAM） • 体系的ソフトウェアテスト（SST） • プロダクトリスクマネジメント（PRisMa） • 「軽量のリスクベースアプローチ」の特徴 • 非公式アプローチが持つ反応の早さ、柔軟性 • 公式なアプローチが持つ権限や合意形成 2.3.2 リスクベースドテストの技法
- 50. • 軽量のリスクベースアプローチの性質（1/2） 1. 時間とともに進化する • 特に、効率性の問題が重要となる業界でのリスクベースドテストに 関する経験に基づいて 2. 初期のリスク識別＆アセスメントにおいて、クロスファンクショナルな ステークホルダによる関与が前提になる 2.3.2 リスクベースドテストの技法
- 51. • 軽量のリスクベースアプローチの性質（2/2） 3. 以下のケースに最適化している • PJの最も早い段階で導入する場合 • リスク分析の成果物が、（リスク最小化のために）プロダクト仕様 と実装に影響を与える場合 4. 作られた成果物をテスト計画やテスト条件、および後続の テストマネジメント＆テスト分析活動のベースとして使用する 5. 「残存リスクが何か？」を理解できるような テスト結果の報告に役立てられる 2.3.2 リスクベースドテストの技法
- 52. • SSTは、リスク分析の入力のために「要求仕様」が必須 • 要求仕様が提供されない場合は使用不可 • PRisMaやPRAMは、リスクベース＆要件ベース両戦略の併用を推奨 • リスク分析の入力には「要件（仕様）」が必要だが、 ステークホルダの入力だけでも機能する • 要件を入力として使用すると、要件の適切なカバレッジを確保できる • しかし、要件からは見えないリスクを見逃していないかの確認が必 要（特に非機能領域） 2.3.2 リスクベースドテストの技法
- 53. • これらの技法の多くは、リスク分析プロセスを「テストアプローチに関する ステークホルダ間の合意形成手段として使用すること」を推奨している • 強力な利点である一方で、ステークホルダが上記プロセスへの参加に時 間を割く必要がある • 参加できない場合、（参加者と非参加者間に）ギャップが発生する • また、ステークホルダが常にリスクレベルに同意するとは限らない • 品質リスク分析活動のリーダーは、最善の合意のため、積極的にス テークホルダと共に作業を行う必要がある 2.3.2 リスクベースドテストの技法
- 54. • 軽量のリスクベースアプローチの特徴 • 「可能性」と「影響」の2要因のみを使用する • シンプルで定性的な判定と尺度を使用する 「柔軟性」＆「広範囲なドメインへの適用性」を持ち、 あらゆる経験やスキルを持つチームで活用可能 2.3.2 リスクベースドテストの技法
- 55. • 公式で重い技法とその特徴 # 技法 特徴 1 ハザード分析 各リスクの根底にあるハザード（危害要因）を識別し、 分析プロセスを上流に拡張する 2 エクスポージャーコスト 各品質リスクアイテム（RI）に対して、3つの要因を決定する 1：RIに関連する故障が発生する可能性 2：RIに関連する故障が本番環境で発生した場合の損失コスト 3：故障をテストするためのコスト 3 故障モード影響解析（FMEA） 品質リスクやその原因および影響を識別し、 重要度&優先度&検出率を割り当てる 4 品質機能展開（QFD） 顧客またはユーザーの要件に対する誤解or不十分な理解から 生じる品質リスクに関連する 5 フォールトツリー解析 実際に観察されたor潜在的な故障を分析対象とし、 根本原因を識別するまで分析を継続する 2.3.2 リスクベースドテストの技法
- 56. 公式度 アプローチ 主な技法 低 高 非公式 ・探索的テスト 軽量 ・実用的リスク分析とマネジメント（PRAM） ・体系的ソフトウェアテスト（SST） ・プロダクトリスクマネジメント（PRisMa） 公式 ・ハザード分析 ・エクスポージャーコスト ・故障モード影響解析（FMEA） ・品質機能展開（QFD） ・フォールトツリー解析 2.3.2 リスクベースドテストの技法 【補足】アプローチごとの公式度と主な技法まとめ
- 57. • リスクベースドテストの「入力」「プロセス」「出力」は、 選択した技法により決まる傾向がある • 一般的な例 # 工程 主な構成要素 1 入力 ・ステークホルダの知識 ・仕様 ・過去のデータ 2 プロセス ・リスク識別 ・リスクアセスメント ・リスクコントロール 3 出力 ・品質リスク ・入力ドキュメントにて検出した欠陥 ・リスクアイテムに関連する疑問点や問題 ・PJリスクの一覧 2.3.2 リスクベースドテストの技法
- 58. • リスクベースドテストの成功のために最も重要なこと • 「適切なチームがリスク識別とアセスメントに関与すること」 • ステークホルダは「プロダクト品質の構成要素」について独自の理 解があり、「品質」に関して独自の優先度と関心事を持っている • ステークホルダは「ビジネス」「テクニカル」の2枠に分類される # ステークホルダ種別 主なロール 特徴 1 ビジネスステークホルダ ・顧客 ・ユーザ ・運用スタッフ ・テクニカルサポートスタッフ ・顧客やユーザを理解している ・ビジネスの観点からリスクを評価できる 2 テクニカルステークホルダ ・開発者 ・DB管理者 ・ネットワーク管理者 ・ソフトウェアが失敗に至る過程を理解している ・技術的な観点からリスクを評価できる 2.3.2 リスクベースドテストの技法
- 59. • 「何がリスクアイテムに該当するか」にステークホルダ間の合意は不要 • 「リスクである」と認識したものがリスクアイテムになる • ただし、リスクレベルの評価に関してはステークホルダ間の合意形成が必要 • 例）「可能性」と「影響」を評価要因として扱う場合、 それらに対して共通の評価方式を決める必要がある • 全ステークホルダが同じ尺度を活用し、「可能性」と「影響」 について単一の評価がなされるようにするため 2.3.2 リスクベースドテストの技法
- 60. 2.3.2 リスクベースドテストの技法 • ステークホルダが品質リスク分析プロセスに適切に関与することで テストマネージャが得られる利点 • 「要件が不明瞭or不足しているPJでも、リスクを識別できる」
- 61. 2.3.2 リスクベースドテストの技法 • リスクベースドテスト終了時に「利点をどれだけ実現できたか」を 測定する必要がある • 【確認方法】 • メトリクス（データ）の分析、もしくはチームへのヒアリング • 【確認内容】 • 重要度「低」の欠陥より、重要度「高」の欠陥を多く検出したか • テスト実行期間の早期に、重要な欠陥のほとんどを検出したか • テスト結果を、リスクの観点でステークホルダに説明できたか • SKIPしたテストがあった場合、そのテストは実行したテストよりも 関連するリスクレベルが低かったか
- 62. 2.3.2 リスクベースドテストの技法 • テストマネージャは長期にわたり、以下を行う必要がある • 品質リスク分析プロセスの改善 • メトリクスに関する、改善目標の設定 • テストマネージャは以下の関係を慎重に考慮する必要がある • メトリクス • テストチームが達成するべき目的 • 「成功基準や特定のメトリクスに基づくマネジメント」によって生じる 行動
- 63. 2.3.3 テストを選択するためのその他の技法 • リスクベースドテスト以外の代替技法 1. 要件ベースドテスト 2. モデルベースドテスト 3. 対処的アプローチ
- 64. 2.3.3 テストを選択するためのその他の技法 • リスクベースドテスト以外の代替技法 1. 要件ベースドテスト 2. モデルベースドテスト 3. 対処的アプローチ
- 65. 2.3.3 テストを選択するためのその他の技法 • 要件ベースドテストについて • 以下の技法を活用する 1. 曖昧性レビュー • 要件の欠陥チェックリストを使用し、 要件の曖昧性の識別及び除去を行う 2. テスト条件分析 • 要求仕様を読み、カバーするテスト条件を識別する • 要件に優先度がある場合、 それに基づいて工数やテストの優先度を割り当てる 3. 原因結果グラフ • 膨大なテストケースをマネジメント可能な数に減らす • テスト設計時にテストベースの矛盾を識別する
- 66. 2.3.3 テストを選択するためのその他の技法 • 要件ベースドテストについて • 要求仕様が曖昧or不完全or存在しない場合、この戦略を活用できない • 他のテスト戦略を選択する必要がある
- 67. 2.3.3 テストを選択するためのその他の技法 • リスクベースドテスト以外の代替技法 1. 要件ベースドテスト 2. モデルベースドテスト 3. 対処的アプローチ
- 68. • モデルベースドテストについて • システムの実際の使用状況を想定した、ユースケース、ペルソナ、入出力 を組み合わせて活用するアプローチ • 機能面に加え、使用性、相互作用性、信頼性、セキュリティ、性能 もテスト可能 • テスト計画＆分析作業では、利用方法プロファイルを識別し、 テストケースでそれを網羅する • 利用方法プロファイル＝得られる情報に基づいた、 ソフトウェア利用状況の見積もり • 利用方法プロファイルは（リスクベースドテストと同様に） 完全なモデル化はできない可能性がある • 一方で、十分な情報とステークホルダからの入力があれば、 適切なモデルを作成できる 2.3.3 テストを選択するためのその他の技法
- 69. 2.3.3 テストを選択するためのその他の技法 • リスクベースドテスト以外の代替技法 1. 要件ベースドテスト 2. モデルベースドテスト 3. 対処的アプローチ
- 70. • 対処的アプローチについて • テスト実行前の準備を行わない • 提供されたプロダクトに対応することに焦点 • 優先度付と割り当ては動的に行う • バグの偏在を検知すると、さらなるテストを実施する、等 • 他のアプローチの補完として機能する • 単独での採用の場合、バグがあまり発生しない重要領域を見逃す傾向が ある 2.3.3 テストを選択するためのその他の技法
- 71. 2.3.4 テストプロセスにおけるテストの優先度付けと工数の割り当て • テストマネージャは、どのようなテスト技法を使う場合でも それらをプロジェクト＆テストプロセスに組み込む必要がある • 例） • シーケンシャル（Vモデル）の場合 • 要件フェーズにて、テストの選択と工数の割り当てを行い、 最初にテストの優先付けを行う • イテレーティブorアジャイルの場合 • イテレーションごとのアプローチが必要 • テスト計画とコントロールでは、リスク、要件、利用方法プロ ファイルが増大する程度を考慮し対応する
- 72. 2.3.4 テストプロセスにおけるテストの優先度付けと工数の割り当て • テストプロセスごとの注意点（1/4） 1. テスト分析、設計、実装 • テスト計画で決定された割り当てと優先度付けを適用するべき • この情報はテストを進める上でのガイドになるだけではなく、 注意深い分析やモデリングを行う目的で、テストプロセス内（特に 設計と実装フェーズ）で詳細化される 2. テスト実行 • テスト計画で決定した優先度に従って実行すべき • ただし、計画後に得られた情報に基づいて、優先度の定期的な更新 が必要である
- 73. 2.3.4 テストプロセスにおけるテストの優先度付けと工数の割り当て • テストプロセスごとの注意点（2/4） 3. テスト終了基準の評価とレポート（1/2） • テストマネージャは、以下について評価しレポートする必要がある 1. リスク 2. 要件 3. 利用方法プロファイル 4. チェックリスト 5. テストの選択、優先度付けに使用する上記以外の情報 6. 実現された利点、実現されていない利点 7. 対応済みのリスク、未対応のリスク
- 74. 2.3.4 テストプロセスにおけるテストの優先度付けと工数の割り当て • テストプロセスごとの注意点（3/4） 3. テスト終了基準の評価とレポート（2/2） • 必要に応じて、テストの優先度付けに基づいたトリアージを行う • 上記活動の一環として、テストがどの程度完了しているか を測定できる • テストケースと検出した欠陥が関連するテストベース（要件や 仕様）にさかのぼって追跡する
- 75. 2.3.4 テストプロセスにおけるテストの優先度付けと工数の割り当て • テストプロセスごとの注意点（4/4） 4. テスト終了作業 • 以下を評価する必要がある 1. 「ステークホルダ（顧客やユーザ含）のニーズと期待」 に関するメトリクス 1. 成功のための基準 これらのニーズや期待をテストが満たした場合のみ、 テストチームが有効に機能したといえる
- 76. 2.4 テストドキュメントとその他の成果物 • テストドキュメントとは • これらは主に、テストマネジメント活動の一環として作成される # ドキュメント名 記述内容 ① テストポリシー 組織の、テストに関する目的と目標 ② テスト戦略 PJに依存しない、組織の一般的なテスト方法 ③ マスターテスト計画 （プロジェクトテスト計画） 特定のPJに関する、テスト戦略の実装 ④ レベルテスト計画 （フェーズテスト計画） 各テストレベルで実装する特定の活動
- 77. 2.4 テストドキュメントとその他の成果物 • これらのドキュメントの内、どれを準備するかは状況によって異なる • 大規模で正式度の高い組織やPJ • 全ドキュメントを成果物にする場合が多い • 小規模で正式度の低い組織やPJ • 特定のいくつかを成果物にする場合が多い
- 78. • テストドキュメントとは【再掲】 # ドキュメント名 記述内容 ① テストポリシー 組織の、テストに関する目的と目標 ② テスト戦略 PJに依存しない、組織の一般的なテスト方法 ③ マスターテスト計画 （プロジェクトテスト計画） 特定のPJに関する、テスト戦略の実装 ④ レベルテスト計画 （フェーズテスト計画） 各テストレベルで実装する特定の活動 2.4.1 テストポリシー
- 79. 2.4.1 テストポリシー • テストポリシーの記述内容（概要） • 組織がテストを行う理由 • 組織が達成するべき、テストの全体的な目的 • テストポリシーの作成者 • 組織内の上級テストマネジメントスタッフ • テストステークホルダグループの上級マネージャ
- 80. 2.4.1 テストポリシー • テストポリシーの記述内容（詳細） • 組織がテストから得られる価値 • テストの目的（以下例） • ソフトウェアの確信度合いの構築 • ソフトウェアの欠陥の検出 • 品質リスクレベルの軽減 • テストの目的を達成するための、テスト有効性及び効率性の評価方法 • 一般的なテストプロセスの概要（ISTQBなど） • 組織がテストプロセスを改善する方法 • テストポリシーは、新規開発＆保守の両テスト活動に対応する必要がある • 組織全体で使用するテスト成果物や用語の標準として参照することもある
- 81. • テストドキュメントとは【再掲】 # ドキュメント名 記述内容 ① テストポリシー 組織の、テストに関する目的と目標 ② テスト戦略 PJに依存しない、組織の一般的なテスト方法 ③ マスターテスト計画 （プロジェクトテスト計画） 特定のPJに関する、テスト戦略の実装 ④ レベルテスト計画 （フェーズテスト計画） 各テストレベルで実装する特定の活動 2.4.2 テスト戦略
- 82. • テスト戦略の記述内容（概要） • 組織の一般的なテスト方法 • リスクマネジメント • テストレベルへの分割 • テストに関する上位の活動 • 一般的なテスト開始基準と終了基準 • テスト戦略（および、そこに記載されるプロセスや活動）は テストポリシーと一貫している必要がある 2.4.2 テスト戦略
- 83. • 組織やプロジェクトよって適切なテスト戦略は異なる • 開発ライフサイクル、リスクレベル、規制上の要件によっては、 同じ組織でも異なるテスト戦略を採用することもある • 短期向け、長期向けの両方のテスト戦略が必要となる場合がある 2.4.2 テスト戦略
- 84. • 一般的なテスト戦略（1/2） • これらを1つ、あるいは複数組み合わせて使用する 2.4.2 テスト戦略 # テスト戦略 例 内容 1 分析的戦略 リスクベースドテスト テストベースを分析して、カバーするテスト 条件を識別 2 モデルベースド戦略 運用プロファイル 実際の状況に基づいて、システムへの入力や、 システムの動作方法等のモデルを作成 3 系統的戦略 品質特性ベース ISO25000などの、品質標準に関連するテス ト条件を使用 4 プロセス準拠または 規格準拠戦略 FDAの規定の対象となる 医療システムなど 規格委員会または他の専門家達が定義した一 連のプロセスに準拠
- 85. • 一般的なテスト戦略（2/2） • これらを1つ、あるいは複数組み合わせて使用する 2.4.2 テスト戦略 # テスト戦略 例 内容 5 対処的戦略 欠陥をベースにした攻撃 の利用 テストの設計と実装を行わず、テスト対象ソ フトウェアが渡されてから対処する 6 コンサルテーションベ ースの戦略 ユーザ主導のテスト ステークホルダからのインプットにより、カ バーするテスト条件を決定 7 回帰的テスト戦略 テスト自動化 回帰のリスクをマネジメントする技法を使用
- 86. • テスト戦略で示すもの（1/2） • 実行するテストレベル、およびその開始基準と終了基準 • テストレベル間の上記基準の関係（カバレッジや目的の割り振り） • 統合手順 • テスト仕様化技法 • テストの独立性（テストレベルによって異なることがある） • 必須の標準、任意の標準 • テスト環境、ツール • テスト自動化 2.4.2 テスト戦略
- 87. • テスト戦略で示すもの（2/2） • ソフトウェア成果物、テスト成果物の再利用性 • 確認テストおよび回帰テスト • テストのコントロールおよびレポート • テストの測定指標及びメトリクス • 欠陥マネジメント • ソフトウェアの構成管理アプローチ • 役割と責任 2.4.2 テスト戦略
- 88. • テストドキュメントとは【再掲】 # ドキュメント名 記述内容 ① テストポリシー 組織の、テストに関する目的と目標 ② テスト戦略 PJに依存しない、組織の一般的なテスト方法 ③ マスターテスト計画 （プロジェクトテスト計画） 特定のPJに関する、テスト戦略の実装 ④ レベルテスト計画 （フェーズテスト計画） 各テストレベルで実装する特定の活動 2.4.3 マスターテスト計画
- 89. 2.4.3 マスターテスト計画 • マスターテスト計画について • 特定のPJで行う全てのテスト作業を対象とする • 実行するテストレベル、レベル間の関連、テストレベルに対応する テスト活動も含む • テスト戦略の実装方法（テストアプローチ）を記述する • テストポリシーとの整合性が取れている必要がある • 逸脱や例外がある場合、それら（＆それによる影響）も記述する
- 90. 2.4.3 マスターテスト計画 • マスターテスト計画の代表的な内容（一部抜粋） 1. 「テストする」アイテムおよび品質特性 2. 「テストしない」アイテムおよび品質特性 3. テストスケジュールおよび予算 4. テスト実行サイクル及び、ソフトウェアリリース計画との関連 5. テスト担当部署と、他部署との関連性および提出書類 6. 各テストレベル個別の開始基準、終了基準 7. プロジェクトリスク 8. テスト活動の全体的な管理 9. 各テストレベルを実行する責任の所在 10.各テストレベルにおける入力と出力
- 91. 2.4.3 マスターテスト計画 • 1つのテストレベルのみを公式として行うプロジェクトの場合 マスターテスト計画とレベルテスト計画をまとめて記述することが多い • テストは一般的に、PJの他の活動に依存する • その為、他の活動を十分に記述していない場合、これらの活動に関する 内容をマスターテスト計画でカバーすることになる • 例）構成管理プロセスについて書かれたドキュメントがない場合 • テスト対象の受け渡し方法について、テスト計画で定義する
- 92. • テストドキュメントとは【再掲】 # ドキュメント名 記述内容 ① テストポリシー 組織の、テストに関する目的と目標 ② テスト戦略 PJに依存しない、組織の一般的なテスト方法 ③ マスターテスト計画 （プロジェクトテスト計画） 特定のPJに関する、テスト戦略の実装 ④ レベルテスト計画 （フェーズテスト計画） 各テストレベルで実装する特定の活動 2.4.4 レベルテスト計画
- 93. 2.4.4 レベルテスト計画 • レベルテスト計画について • 各テストレベルで実行する特定の活動を記述する • テストタイプごとに記述する場合もある • 主に、マスターテスト計画で触れていない情報を記述する • スケジュール • タスク • マイルストーン • アジャイルPJでは、スプリント（イテレーション）テスト計画が レベルテスト計画の代わりになる
- 94. 2.4.5 プロジェクトリスクマネジメント • PJリスクはリスク分析プロセスで識別できる（スライド46参照） • PJリスクが識別された場合、プロジェクトマネージャに通知し、その指示に従う • ただし一部のPJリスクは、テストマネージャによって軽減可能 1. テスト環境及びツールの準備 2. テストスタッフの調達能力と資質 3. テスト活動に関する標準類、ルール及び技法の欠如
- 95. 2.4.5 プロジェクトリスクマネジメント • PJリスクの主な検出方法 1. テストウェアの早期準備 2. テスト環境の事前テスト 3. プロダクト初期verへの事前テスト 4. テスト開始基準の厳格化 5. 試験性要件の強化 6. プロジェクト成果物の早期レビュー 7. 変更管理への参加 8. プロジェクトの進捗及び品質のモニタリング
- 96. 2.4.5 プロジェクトリスクマネジメント • PJリスクの主な対応方法 1. 予防対策 • リスク可能性＆影響の軽減 2. コンティジェンシープランの作成 • リスク影響の軽減 3. 移管 • リスクを別の部門に移してリスクに対処 4. 受容 • リスクを無視or受入 • それぞれの利点、コストや追加で発生するリスクを加味して 最適なオプションを選択する
- 97. 2.4.6 その他のテスト成果物 • テストでは前述の成果物以外にも様々な成果物を作成する • 欠陥レポート • テストケース仕様 • テストログ • テストマネージャは以下の活動を通じて、 これらの成果物の品質と一貫性を確保する必要がある • 拒否された欠陥レポートの割合のモニタリング • 成果物のテンプレート作成、カスタマイズ • テスト、ログ、レポートで必要になる詳細度合いなどの標準の確立 • 適切な技法と参加者による成果物レビュー
- 98. 2.4.6 その他のテスト成果物 • テスト成果物のテンプレートはIEEE829等の資料に基づいて作成できる • IEEEのドキュメントはどの業界でも使用できるように作られている • これをカスタマイズし、自身の組織で使用できる標準テンプレート を作成するのがベストプラクティス • 【補足】IEEEについて https://ieeexplore.ieee.org/document/4578383
- 99. 2.5 テストの見積り • 「見積もり」とは • PJ活動に対する「コストおよび終了日の近似値」を作ること • 優れた見積もりの特徴 • 経験を積んだ実務者の英知の結集となる • 関連する参加者のサポートも得られる • PJのコスト＆リソース＆タスク＆人についての詳細を提供する • 対象のPJ活動に対し最も可能性の高い「コスト＆工数＆期間」を出す • 近年、見積もりに対するベストプラクティスが確立されてきている • テストの見積もりは、上記プラクティスをテスト活動に適用すること
- 100. 2.5 テストの見積り • テストの見積もりに含めるもの • 第1章「テストプロセス」に出てくる活動全て 1. 計画、モニタリング、およびコントロール 2. 分析 3. 設計 4. 実装 5. 実行 6. 終了基準の評価とレポート 7. 終了作業
- 101. 2.5 テストの見積り • 一般的に「テスト実行」がプロジェクトのクリティカルパスになる • そのため、テスト実行期間は重要な情報になりうる • 「テスト実行の見積もり」の質（精度）に影響するもの • ソフトウェア品質 • 品質が低いor未知数の場合、見積もり作成が難しく、 信頼性に欠けることが多くなる • テスト担当者の、システムに関する精通度合いや経験 • 見積もりに際し仮定がある場合、仮のものとして記述する必要がある
- 102. 2.5 テストの見積り # 考慮すべき要素 備考 1 システムに求められる品質レベル - 2 テスト対象システムのサイズ - 3 過去のPJの履歴データ 他組織の業界データ等を含む場合有 4 テスト戦略、開発プロセスの成熟度、見積もりの正確性 - 5 物理要因 ・テスト自動化ツール ・テスト環境/データ ・開発環境 ・PJドキュメンテーション ・再利用可能なテスト成果物など • 見積もりにおいて考慮すべきもの（1/2）
- 103. 2.5 テストの見積り • 見積もりにおいて考慮すべきもの（2/2） # 考慮すべき要素 備考 6 人的要因 ・上位レイヤーの責務と期待 ・チームのスキル、経験、態度 ・チームの安定性、関係性 ・テストおよびデバッグ環境 ・優れた請負業者などの利用可能性 ・ドメイン知識 7 プロセス、技術、組織の複雑さ、ステークホルダの数 - 8 教育やオリエンテーションの必要性 著しい人員増による 9 使える範囲の限られたテストデータ 時間の影響を受けるデータなど
- 104. 2.5 テストの見積り • 見積もりの方法 1. 直感、推測、および過去の経験 2. ワークブレークダウンストラクチャ（WBS） 3. チーム見積りセッション • ワイドバンドデルファイ 4. 企業の標準および基準 5. プロジェクトの総工数またはスタッフ構成の割合 • テスト担当者と開発者の割合など 6. 組織のデータ蓄積およびメトリクス • 欠陥数、テストケース数、各テストの平均工数など 7. 業界平均および予測モデル • ファンクションポイント、コードの行数、開発者の工数など
- 105. 2.5 テストの見積り • 見積もりは、根拠を添えて管理担当者に送らなければならない • 多くの場合、協議の中で再作成が必要になる • 全ての見積もりが、その時点で利用可能だった情報に基づく • その為、以下のようなことがありうる • 初期段階では十分な情報が利用できない • 時間の経過とともに情報が変化する • 正確性維持のために、新しいor更新された情報に基づき、 見積もりを更新する必要がある
- 106. 2.6 テストメトリクスの定義および使用 • マネジメントの世界にある決まり文句 • 「測定できるものは達成できる」 • 「測定されないものは実行されない」 テストを含むすべての活動で、 適切なメトリクスセットを確立する必要がある。
- 107. 2.6 テストメトリクスの定義および使用 • テストメトリクスのカテゴリ分け # カテゴリ 測定内容 具体例 1 プロジェクトメトリクス プロジェクト終了基準に対する進捗 テスト結果の割合（実行済み、 合格、不合格など） 2 プロダクトメトリクス プロダクトの属性 テスト範囲や欠陥密度 3 プロセスメトリクス テストor開発プロセスの能力 テストで検出された欠陥の割合 4 人的メトリクス 個人orグループの能力 指定されたスケジュール内での テストケースの実施
- 108. 2.6 テストメトリクスの定義および使用 • 人的メトリクスの扱いは慎重に • 誤った活用をすると破滅的な結果となる • テスト担当者への適切な動機付けとアセスメントに関しては第7章 • ALでは特に「プロジェクトメトリクス」に重点を置く • プロダクトメトリクス＆プロセスメトリクスにも関連するため • 詳細はExpert Test Managementシラバス • メトリクスの利用によってできること • 継続的な結果報告 • テスト状況の一貫した追跡
- 109. 2.6 テストメトリクスの定義および使用 • メトリクスは、プロジェクト全体の成功判定に使用する • 故に、以下を入念に考慮する必要がある（1/2） # 考慮事項 内容 1 メトリクスの定義 ・有用なものに限定する必要がある。 ・プロジェクト、プロセス、プロダクトの目的に従って定義しなければ ならない。 ・単一のメトリックでは誤って解釈される可能性があるので、メトリク スの解釈については、すべてのステークホルダからの合意を求める。 ・定義するメトリクスは、適切な数よりも多くなりがち 2 メトリクスの追跡 ・生データからメトリクスを算出するまでを極力自動化する ・時間の経過によりデータが変化する場合、メトリックを定義した段階 で合意した解釈以外の情報が影響していることもある。 ・測定値が期待している値から逸脱する可能性と、その理由を入念に分 析しなければならない。
- 110. 2.6 テストメトリクスの定義および使用 • メトリクスは、プロジェクト全体の成功判定に使用する • 故に、以下を入念に考慮する必要がある（2/2） # 考慮事項 内容 3 メトリクスのレポート ・マネジメントのため、速やかに理解できる情報を提供することが目的 ・特定の時期での「スナップショット」や、時間の経過に伴うメトリッ クの変化を提示することにより、傾向を評価できる。 4 メトリクスの有効性 ・メトリック用に取得された測定値が、プロジェクトの本当のステータ スを反映していなかったり、過度に良い傾向または悪い傾向を示したり することがある。 ・テストマネージャは、データを提示する前に、正確性、およびデータ から読み取れるメッセージについて確認しなければならない。
- 111. 2.6 テストメトリクスの定義および使用 • プロジェクトメトリクスの、主なモニタリング対象（1/2） # モニタリング対象 例 1 プロダクトリスク ・テストの合格により、完全に対応されたリスクの割合 ・一部orすべてのテストが不合格となるリスクの割合 ・テストが完了していないリスクの割合 ・リスクカテゴリで分類されたリスクのうち、対応されたリスクの割合 ・最初の品質リスク分析後に識別したリスクの割合 2 欠陥 ・検出された総数と修正された総数の比 ・平均故障間隔（MTBF）または故障率 ・欠陥のレポートから解決に至るまでのタイムラグの傾向 ・新たな欠陥を発生させた欠陥修正の数
- 112. 2.6 テストメトリクスの定義および使用 • プロジェクトメトリクスの、主なモニタリング対象（2/2） # モニタリング対象 例 3 テスト ・計画、仕様化（実装）、実行、合格、不合格、ブロック、スキップしたテストの総数 ・回帰テストおよび確認テストのステータス（不合格となった回帰テストおよび確認テ ストの傾向および総数を含む） ・計画している1 日当たりのテスト時間と実際のテスト時間との比 ・テスト環境の可用性（計画されたテスト時間のうち、テストチームがテスト環境を使 用できる時間の割合） 4 カバレッジ ・要件および設計要素のカバレッジ ・リスクのカバレッジ ・環境／構成のカバレッジ ・コードカバレッジ 5 確信度合い -（シラバスに記載なし）
- 113. 2.6 テストメトリクスの定義および使用 • メトリクスは、テストプロセス活動にリンクすることができる（1/3） # テストプロセス 主なメトリクス 1 テスト計画 ・リスク、要件、および他のテストベース要素のカバレッジ ・欠陥検出 ・テストウェアの開発とテストケースの実行に関する計画時間と実時間 2 テスト分析 ・識別されたテスト条件の数 ・検出した欠陥の数 3 テスト設計 ・テストケースによりテスト条件を網羅している割合 ・検出した欠陥の数 4 テスト実装 ・構築済みのテスト環境の割合 ・ロードしたテストデータレコードの割合 ・自動化したテストケースの割合
- 114. 2.6 テストメトリクスの定義および使用 • メトリクスは、テストプロセス活動にリンクすることができる（2/3） # テストプロセス 主なメトリクス 5 テスト実行 ・計画したテストケースで、実行、合格、および不合格となったテストケースの割合 ・実行、または合格したテストケースにより網羅したテスト条件の割合 ・レポート、または解決した欠陥の計画数と実際の数 ・達成したカバレッジの計画と実際の比 6 テスト完了基準の 評価 ・計画したテスト条件などの数や結果を、合格・不合格ごとに分類した数 ・発生した欠陥の総数を、重要度、優先度などで分類した数（第4 章を参照） ・変更の発生数、受け入れ数、ビルドした数、テスト済みの数 ・計画上のコスト（or期間）と実際のコスト（or期間）との比 など 7 テスト終了作業 ・実行中に「実施、合格、不合格、ブロック、スキップ」となったテストケースの割合 ・再利用可能なテストケースの割合 ・自動化したテストケースと自動化予定のテストケースの割合 ・回帰テストに統合したテストケースの割合 など
- 115. • メトリクスは、テストプロセス活動にリンクすることができる（3/3） • 一連のメトリクスの活用目的 1. 分析 • テスト結果に基づいて、傾向とその原因を見つける 2. レポート • テストで気づいたことをステークホルダに伝える 3. コントロール • 一連のテスト（orプロジェクト）を全体として見直し、 その結果をモニタリングする 2.6 テストメトリクスの定義および使用
- 116. • テストコントロールについて（1/2） • 【いつやるか】 • テスト進捗レポートによりテスト計画からの逸脱がわかった時 • 【目的】 • プロジェクトorテストが成功に向かうための軌道修正 • 【対応すべきこと】 • 「テストにより生成された情報」の変化 • 例）予期しない機能領域での大量の欠陥 • 「プロジェクトorテスト状況」の変化 • 例）開発遅延に伴うテスト実行期間の短縮 2.6 テストメトリクスの定義および使用
- 117. • テストコントロールについて（2/2） • 【コントロール手段】 • 品質リスク分析、テストの優先度、およびテスト計画の見直し • リソースの追加、またはプロジェクト活動やテスト活動の追加 • リリース日の延期 • テスト終了基準の緩和または厳格化 • プロジェクトの対象範囲（機能および非機能）の変更 • 【必要なこと】 • テストプロセス全体のメトリクスの収集が必要 • その為、テスト計画時に必要な情報を網羅し、 モニタリングでは、成果物に関する全メトリクスを収集する 2.6 テストメトリクスの定義および使用
- 118. 2.7 テストのビジネスバリュー • 優れたビジネスバリューのために、テストの最適化に努める必要がある • 優れたビジネスバリューを提供しないテスト • 過剰なテスト：不合理な遅延、余計なコスト • 過小なテスト：欠陥を漏らしてしまう • 最適なテスト量はこれらの間に存在する • 多くの組織では、何らかの意味で価値あるテストを検討している • しかし、この価値の定量化or明確に記述できるマネージャは存在しない • 多くのテストマネージャ、テストリーダ、テスト担当者は、 テストの戦術的な詳細事項に集中しがち • テストに関連する戦略的な上位の問題は無視する
- 119. 2.7 テストのビジネスバリュー • テストがもたらす価値 定量/定性 詳細 定量的価値 ・リリース前の欠陥の検出 ・テスト実行によるリスク軽減 ・ステークホルダへの情報提供 →プロジェクト、プロセス、ステータス など 定性的価値 ・（品質による）評判の向上 ・予定を立てやすいリリース ・確信度合いの向上 ・法律上の免責 ・生命損失リスクの軽減
- 120. 2.7 テストのビジネスバリュー • テストの定量的価値を測定するための「品質コスト」 • プロジェクトor運用のコストを、4つのカテゴリに分類する ②+③<④の時「テストが優れた価値をもたらしている」と言える # カテゴリ 詳細（例） ① 予防コスト 保守性・セキュリティに優れたコードを記述するような開発者へのトレーニング ② 評価コスト テストケースの記述、テスト環境の構成、要件のレビュー ③ 内部失敗コスト 提供前の、テストまたはレビュー期間中に検出した欠陥の修正 ④ 外部失敗コスト 顧客に提供した欠陥ソフトウェアに関連するサポートコスト ※赤字部→テストにかかるコスト
- 121. 2.8 分散テスト、アウトソーステスト、およびインソーステスト • テスト活動は多くの場合、他の会社や異なる地域のメンバーと行われる テスト活動 詳細 分散テスト 複数の地域で行われるテスト アウトソーステスト PJチームと異なる地域にいるメンバーによって行われるテスト インソーステスト PJチームと同じ地域にいるが、 同僚でないメンバーによって行われるテスト
- 122. 2.8 分散テスト、アウトソーステスト、およびインソーステスト • いずれのテスト活動でも、次の項目に対する要望をまとめる必要がある • 明確なコミュニケーションチャンネル • 使命 • 業務 • 提出書類 • コミュニケーション方法を定義し、非公式なコミュニケーションに頼らない • 定義するべきトピック（例） • 問題のエスカレーション • コミュニケーションされる情報の種類 • 使用されるコミュニケーション情報
- 123. 2.8 分散テスト、アウトソーステスト、およびインソーステスト • 関係するすべてのチームおよび人々が、自分および他グループの 役割と責任を明確に理解し、誤解や非現実的な期待を避ける必要がある • 地域、時間帯、文化、言語の違いが、コミュニケーションや期待との差 異による問題を引き起こしやすくする • これらのテスト活動の全てにおいて、進め方の調整が必要になる • 調整ミスが起こりやすいテスト活動 • 「分散テスト」や「外部組織によるテスト実行時」 • 次のような状況は、特にテスト実行時に大きな問題となりうる • 複数のテストグループがそれぞれ異なった方法を活用 • テストグループが開発グループと異なった方法を活用
- 124. 2.8 分散テスト、アウトソーステスト、およびインソーステスト • 分散テストの場合、テスト作業を各地域に分割することを、 明示的かつ合理的に決定しなければならない • このような決定指針がない場合に、次のことが起こりうる • 最も能力の高いグループが、本来やるべきテスト作業を行わない • 各チームが自分の責任を理解できず、やるべきことを行わなくなる テスト活動のすべてにおいて、各テストチームが 「組織、文化、言語、地理的な境界を越え役割を正しく果たす」 という信用を獲得・維持することが非常に重要
- 125. 2.9 業界標準適用のマネジメント • FL/AL両シラバスにおいて、多くの「標準」を参照している • それらの標準は次を網羅している • ソフトウェア開発ライフサイクル • ソフトウェアテスト • ソフトウェア品質特性 • レビュー • 欠陥マネジメント • テストマネージャは標準について、次を理解する必要がある • 標準および、その使用に関する組織のポリシー • どの標準の使用が必須or必要or有益なのか
- 126. 2.9 業界標準適用のマネジメント • 標準の情報源 適用範囲 標準 説明 例 広 狭 国際標準 主要な作成団体→ISO、IEEE ISO9126（ISO 25000 に改訂中） ISO 12207/15504 IEEE 829 / 1028 国内標準 国際標準を国レベルで適用したもの BS 7925-2 ドメイン固有の標準 国際標準または国内標準を特定のド メインに適合したものや、特定のド メイン向けに作成したもの DO-178B（航空関連システム） Title 21 CFR Part 820（医療システ ム）
- 127. 2.9 業界標準適用のマネジメント • ソフトウェアプロセスに影響を及ぼす標準 • ソフトウェアプロセス改善フレームワーク • CMMI🄬 • プロジェクトマネジメントフレームワーク • PMBOK • PRINCE2🄬 • ITサービスマネジメントに関するフレームワーク • ITIL🄬 • これらのフレームワークでの用語や活動は、ISTQBと異なる場合もある • 選択されているフレームワーク、用語を理解する必要がある
- 128. 2.9 業界標準適用のマネジメント • 標準は専門家グループにより作成される • そのため、専門家の経験と知恵だけでなく、弱点も反映される • 自身の環境に適用される標準が、次のどれであるかの認識が必要 • 公式な標準 • 社内の標準 • 推奨事項 • 複数の標準を使用する場合、その有効性を判断しなければならない • 標準間での矛盾が、プロジェクトの妨げになることもあるため • 特定の標準への準拠が必須な場合、その要件を認識し 適切に準拠し続けることが必要
Editor's Notes
- >TAおよびTTAに対し Test AnalystおよびTechnical Test Analyst の略
- >テスト計画～実装は、PJ計画～プログラミングと重複して進行する テスト計画～実装が、テスト以前の工程とリンクしている ・PJ計画→テスト計画 ・ビジネス＆要求分析→テスト分析 ・ソフトウェア＆DB設計→テスト設計 ・プログラミング→テスト実装
- 非機能テストとは →コンポーネントやシステムで、機能に関係しない属性のテスト。たとえば、信頼性、効率性、使用性、保守性、移植性のテスト。（ISTQB-Glossary）
- >TTA（orTA） テクニカルテストアナリスト、テストアナリスト
- >テストチャータ テスト目的を明記したもの。テスト実施法のアイデアを含む場合もある。探索的テストにて使用する。（ISTQB-Glossary）
- レポートでの不正な計算 →正確性に関する機能リスク ユーザー入力に対する応答の遅れ →効率性と応答時間に関する非機能リスク 画面とフィールドのわかりにくさ →使用性と分かりやすさに関する非機能リスク
- 【Colum】ChatGPTによる解説 「リスク優先度値として示す場合がある しかし、この数字は順序尺度としての、定性的かつ相対的な評価点として解釈すべきである」について ここでいう「リスク優先度数（Risk Priority Number）」は、リスクを評価し優先順位を決めるための指標のことを指します。 一般的に、リスク優先度数はリスクの発生可能性、重大度、検出困難さなど、複数の要素を元に算出されます。 また「序数尺度（ordinal scale）」は、順位や順序を表すための尺度のことです。 例えば、「優、良、可」のような評価や、「高中低」のようなランク付けに用いられます。 したがって、この文章は「リスクスコアは数値として表現されるかもしれないが、それは単純な数値以上の意味を持ち、リスクの相対的な優先順位を示す質的な指標として理解するべきである」 という意味を持っています。
- 実用的リスク分析とマネジメント（PRAM） →Pragmatic Risk Analysis and Management 体系的ソフトウェアテスト（SST） →Systematic Software Testing プロダクトリスクマネジメント（PRisMa） →Product Risk Management
- >クロスファンクショナルなステークホルダによる関与 「ビジネス的＆技術的観点の両方を代表する」ステークホルダによる関与
- >作られた成果物を リスクマトリクスorリスク分析テーブル
- >リスク分析プロセス →主にリスク識別とアセスメント
- >あらゆる経験やスキルを持つチーム 非エンジニアや若手メンバーも含む
- 成功したリスクベースドテストであれば、確認内容に対する回答はポジティブなことが多い
- 【補足】 赤字の部分、ChatGPTによると翻訳内容としては間違っていそう、とのこと 「テストの分析、設計、および実装では、 テスト計画作業で決定された割り当てと優先度付けが適用されるべきである。 慎重な分析やモデリングが行われることは一般的だが、 それらの情報がテストプロセスを進めていくガイドとして活用されないことがよくある。 この問題は、特に設計や実装のフェーズで発生する。」 シラバス原文は以下 —----------------------------------------- During test analysis, design, and implementation, the allocation and prioritization determined during test planning must be applied. It is a common breakdown in the test process for careful analysisand/or modeling to occur, only for that information not to be used to guide the test process goingforward. This breakdown typically occurs during design and implementation. —-----------------------------------------
- FDA：米国食品医薬品局
- FDA：米国食品医薬品局
- >非公式なコミュニケーション ホールでの会話やつきあいなど
- BS 7925-2→the software component testing standard https://ieeexplore.ieee.org/document/883787