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

テストモニタリング

テスト活動に関する情報を収集・可視化

• 「やってる？」「やってるよ」だと(本人にさえ)進捗が見えない
• 大変なので、メトリクスの自動収集等を検討する

なんのため？

• テストコントロールのため
• doneの判定を行うため

テストコントロール

モニタリングの結果をフィードバックしガイドや補正を行う

識別したリスクが現実になった場合(例えば、リリース遅延)、テストの優先度を見直す

例: あるマイクロサービスの開発が遅延し、連携のテストができなくなる

-> 他のサービスのテストを先にする

テスト環境や他のリソースの利用可否により、テストスケジュールを変更する

例: 必要な機材が期日までに調達できない

-> それを使わないテストから行う

再作業が発生した場合に、テストアイテムが開始基準と終了基準を満たすかを再評価する

例:

  テストケース1
  テストケース2
x テストケース3
  ...

テストケース3の実行により重大な故障が見つかり、大規模修正が発生した。

すでに合格したテストケース1,2の対象範囲にまで影響が及ぶ。

• 開始基準は？

  • テストケース3を実行できるまでに全ての欠陥が修正されていること
  • テスト環境が準備できていること

• 終了基準は？

  • テストケース1,2のぶんも含めて再度判断しないといけない

5.3.1 テストで使用するメトリクス

メトリクス

計画したスケジュールや予算に対する進捗

「前倒し」も要注意

• 用意したテストケースに不足はないか
• 用意したケースが確実に実行されているか

テスト対象の現在の品質

【補】PB曲線とか使う

テスト消化曲線とバグ発生曲線の7パターン診断

例: テスト消化率が想定よりも少ないうえに故障発生率が想定よりも多いのは「前工程成果物の品質が悪い」を意味し、最悪の事態

-> しかるべきコントロールを行う (「コードを捨てる」もあるかも)

テストアプローチの十分性

例: 「系統的なアプローチ」を採用し、組織標準のテスト条件一覧を活用してテスト設計したが、標準以外の部分で故障を多く検出した

-> テストコントロール: 標準のテスト条件一覧の見直しを行う

テスト目的に対するテスト活動の効果

例: 作業成果物を静的テストすることで動的テストでの故障検出が減少することを確認する

当該プロジェクトへフィードバックすることはできないが、未来の別プロジェクトへの教訓として活かすことはできる

テストメトリクス

計画したテストケースの準備が完了した割合

あとどのくらいでテストに入れるか

計画したテスト環境の準備が完了した割合

H/Wの調達等が大変なことがある

テストケースの実行した数、結果

• 合格/不合格の率で信頼性をはかる
• 未実施テストケース数に実行時間の係数を掛けて、必要なテスト実行期間を算出する

欠陥情報

欠陥密度

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

プログラムの規模: 行数、ステートメント数、ファンクションポイント数等

• 【所感】テスト7原則の4. 「欠陥の偏在 — 特定の少数モジュールに集中する」と対立していないか？

  • 「プログラムの規模」にファンクションポイント数を用いれば、そのモジュールの本質的な困難性が分母に反映されるからよいのかな？

故障率

H/Wのそれとは概念が異なる

故障率 = 故障数 / テストに費やした工数

検出した欠陥と修正した欠陥

オープンクローズチャート

検出した欠陥数に修正した欠陥数が追いつけばリリース可能

【所感】テスト未実施、もしくはテストの欠陥検出能が低いということも考えられるのでは？

要件、ユーザーストーリー、受け入れ基準、リスク、コードのテストカバレッジ

最も強力

• プロダクトリスクのカバレッジ
• 要件のカバレッジ
• 受け入れ基準のカバレッジ
• コードカバレッジ
• etc.

コードのホワイトボックステスト(動的テスト)で測定したコードカバレッジについては、100%に近づくにつれ上げるのが困難になる

• 代替フロー
• エラーハンドリング

