基本から学ぶテストプロセス管理 〜コンピュータシステムのテストを成功させるために〜

英語名：Managing the Testing Process Second Edition

テストの目的は、バグを見つけること！

第1章 実施するテストの選択

ーーテストプロジェクトの基本計画

実施するテストの候補:テスト作業とその範囲

詳細な観点から全体的な観点へ：テスト観点の粒度

• 構造(ホワイトボックス)テスト
• 動作(ブラックリスト)テスト
• 実地テスト

  テストフェーズ:暴走か進行か

• 単体テスト
• コンポーネントテスト/サブシステムテスト
• 統合テスト/製品テスト
• システムテスト
• 受入テスト/ユーザ受入テスト
  • アルファテスト 社内ユーザが実施
  • ベータテスト 現在もしくは将来のクライアントが実施
• パイロットテスト

実施すべきテスト:品質の考察

象を触る：品質は定義できるか

品質とは：製品の性能や製品の満足度…を左右する重要な特徴である。

経験則的品質から外れる危険性

標準手法だけではない:略式の品質リスク評価法

• 一般的な品質リスク
  • コンポーネントテスト
    • 状態
    • トランザクション
    • コードカバレッジ
    • データフローカバレッジ
    • 機能性
    • ユーザインターフェイス
    • 機械的な寿命
    • 信号品質
  • 統合テスト
    • コンポーネント/サブシステムI/F
    • 機能性
    • 容量とボリューム
    • エラー/災害時の処理と復旧
    • データ品質
    • 性能
    • ユーザI/F
  • システムテストと受入テスト
    • 機能性
    • ユーザI/F
    • 状態
    • データ品質
    • 操作
    • 容量とボリューム
    • 信頼性、稼働率、安定性
    • エラー/災害時の処理と復旧
    • ストレス
    • 性能
    • 日時の処理
    • ローカライゼーション
    • NW環境と分散環境
    • 設定オプションと互換性
    • 規格への適合
    • セキュリティ
    • 環境
    • 入力電力、消費電力、出力電力
    • 衝撃、振動、落下
    • インストール、カットオーバ、セットアップ、初期設定
    • 資料とパッケージ
    • 保守性
  • リストの確認と完成
    • ピアレビュー
    • 社内の専門家
    • 社外のリソース
    • 品質リスクの提案

不具合モード影響解析:品質リスクを理解するための標準的な手法

FMEA：不具合モード影響解析。

• システム機能または要素
• 潜在的不具合モード-品質リスク
• 不具合の潜在的影響
• 致命的か
• 重要度 1.データ消失/HW損傷/安全上の問題 2.機能喪失、迂回方法ない 3.機能喪失、迂回方法ある 4.機能が部分喪失 5.表面的/ささいな問題
• 不具合の潜在的原因
• 優先度 1.システムの価値が安全に喪失 2.システムの価値が許容できないほど喪失 3.システムの価値が低下するが、許容できる可能性がある 4.システムの価値が低下するが、許容できる 5.システムの価値が低下は無視できるほど僅かである
• 検出方法
• 発生確立 1.全ユーザに必ず影響 2.部分ユーザに影響する可能性高い 3.部分ユーザに影響する可能性ある 4.少数のユーザに限定的な影響が生じる 5.実際の使用用法では考えられない
• RPN(Risk Priority Number:リスク優先度指数) RPN=重度x優先度x発生確率(=1~125)
• 推奨処置
• 責任者／時期
• 参照先
• 処理の結果

実施可能なテスト:スケジュール、リソース、予算

テストスケジュールとプロジェクトの調整

• 費用が高いリソース NW、環境テスト機器、テストツールなど
• 準備に時間がかかるリソース 借りたり、建てたり、回線を引いたりする必要があるテストスペース
• 現在にないリソース 新たに雇用する必要がある人員など
• 外部リソース 第三者のテストラボなど
• 不足していて獲得しにくいリソース テスト技術者その他の要員

リソースの推定と予算の作成

• 人件費
• テストツール
• 施設と間接費
• テスト環境
• 外部ラボ

テストプロジェクトの交渉術

• どのようなリスク管理を採用しようとしているのか
• どの程度の期間がかかるか
• コストはいくらか
• 投資利益はどうか

第二章 テスト計画書

ーーコースの構想と提示

テスト計画書をなぜ作成するのか

