JSTQB ch5 テストマネジメント (1/3)

JSTQBテスト技術者

出典: 

5.1 テスト組織

5.1.1 独立したテスト

独立性の度合い

低い順

独立したテスト担当者不在

  • テスト対象について他の誰よりも熟知している開発者自身がテストする
  • 確証バイアスの影響も最も大きくなってしまう

開発チーム、またはプロジェクトチーム内に所属する、独立した開発担当者、またはテスト担当者(開発担当者が同僚の成果物をテストすることもある)

  • よそのチームよりはテスト対象について熟知している
  • 開発者自身よりは確証バイアスの影響が小さくなる
  • 納期やコスト等のプレッシャーからは独立できない

組織内にある独立したテストチームまたはグループで、プロジェクトマネージャーや上位管理者の直属組織

  • QAチームによる評価などはこれ
  • 納期やコスト等のプレッシャーを受けづらくなる

顧客またはユーザーコミュニティから派遣された独立したテスト担当者、または、使用性、セキュリティ、性能、規制/標準適合性、移植性など、ある特定のテストタイプを専門に行う独立したテスト担当者

  • 受け入れの観点でテストを実施できる
  • プロジェクトからの圧力を排除
  • 使用性テストやペネトレーションテスト等、特定の品質要件特化のテストを実施できる

    • 【所感】法的規制のテストもこのたぐいかな

組織外の独立したテスト担当者、オンサイト(インソーシング)またはオフサイト(アウトソーシング)で作業する

  • 完全に独立した視点

テストの独立性の選択

テストレベルにより使い分ける

  • 例: 低いレベルのテスト(コンポーネントテスト等)では、熟知している開発担当者がテストすると成果があがりやすい

開発プロセスにより変わる

  • 例: アジャイル

    • 必要最低限の作業成果物しか作らないことがある
    • この場合、テスト担当者も開発チームの一員としてチームに参加してソフトウェアの情報を共有するとよい
    • 各サイクルの終わりにユーザーストーリーに基づいた受け入れテストをプロダクトオーナーが行うことがある

独立したテストの利点

  • 認知バイアス(特に確証バイアス)の違いによって効果的に欠陥を発見できる

    • ただし、熟知していることの代わりにはならない
  • 作業成果物のレビューにて、ステークホルダーが行った仮定に対して説明要求または反証できる

    • 欠陥の早期検出

独立したテストの欠点

回避可能

  • 情報の入手が困難になる

    • -> 独立と隔絶をはきちがえないようにしよう
  • 独立したテスト担当者がボトルネックとして見られ、チーム間対立をまねく

  • 開発担当者の品質に対する責任感低下

    • -> 開発担当者も低にレベルのテストに参加しよう

5.1.2 テストマネージャーとテスト担当者のタスク

テストマネージャーのタスク

テストプロセスに対して全体的な責任を持ち、テスト活動においてリーダーシップを適切に発揮する

詳細割愛

誰がやるの:

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

大きなプロジェクトではテストリーダーに責任委譲・分割統治する

  • 束ねる人はテストマネージャー、テストコーチ、テストコーディネータ等呼ばれる

テスト担当者の役割

全体的じゃない仕事をする

詳細割愛

誰がやるの: テストレベルによりまちまち

  • コンポーネントテスト、コンポーネント統合テスト: 開発担当者自身
  • 受け入れテスト: ビジネスアナリスト、特定分野の専門家(前述の使用性テストなど)、ユーザ
  • システムテスト、システム統合テスト: 独立したテストチーム
  • 運用受け入れテスト: 運用担当者、システムアドミニストレータ

5.2 テストの計画と見積もり

5.2.1 テスト計画書の目的と内容

テスト計画の種類

  • マスターテスト計画

    • プロジェクト全体のテストを計画
  • 個別のテスト計画

    • テストレベル別の計画(システムテスト計画、受け入れテスト計画、…)
    • テストタイプ別の計画(性能テスト計画、セキュリティテスト計画、…)

テスト計画書の概要(ISP/IEC/IEEE標準:ISO/IEC/IEEE 29119-3)

1. 文書情報
1.1. 概観
1.2. 文書ID
1.3. 発行組織
1.4. 承認権限
1.5. 変更履歴

2. はじめに
2.1. 適用範囲
2.2. 参考文献
2.3. 用語集

3. テストの背景
3.1. プロジェクト/テストサブプロセス
3.2. テストアイテム
3.3. テスト範囲
3.4. 前提と制約
3.5. 利害関係者

4. テストでのコミュニケーション

5. リスク管理表
5.1. プロダクトリスク
5.2. プロジェクトリスク

6. テスト戦略
6.1. テストサブプロセス
6.2. テスト成果物
6.3. テスト設計技法
6.4. テスト完了基準
6.5. 収集されるメトリクス
6.6. テストデータ要件
6.7. テスト環境要件
6.8. 確認テストおよびリグレッションテスト
6.9. テストの中止および再開基準
6.10. 組織レベルのテスト戦略からの逸脱

7. テスト活動および見積もり

8. スタッフ
8.1. 役割、活動、責任
8.2. 雇用ニーズ
8.3. 教育ニーズ

9. スケジュール

単なる「納期から逆算してスケジュール引いたやつ」ではない

範囲・目的、リスクの決定

3.2. テストアイテム
3.3. テスト範囲
3.4. 前提と制約
3.5. 利害関係者

  1. リスク管理表
    5.1. プロダクトリスク
    5.2. プロジェクトリスク

重要度や優先度もスケジュールを組む上で重要な考慮点になる

包括的なアプローチの決定

後述

テストサブプロセスを開発モデルに応じてスケジュール

  1. スケジュール

