JSTQB AL テストマネージャ 第2章 750分

JSTQB AL テストマネージャ 第2章

参考

ありがとうございます

• Advanced Level シラバス日本語版 テストマネージャ

• スクエアリング　｜　用語集

• テストマネージャ試験対策勉強会

2.2 状況に応じたテストマネジメント

テストマネージャの責任

• リソースを確保し、活用、付加価値をもたらす

ステークホルダー

• 開発者、開発リーダ、開発マネージャ
• データベースアーキテクト、システムアーキテクト
• マーケティングアナリスト、及びビジネスアナリスト
• 上級管理職、プロダクトマネージャ
• プロジェクトマネージャ
• テクニカルサポート

2.2.2 その他のソフトウェア開発ライフサイクル活動と成果物

2.2.3 テスト活動とそのほかのライフサイクル活動の連携

• シーケンシャルモデル
  • 所定のフェースが完結してから、次のフェーズが始まる
• インクリメンタルモデル（RAD、RUP）
  • テスト実行時には、テストレベルが重複が発生する。
  • 各テストレベルはできるだけ早期開始し、より上位の後続するテストレベルが開始した後にも継続して行う場合
• アジャイル
• スパイラル

要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性となる機能群
（たとえば、信頼性、使用性、設計上の制約など）

追加のテストレベル

• ハードウェアーソフトウェア統合テスト
  • 統合したコンポーネントやシステムのインターフェースや相互作用の欠陥を摘出するためのテスト
• システム統合テスト ⇒　外部連携テスト
  • システムとパッケージを統合するテスト。完成したシステムが外部の要素(他のシステムやネットワークなど)と期待通りに連携・接続して動作するかを確認するテスト。
• フィーチャ相互作用テスト
  • ソフトウェアがもつ複数の特性や機能がぶつかったときに、正しく動作するかを確認するもの
• 顧客プロダクト統合テスト
  • 顧客側で複数のプロダクトを統合してテストすること。個々のプロダクトのシステムテストが終った後に実施されるテストレベルとなる。

各テストレベルでは、以下を明確にする必要がある（抜粋）

• テストの目的
• テストスコープとテストアイテム
• テストベース
• 開始基準、終了基準
• テスト成果物
• テスト技法（どんなやり方でテストするか）
• メトリクス（評価基準）
• リソース（テスト環境等）

テストを実施する個々の要素。テスト対象。

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

「どのように動作するか」を確認するテスト

機能性、信頼性、使用性、効率性、保守性、移植性の、６つのソフトウェア品質特性

• 実行する項目を絞らないとコストがかかる。
• 専門知識を持っていないテスト計画の責任の一部は、テストテクニカルアナリストに委任する
• サイクルが速いアジャイル等では、非機能テストは独立させたほうがよい
  • 実装活動等で時間がかかるため

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

テスト担当者のスキルと直感の他、同様のアプリケーションまたはテクノロジーにおける経験からテストする。

メリット

• 見逃す場合がある欠陥を検出し、完全性をチェックする役割を果たす

デメリット

• テスト中に達成するカバレッジを決定するのが困難
  • 結果記録を軽量にするため。
  • テスト事前準備を最小限にするため

マネジメントする方法
1.テストセッションと呼ばれる30~120分の短時間にテスト作業を分割する
2.従来的な事前に設計したテストセッションに結合する

2.3 リスクベースドテストとその他のテストの優先度付と工数配分のアプローチ

悪いまたは望ましくない結果やイベントをもたらす可能性

2.3.1 リスクベースドテスト

プロジェクトの初期段階からプロダクトリスクのレベルを低減させ、
ステークホルダにその状態を通知するテストの方法。

潜在的な問題がプロダクト品質に及ぶ場合のリスクのこと

潜在的な問題がプロジェクト成功に及ぶ場合のリスクのこと

主な活動

• リスク識別

  • ブレスト、チェックリスト等を使用してリスクを見分ける（品質リスク分析）
  • 副産物として、プロダクト品質リスク以外の問題を検出することがある
    • プロジェクトに関する全体的な疑問点、要求仕様などの参照ドキュメントの問題

• リスクアセスメント

  • リスク分類して、リスクに関連する可能性や影響を判定する
  • 品質特性 ISO　9126、ISO 25000
    • ソフトウェアの品質特性モデル JIS X 0129-1(ISO/IEC9126)

• リスク軽減

  • リスクコントロール：特定のレベルまでリスクを減らす