• 自分の考えや、アイディア、記憶をまとめる良い機会となる
• 実際に作成を経験したことがあれば、多くのことを学んできたはず
• テストチームや開発担当者、管理者などと意見を交換しあうきっかけにもなる

いくつテスト計画書を作成すべきか

下記1つでも異なる要素があれば、サブプロジェクト別にテスト計画書を作成したほうがいい。

• 期間
• 方法
• 目的
• 対象者

草稿を利用して議論を活発化する

TBDなどを多用するなど。

テスト計画書のテンプレート

鵜呑みではなく、自分にあったものを使えればいい。

概要

テスト対象や全般的なテスト方法などを記載し、そのテストプロジェクトの計画を読み手に紹介する。

境界

テスト計画の境界を明確に定める。

範囲

する/しない 表を作成し、テストの範囲を明確にする。

定義

言葉定義や用語集など。

設定

テストの実施場所や、テスト実施組織とその他の組織の関係を記入。

品質リスク

主要事項のスケジュール

移行

開始基準

システムが特定のテストフェーズに移行するために必要な条件を細かく規定したもの。

継続基準

テストを継続的かつ効果的に継続できるようにするためにテストプロセスが満足しなければならばい条件及び状況を規定したもの。

終了基準

テストが完了したと判断する方法を定めたもの。

テストの構成及び環境

テストを実施するために使用するHW、SW、NW、ラボスペースなどについて記述する。

テスト開発

テストケース、テストツール、テスト手順、テストスイート、自動テストスクリプトなどを設計、開発する作業（まとめてテストシステムと呼ぶ）。

テストの実施

参加者

テストケースとバグ追跡

バグの分離と分類

• バグの分離 連結された変数、原因、その他を見つける目的でテスト対象システムを試験すること。
• バグの分類
  • 要件障害 システムがその要件を満たしていない状況に関する障害レポート。
  • 要件外の障害 システムの要件範囲からははずれていないが、システムの品質に受入がたい影響を及ぼすようなバグのレポート。
  • 放棄要求 確かに不具合ではあるが、クライアント及びユーザの経験則的品質に重大な影響を及ぼすようなバグではないと開発者が判断し、修正の放棄を要求sいている場合。
  • 外的な障害 テスト対象システムの制御範囲外の要員によって生じた不具合についての障害レポート。
  • テスト障害 障害があるというテスト結果は間違いまたは無効であると開発者が考えている場合。

テストリリースの管理

• テストサイクル
• テスト時間

リスクと不測事態

「未解決問題」という見出しヲつけることもある。テスト計画書の実行を難しくしたり、不可能にしたりする可能性のある事項を記入する。

変更履歴

参考文書

一般的な質問(FAQ)

計画書の承認

会社のPJ担当の役員と開発部門のマネージャの承認を得ておきたい。 メールで承認を得ることはよくない(反応がない=みていない可能性が高いから)。 皆に計画書を読ませるために最も効果的な手段はレビュー会議のようだ。

的を外さず、明確に、そして実際的に

文章表現も重要である。受動態を酒、何かが「なさなければならない」とするのではなく、誰がいつ何をするのかはっきり記載する必要がある。

第3章 テストシステムアーキテクチャ、テストケース、テストカバレッジ

テストシステムアーキテクチャとエンジニアリング

• テストシステム テストプロセス、テストウェア、テスト環境によって構築された系統的なテスト能力のこと。
  • テストプロセス テストを行う手順、CL、その他の合意事項。
  • テストウェア テストに使用するすべてのツール、文書、スクリプト、データ、テストケース、追跡メカニズムなど。
    • テストケースのセットアップ テストケースを実行するためのテスト環境の構築に必要な手順。
    • テストケースの実行に関する重要なポイント ひとまとまりのテスト条件の作成。
    • テストケースの除去 テストケースの実行後にテスト環境を元どおりの「きれいな」状態に戻すために必要な手順。
  • テスト環境 テスト対象システムをテスト可能な状態にするために調達/導入/設定するHW/SW/NWなどのインフラ/消耗品/施設/ラボなど。

テストシステムアーキテクチャの原則

芸術作品との違い:テストシステムの品質

ANSI/ISO 9126の特性(機能性、信頼性、使用性、効率性、保守性、移植性)。

テストシステムはだけでは機能しない:テスト担当者とテストシステム

テストシステムを作成、保守するのは人である。

テストシステムの品質と文書化その他の大原則