こういった部分はレビュー(静的テスト)で欠陥のないことを確認したほうが効率的なことがある

タスクの完了、リソースの割当と稼働状況、工数

そんまんま

テストに費やすコスト

【補】SEC BOOKS：高信頼化ソフトウェアのための開発手法ガイドブック

品質と健康は、どちらも「完全に問題のない状態」を明確に証明することは困難であるといわれています。
従って、検知活動は検知の網羅性を高めつつ、現実的にはコストおよび開発期間などの制約を勘案し、
合理的なレビューおよびテストにかかわる手法を選択することが必要になります。

コストを度外視しては本末転倒

1. これまでに費やしたコストを集計し、テストを続行するコストを見積もる
2. テストを続行するコストとプロダクトリスクを受け入れるコストとを定量的に比較し、どこまでテスト実行を継続可能なのか定量的に把握する

【所感】つまり、プロダクトリスクを識別し、それを受容するコストを定量的に見積もれていないといけない

5.3.2 テストレポートの目的、内容、読み手

2種類のテストレポートがある

• テスト進捗レポート

  • テスト活動期間中のレポート

• テストサマリーレポート

  • テスト活動終了時のレポート

典型的なテストレポート

ISO/IEC/IEEE 29119-3 テスト進捗レポート/テスト完了レポートの共通の構成(意訳)

• 文書固有の情報

  • 概要
  • 文書を一意に識別できる情報
  • 発行期間
  • 承認権限
  • 変更履歴

• はじめに

  • 範囲
  • 参照/被参照
  • 用語集

ISO/IEC/IEEE 29119-3 テスト進捗レポートの構成差分(意訳)

• テストの状況

  • 報告対象期間
  • テスト計画に対する進捗、外れている場合は理由と解決策
  • 進捗を妨げる要因、解決策
  • テスト方法
  • テストコントロールの結果、新規追加および変更されたタスク
  • 次回進捗レポートまでの間で実行予定のテスト

ISO/IEC/IEEE 29119-3 テスト完了レポートの構成差分(意訳)

呼び名が異なるが、ISTQBの「テストサマリーレポート」と同じもの

• 実施したテスト

  • 実行したテストの概要
  • 計画からのテストの逸脱
  • テスト完了評価、満たしていないものは理由とリスクについて
  • 進捗を妨げた要因、実施した施策
  • テスト方法
  • 残存リスク、テスト実行時に新たに特定されたリスク
  • テスト成果物
  • 再利用可能なテスト資産

満たしていないものは理由とリスクについて

【補】例: 2038年問題という欠陥があるけれど2037年までは問題ない！とかそういう話

• 発生確率

  • 2038年になったら100%だが2037年までは0%、もっというとそれまでDBが残っている可能性も0%に近い、とか

• 想定される問題への対処

  • DBの移行作業等必要そう

テーラリング

プロジェクトの性質、組織から与えられた要件、ソフトウェアライフサイクルによるテーラリング

• 多くのステークホルダーが関与する複雑なプロジェクト・法規制を受けるプロジェクト

  • 相応に詳細・厳密・多量になる

• 簡易なソフトウェア更新

  • レポート作成もタダじゃないので省力化

• アジャイル開発

  • 進捗レポートはタスクボード、欠陥サマリー、バーンダウンチャート等で代用
  • 日々の朝会やスタンドアップミーティングで情報共有

読み手によるテーラリング

• 開発担当者・テストチーム向け

  • テストreadyの判定のために「どの欠陥がいつ修正されるか」がわかると有用

• PM向け

  • テストマネージャとプロジェクトマネージャが連携してコントロールできるための情報が必要
  • 例: システムテストとシステム統合テストどちらで故障が多く発生しているか？
  • 例: 何の修正に時間がかかるか・かかっているか？

• 経営者向け

  • ハイレベルな粒度で簡潔に
  • 例: QCDは良好なのか、課題ありなのか
  • 例: 課題があるなら、理由と対処状況