• リスクマネジメント

  • 成熟した組織では、テストだけでなく様々な段階で行う（性能テストをシステムテストでするのではなく、ユニットテスト及び統合テストでも実行する）。

テストマネージャ試験対策勉強会

リスクレベルを使用してテストの順序付け及び優先度付を行う

2.3.1.4 ライフサイクルにおけるリスクマネジメント

• 縦型探索：高リスクのテストをすべて、低リスクのテストよりも先に実行したり、厳格なリスク順にテストを実行したりする。
• 横型探索：サンプリングアプローチを使用して、識別したすべてのリスクアイテムからテストのサンプルを選択する。

上記どちらを選択してもテストに割り当てた時間を消費してしまう可能性があるため、残りのリスクレベルについててテスト担当者は検討する必要がある。

2.3.2 リスクベースドテストの技法

• 探索的アプローチ
• 軽量なアプローチ
  • PRAM(Pragmatic Risk Analysis and Management)実用的リスク分析とマネジメント
  • SST(Systematic Software Testing)体系的ソフトウェアテスト
  • PRisMa(Product Risk Management)プロダクトリスクマネジメント

上記技法は、次の属性も持っている。

• 常に進化している
• クロスファンクショナルなステークホルダによるチームの広範囲な関与が前提
• リスクマトリクスまたはリスク分析テーブルを、後続のテストマネジメント活動とテスト分析活動のベースとする。
• 「残存リスクは何か」の分析・報告に役立てることができる。

これらの技法の一部（たとえばSSTなど）では、リスク分析への入力として要求仕様が必要となるので、要求仕様が提供される場合以外は使用できない。その他の技法（たとえばPRisMaやPRAMなど）では、リスクベースの戦略と要件ベースの戦略をあわせて使用することを推奨する。

公式で重い技法では、以下のオプションが利用可能

• ハザード分析
• エクスポージャーコスト
• 故障モード影響解析(FMEA)
• 品質機能展開(QFD)
• フォールトツリー解析(FTA)

PRAM(Pragmatic Risk Analysis and Management)

ハザード：危険の原因・危険物・障害物を分析する。

例えば、自転車に乗っている場合にたとえてみと・・・
ブレーキのききが悪い
道がでこぼこ　など、、、
事故を起こす原因になると考えられることが事故の「ハザード」

エクスポージャー（Exposure）は、晒す（さらす）ことや晒されること。
→リスクアイテムの中で一般的な故障が本番環境で発生した（晒される）場合の損失コスト。
　また、このような故障をテストするためのコスト。

製品やシステムの信頼性や安全性を評価し分析する手法
故障モードといわれる故障や不具合を事前に予測し、質の向上・安全性の向上を目指す

FMEAとは「Failure Mode and Effects Analysis」の頭文字からとったもの

故障モードの「故障」とは、失敗、不履行、断線、短絡、折損、摩耗、特性の劣化などのこと

故障モードの「モード」とは、方法、方式、様式、形態などを意味する

【FMEA】故障モード影響解析～事故を未然に防止する手法

FTAとの違いは、FTAが事後的に原因を分析する手法であるのに対して、FMEAは事前に起きる可能性のある故障や不具合を予測して対応することにあります。

システムなどの不具合の原因を分析し、未然の改善を助けるためによく使われる効果的な手法

FTAとは何 - フォールトツリー解析を簡単に説明

顧客のニーズや期待を整理し、技術的にどうすれば、顧客の要望する品質を確保でき、顧客に喜んでもらえるかを明確にする方法

テストマネージャ試験対策勉強会

2.3.3 テストを選択するためのその他の技法

• 方法論的アプローチ
  • 科学の方法（分析・総合，帰納・演繹）への論理的・認識論的反省d
• 対処的アプローチ
• モデルベースのアプローチ

2.3.4 テストプロセスにおけるテストの優先度付と工数の割当

2.4 テストドキュメントとその他の成果物

主なテストドキュメント

• テストポリシー
  • 組織のテストに関する目的と目標を記述する
    • テストの目的を定義する
    • 目的を達成するためのテストの有効性と効率性を評価する方法
    • ベースとして一般的なテストプロセスの概要を記述する