テストのモニタリングとコントロールのためのメトリクス

6.4. テスト完了基準
6.5. 収集されるメトリクス
6.9. テストの中止および再開基準
6.10. 組織レベルのテスト戦略からの逸脱

予算

  1. テスト活動および見積もり
  2. スタッフ
    8.1. 役割、活動、責任
    8.2. 雇用ニーズ
    8.3. 教育ニーズ

テストアイテムのテスタビリティが低くテストに手間がかかる場合、その手間もスケジュールを組むうえで重要な考慮点となる

テストドキュメントの詳細レベルと構造を決定する

6.2. テスト成果物

テスト活動をソフトウェアライフサイクルでの活動に統合し、協調させる

3.1. プロジェクト/テストサブプロセス

テスト計画書の内容の拡充

プロダクトのライフサイクルにわたって継続する

  • プロジェクト完了後、保守・廃棄されるまで

5.2.2 テスト戦略とテストアプローチ

テスト戦略

プロダクトまたは組織のレベルでのテストプロセスに対する汎用的な考え方

分析的

  • リスクベースドテスト

    • リスクのレベルに基づいてテストを設計し優先度づけ

モデルベースド

何らかのモデルに基づいてテストを設計する

  • ビジネスプロセスモデル
  • 状態モデル
  • 信頼度成長モデル

系統的

事前に定義した一連のテストケースまたはテスト条件を体系的に使用する

  • 企業全体のルックアンドフィール標準

プロセス準拠(標準準拠)

組織内外のルールや標準を使用してテストの分析、設計、実装を行う

指導ベース(コンサルテーションベース)

専門家からの助言、ガイダンス、指示に基づいてテストを行う

  • 組織外部のステークホルダー
  • ビジネスドメインの専門家
  • 技術的専門家

    • 【所感】性能やセキュリティ等かな

所感: 受け入れテストで適していそう

リグレッション回避

  • 既存のテストウェアの再利用
  • 高度に自動化されたリグレッションテスト
  • 標準テストスイートの再利用

対処的

事前に計画を行わない。探索的テストを使用する

テストアプローチ

テスト戦略を特定のプロジェクトやリリース向けにテーラリングしたもの

考慮点いろいろ

  • プロジェクトの複雑さやゴール
  • プロダクトの種類
  • プロダクトリスク分析
  • プロジェクトの状況
  • リスク
  • 安全性
  • リソース
  • スキル
  • 技術
  • システムの性質

    • カスタムメイド
    • COTS
  • テスト目的
  • 法規制

5.2.3 開始基準と終了基準 — 準備完了(ready)の定義と完了(done)の定義

開始基準

例: 次のものが準備されていること

  • テストベース
  • テストアイテム
  • テスト環境
  • テストツール
  • テストデータ
  • その他のリソース

開始基準が満たされないままテスト活動を開始すると…

  • 難易度が上がる
  • テスト時間が増える
  • コストが増える
  • リスクが上がる

終了基準

  • 計画したテスト実行が完了している
  • 定義済みのカバレッジ達成
  • 未解決の欠陥やカバレッジ不足が合意された制限内であること
  • 残存欠陥数が十分少ないこと

    • 直接測れないので信頼度成長モデル等で想定する
  • 各種品質特性を十分に評価していること

    • 信頼性
    • 性能効率性
    • 使用性
    • セキュリティ
    • etc.

【所感】「十分」って何…?

下記を勘案し、ステークホルダーやビジネスオーナーがリスクを受容して切り上げることもある

  • サンクコスト
  • プロダクトを市場に送り出すプレッシャー

5.2.4 テスト実行スケジュール

優先度、依存関係、効率性のバランスを取りながらスケジュールを作成する

  • 基本は優先度順
  • 依存関係上の制約がある場合はこの限りではない

    • 【補】例えば詳細表示機能のテストのために管理画面の新規登録を先にテストするとか?
  • 要員の稼働状況に偏りや手待ちが生じぬよう

5.2.5 テスト工数に影響する要因

プロダクトの特性

例: テストドキュメントの記述の詳細度

開発プロセスの特性

例: 納期のプレッシャー、それにともなう並行タスク増・要員増

人の特性

例:

  • メンバーのスキルや経験
  • チームのまとまり

    • 見落とされがち

テスト結果

  • 検出した欠陥数と重要度
  • 必要な再作業の量

必要な再作業

  • 確認テストの量の見積もりは重要
  • 【所感】以前参画したプロジェクトでは、レビュー(静的テスト)の基準が定められておらず、
    指摘点修正・再レビューの工数が読めなかった…

5.2.6 テスト見積もりの技術

メトリクスを活用する

アジャイル開発

バーンダウンチャートの実績工数からベロシティを導出

シーケンシャル開発

欠陥除去モデル

  • 過去のプロジェクトで検出した欠陥数、およびその欠陥を除去するためにかけた時間で見積もる
  • 【補】IPAのソフトウェア開発データ白書で欠陥数を見積もるのもこれ?

専門家の知識を基にする

【補】PMきのこ97 一番うまく見積もれるのはその仕事をする人である

アジャイル開発

プランニングポーカー

  • チームメンバー自身の経験に基づいて工数見積もり

シーケンシャル開発

ワイドバンドデルファイ法

  • ビジネスアナリストのフィーチャー要求を聞いて開発チーム自身で見積もり

メトリクスか?専門家か?

一長一短なので、両方使用して比較するとよい

  • 規模やドメインが異なるとメトリクスはあまり信頼できなくなる
  • 専門家は人間なので納期と費用に合わせて帳尻を合わせてしまいがち

    • 【所感】見積もりを収束させていくタイプの手法の場合、発言権の強い人に合わせてしまうもあると思う