• 操作ガイド(システムの使用方法)
• 機能設計仕様書(システムの仕組み)
• テストシステムアーキテクチャ（システムの基本構造)

システムの基本要素:テストケース

テストケース=アクション、データ、予想結果。

テスト条件の作成

基本的なテストのテンプレート

要素：

• テストケース名
• 識別番号 5桁のID XX.YYY:XXはテストスイート番号、YYYはテスト番号。 デューイ10進分類法を使用(Ex.5番目のテストスイートの2番目のテストケースには05.002を使用)
• テストスイート 当該テストケースが使用されるテストスイート(複数の場合もある)
• 優先度 そのテストを何回実行すべきか判断しなければならない場合に便利
• HW要件
• SW要件
• 時間 テストにかかる実時間
• 工数 人/時(H)
• セットアップ法
• 除去法
• 結果
  • 合格
  • 不合格
  • 要注意
  • 実行不能
  • 省略

どの程度の詳細度にすべきか:明確に記述する効果

アクション、データ、予想結果を詳細に書くことは、テスト担当者に知識乏しいことを想定する。

恐ろしい「見逃しバグ」を防ぐには:カバレッジと回帰テストギャップ

見逃しバグ=テスト中に当然検出できたはずなのにテストチームが見落としてしまったフィールド報告バグである。

DDP=(bug_test / (bug_test + bug_customer)) x 100%

• 発生期間 フィールドバグの多くは配備後3ヶ月から1年で発見されると考えてm違いない、DDPを評価できるのはその期間を過ぎてから。
• 発生原因 下記1つ以上あると、大抵発生
  • 忠実性の低いテストシステム
  • 回帰テストギャップ
  • テスト結果の誤った解釈

品質リスクとテストケースを対応付ける

定量的なテストカバレッジ分析 |値|カバレッジの意味| |:-|:-| |0/blank|テストケースは品質リストとは無関係| |1|テストケースは品質リスクに対するある程度の間接的カバレッジを与える| |2|テストケースは品質リスクに対する直接かつ重要なカバレッジを与える|

構成に対するカバレッジ

実施「不可能な」構成が存在し、時間と工数のコストがかかりすぎる場合もある。

その場合の対応例

• 各構成の変数の種類を5個ずつ選択し組み合わせてテスト
• ショットガウン方式 マトリックスの全セルをカバーしようとせず、無作為にテストを分散させる
• テストサイクルを使用しテスト構成をカバー
• 広範囲なベータテストを利用

バグに対するカバレッジ

バグの数を推定する方法として

• 最も一般的なのは、過去のデータを利用する手法
• ファンクションポイントでPJの規模を測る

欠陥除去モデル

• 欠陥を注入(inj)
• 欠陥を除去(rem)
• 欠陥が次の段階に持越(esc)

このタイプの高度な欠陥除去モデルはかなり高精度(コード行モデルでは、±10%程度)。

エラーシーディングとは、
テスト対象システムにバグを故意に埋め込む手法。

k / K ≒ n / N

• K 埋め込んだバグの数
• k システムテストの最後に、検出した埋め込むバグの数
• n システムテストの最後に、埋め込むバグ以外で検出したバグの数
• N テスト対象システムのバグの数

回避テストギャップ

デグレード(回帰)の正しい理解は、
テスト対象システムを変更した結果、システムの新しいリビジョンS_n+1に、リビジョンS_nには存在しなかった欠陥が生じた場合、システムの品質がでグレートしたと言う。

• 自動化は解決策になるか？ 有効な手法の1つだが、万能薬ではない。テストを自動化しても、自動化されるのはテスト条件の作成だけであり、テストケースやテストスイートのセットアップと除去、結果の分析は自動化されない。
• テストをテストサイクルに配置する4つの方法
  • 優先度方式
  • 動的優先度方式
  • ショットガン方式
  • レールローディング方式
• もう1つのデグレード発生リスク緩和戦略 テスト担当組織に新しいリリースが届くたびに、それに対してテストを繰り返す手法。

学ぶ教訓:テストケースの漸進的な改善

障害への対応

ユーザからのFBはテスト部門にとっても重要で、テストケースを書いたり、テストデータを作成、バグを再現できる手段が必要。

ベストプラクティスを採用

探索的テストを利用

すべての実行は不可能:しないことを決める

第4章 バグ追跡データベース