• テスト戦略 参照：テスト戦略
  • プロジェクトに依存しない組織の一般的なテスト方法を記述する
  • 分析的戦略（リスクベースドテストなど）
    • 緊急度が高い分野をやるなど。
  • モデルベースド戦略（運用プロファイルなど）
    • テスト対象から導けるモデルを利用して”抽象テストケース”(テスト設計とテスト実装の間にあるイメージ)を自動的に導くテスト設計からテスト実装の直前までをカバーする手法（イメージ、状態遷移モデルなどからテスト設計するってこと）
  • 方法論的戦略（品質特性ベースのものなど）
  • プロセス準拠または規格準拠戦略
  • 対処的戦略（欠陥を利用した攻撃の利用など）
  • コンサルベースの戦略（ユーザ主導のテストなど）
    • 外部の人やエンドユーザからのアドバイス
  • 回帰的テスト戦略（広範囲の自動化など）
    • 既存のテストの再利用
• マスターテスト計画
  • 特定のプロジェクトに関するテスト戦略の実装について記述する
• レベルテスト計画
  • 各テストレベルで実行する特定の活動を記述する

ソフトウェアが実際に運用される際にどのように利用されるかを確率分布により表現した利用パターン

2.4.5 プロジェクトリスクマネジメント

• プロジェクトリスク
  • プロジェクトを遂行する際に影響を与えるリスク
  • 組織の問題
  • 技術的な問題
  • 供給者側の問題（発注者側）
• プロダクトリスク
  • ソフトウェアやシステムで失敗する可能性のある領域。プロダクトの品質に関する問題。

プロジェクトリスクは、以下で対策する。

• 可能性や影響をへらす予防対策でリスクを軽減する。
• コンティンジェンシープランを作成
• リスクを別部門に移して対処
• リスクを無視、受け入れる

2.4.6 その他のテスト成果物

• 成果物を多数作成するが、成果物の一貫性と品質を確保するのがテストマネージャの役割
• テスト成果物テンプレート、IEEE 829

2.5 テストの見積もり

• テスト実行が一般的にプロジェクトのクリティカルパスとなる
• テストに提供されるソフトウェアの品質も、見積もりで考慮すべき要員
• ボトムアップとトップダウンどちらからでも可能
  • 直感、推測、過去の経験
  • WBS
  • ワイドバンドデルファイ：チーム見積もりセッション
  • 企業の標準、基準
  • プロジェクトの総工数またはスタッフの割合
  • 組織のデータ蓄積及びメトリクス（欠陥数、テストサイクルの数、、、）
  • FP法、コードの行数、見積もった開発者の工数、、、

2.6 テストメトリクスの定義及び使用

テストメトリクスは、以下の１つ以上のカテゴリに分類される。

• プロジェクトメトリクス
• プロダクトメトリクス
• プロセスメトリクス
• 人的メトリクス

実行済み、合格、不合格などのテストケースの割合など、確立しているプロジェクト終了基準に対する進捗を測定する。

テスト範囲、欠陥密度などプロダクトのいくつかの属性について測定する。

テストで検出された欠陥の割合など、テストプロセスまたは開発プロセスの能力を測定する。

指定されたスケジュールでのテストケースの実施など、個人またはグループの能力を測定する。

Advanced Levelでは、プロジェクトメトリクスである、テスト進捗に重点を置く。

テスト進捗の主要要素

• プロダクト（品質）リスク
• 欠陥
• テスト
• カバレッジ
• 確信度合い

プロダクトの包括的な信頼性。
プロダクトが、顧客やユーザーの所期のニーズを満たすものになっているかどうか、顧客やユーザーの期待していた便益が得られるものになっているかどうかの指標。プロダクトの欠陥が収束しているなど、一定の品質が保証されることも、当然含まれる。

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

• 品質コスト
  • 予防コスト
    • 保守性を良くする、開発者のトレーニング
  • 評価コスト
    • レビュー
  • 内部失敗コスト
    • 欠陥の修正
  • 外部失敗コスト
    • 顧客への欠陥ソフトに関するサポート

一般的に、
評価コスト + 内部失敗コスト　＞　外部失敗コスト

4つのカテゴリでコストを判定することにより、テストに対する説得力のあるビジネスケースを作り出すことができる。

プロジェクトのへの投資価値を判断するための情報

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

参照：テストマネージャ試験対策勉強会

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

• ISO 9126:ソフトウェア品質の評価に関する国際規格
• ISO 12207:ソフトウェアのライフサイクル全般についての標準
• ISO 15504:ソフトウェア開発を中心とした工程の評価の枠組み
• IEEE 829:ソフトウェアテストに必要な、テストドキュメントを定義
• IEEE 1028:マネジメントレビュー、テクニカルレビュー、インスペクション、ウォークスルー、監査（Audit）を定義
• PMBOK
• PRINCE2:プロジェクトマネジメントの方法論
• ITIL