ーー「虫」の生態を究める

正式なバグ追跡システムの必要性

すぐれた障害レポートは、問題修正の要否や修正時期の決定に必要な情報をPJチームに提供し、問題修正とデバッグのために必要な情報をプログラマにも提供する。

バグ追跡システムとは、PJチームが詳細レポートを作成/管理/分析してバグの傾向をしるために使う、PG/アプリをいう。

良い障害レポートに含まれるもの

• 要約
• 再現手順
• 分離 バグが現実の問題であることを確認し、そのバグの出現に関係する因子を特定するため、テスト担当者が収集する情報と結果。

よい障害レポートは、テスト担当者が何をしたかではなく、何を発見したかを読み手に伝えるものである。

障害レポート改善んへの10か条

1. 体系化
2. 再現 一般には、障害の再現を3回試みる
3. 分離 条件の変化によってバグの障害が変化しないかを調べ、するようならその条件を特定。
4. 一般化 システムの他の部分にもバグの障害が現れないか、データ等を変えながら探す。
5. 比較 類似のテストの実効結果と比較
6. 要約
7. 凝縮 不必要な内容を削る。
8. 明確化 意味のはっきりした言葉を使う
9. 中立化 公平な立場から表現する
10. レビュー 提出するまえに、少なくとも1人のピアに読んでもらう

柔軟な障害レポート:データベース構築への着手

MS AccessでもOracleでも、MySQLなどでも構わない。

最低でも含めるべき項目

• バグID(順序識別番号)
• プロジェクト名
• 報告書作者
• 報告日付
• 障害記述
  • 要約
  • 再現手法
  • 分離

受容な少数とどうでもよい多数:レベル分けの重要性

重要度(1~5)、優先度(1~5)から、RPN(バグのリスク優先度指数,1-25)に分けておく。

バグ追跡データベースに追跡のメカニズムを:動的情報の追加

バグの状態別ライフサイクル管理

• レビュー レビューされるまでテストチーム以外の人の目にすることがない状態
• 却下 レビューアが障害レポートをみて、相当な書き直しが必要な場合、テスト担当者に戻される状態
• オープン レビューアの確認で問題なければレポートがオープンし、既知のバグとして公表する状態
• 割り当て 権限あるPJメンバーが開発マネージャに割当、さらに開発者に割り当てるかの状態
• テスト 開発チームが問題を修正すると、それはテスト状態に移る
• 再オープン バグ修正が修正確認テストを合格しないと、テスト担当者は障害レポートを再オープンする
• クローズ 合格したら、テスト担当者はクローズする
• 据え置き 権限あるPJメンバーが問題を低い優先度に割り当てるか、修正を次期リリースまでに待つ決定

所有と責任の所在を強調

重要なハンドオフ:分離からデバッグへ

テスト担当者からプログラマに引き渡される時、重要なハンドオフが生じる。

バグのライフサイクルを誘導する:バグの選別プロセス

優先度の決定に迷うバグの場合は、バグ判定(orバグレビュー)委員会、もう1つは変更管理会議(CCB)のアプローチがある。

動的フィールドをしかるべき場所に

仕上げ:分析のためのバグデータ取得

何を関連したバグか:サブシステム、構成、品質リスク

バグはどこからきたか:対策と根本的原因

バグをどこから発生したかを把握するための最も簡単な方法は、プログラマなどにバグを修正した技術者にメモを書いてもらうことである。

自由入力形式の対策フィールドで1つ問題となるのは、分析が難しいことである。

企業のプロセス成熟度は低いと、根本的原因分析という概念を取り入れることができないことがある。

根本的原因とは、バグの背後に潜んでいる発生理由のことである。

障害レポート(や事故対応)に関する障害原因を「テスト不足」と書いてあることがあるが、これは根本的原因の分析をしていいない証である。同様に「忘れた」「もれた」「抜けた」なども分析途中での思考停止を示している。

根本的原因分析の目的は、バグを分類し、体系付けることである。

根本的原因分析法

Boris Beizer著「Software Testing Techniques」(邦訳:ソフトウェアテスト技法)

• 機能
  • 要求仕様誤り 仕様が誤っている
  • 機能不良 仕様は正しいが、実装が誤っている
  • テストに関わる不良 システムは正しく動作しているが、テストで実態のないエラーが報告される
• システム
  • 内部インターフェース 内部システム通信の障害
  • ハードウェアデバイス HWの障害
  • オペレーティングシステム OSの障害
  • ソフトウェア構造 設計の基本的な前提の誤り
  • リソース管理 設計の前提は正しいが、その前提を実装するときにどこかで誤った
• 処理
  • 演算 プログラムによる加算、除算、乗算、因数分解、積分など、演算の誤り
  • 初期化 ある操作の初期値設定に関する不良
  • 制御または順序 アクションが、起こるべきでない時点で実行される。または、誤った理由で実行される
  • 静的論理 境界定義の誤り、無効な論理、「起こらないはず」のイベントが起こる、「差し支えないはず」のイベントが差し支える、など
  • その他 上記のどれにも当てはまらない制御の流れの誤りや処理の誤り
• データ
  • 型
  • 構造体 複雑なデータ構造が誤っていたり、不適切だったりする
  • 初期値 データ要素の初期値の誤り
  • その他
• コード タイプミス、ミススペル、形式の誤りなど
• 文書 文書の記述通りに実装しなかった
• 規則/規格 システムが業界規格またはベンタ規格を満たしていない、コード規則に従っていない、命名規則にいやんしている、など
• その他 根本的原因はわかったが、上記のどのカテゴリにも当てはまらない
• 重複 2つ(以上)の障害レポートに同じ問題を記録している
• NAP Not a Problem
• 不良品 実際にバグは存在するが、HWの不足の障害から発生したもの
• RCN Root Cause Needed バグはテストによって終息が確認されたが、開発チームの誰からも根本的原因の指摘がない状態
• 不明 どこが悪いのか誰にも分からない

根本的原因のデータを収集するメリットは、開発プロセスの改善に着手する次期がきたときに、パレート理論を適用できることである。

別の根本的原因分析法に、

• IBMのRam Chillaregeが考案した直交的欠陥分類 (www.chillarege.com)
• IEEEが定めたSWの標準的分類法 IEEE Standard Classification for Software Anomalies

バグはいつから:クローズ日付と混入・検出・除去の各段階

PJフェーズで調査することが最も一般的である

• 要件定義
• 設計
• 実装
• コンポーネントテスト (orサブシステムテスト)
• 統合テスト コンポーネント(orサブシステム)間の相互作用に関するバグを探し、修正する段階
• システムテスト
• 受け入れテスト
• リリース後

バグ追跡データベースの完成

バグ追跡データベースからのメトリクス抽出

バグ除去の進み方:オープン/クローズチャート

最も基本的な欠陥分析チャートは、オープンされたバグの累計と、クローズされたバグと対策 が据え置かれたバグの累計を、毎日プロットしていくというものである。

なぜバグが起きるか:根本的原因チャート

開発チームの反応:解決期間チャート

解決期間とは、テストチームの障害レポートに対する、開発チームの反応の速さを測る尺度である。これには2つの解決期間がある

1. 日次解決期間 その日にクローズされたすべてのバグの、オープンから解決までの平均日数である。
2. 定期解決期間 その日とそれ以前にクローズされたすべてのバグの平均日数である。

どこが悪いのか:サブシステムチャート

どのサブシステムが最も多くのバグが出ているのかを示すものである。

根本的原因チャートと同様に、サブシステムごとの棒グラフと、累積パーセンテージの折れ線グラフ（パレート図）。

事後メトリクス:欠陥検出率

前出のDDPの公式。

バグ追跡の管理

バグデータの政治的側面と誤用

• 信頼関係の構築を怠るな
  • バグを個人的に受け止めて感情的になることを避けることが大切。
  • すぐれた障害レポートだけを提出する。
  • 先入観抜きで障害レポートについて話し合う。
  • 障害レポートに関するプロセスの何かを変更してほしいという要求が開発者から出たときは、その提案を真剣に検討。
• 余計な口出しをするな 開発マネージャの責任範囲のことを、テストマネージャは口出しすべきではない。
  • テストマネージャの仕事 担当者がバグを見つけ、再現し、分離できる環境を整えること。また、バグを解決に至るまでに追跡し、簡潔なバグの摘出状況の概要を上級管理者に届けるのも仕事。
  • 開発マネージャの仕事 バグ修正プロセス（修正時期、リソースの使い方、進み方など）。
• 個人を悪者にするな

さまざまな難問

• バグか機能か
• 再現不能なバグ
• 据え置き化、見逃しか