【JSTQB FL 】 1. テストの基礎

はじめに : JSTQB FLの学習内容・解釈・気づきを共有

JSTQB Foundation Level(シラバスVersion2018J03)について学習した内容と自分の解釈・気づきをまとめてブログで公開しています。JSTQB FLをシラバスや教科書で学習されている方は、不明点があるときに、本ブログの内容と照らし合わせて頂いて、理解の助けになればいいなと考えています。
(※このブログを全部を読むというよりは、学習中に分からないことがあったときに、覗いていただくという使い方が良いと思います。)

今回の内容 : 第1章.テストの基礎

目次

1.1 テストとは何か？
1.2 テストの必要性
1.3 テストの7原則
1.4 基本的なテストプロセス
1.5 テストの心理学

1.1 テストとは何か？

• テストとは？
  ソフトウェアが、正しく動かないと、問題・不都合が発生する可能性がある
  テストとは、ソフトウェアの本番稼働時、市場利用時に、問題・不都合が発生するリスクを低減する活動

• では、防ぎたい不都合・リスクは？

  • 経済的な損失
  • 時間の浪費
  • 信頼の失墜
  • 傷害や死亡事故

• では、これらは誰に対してのリスクか？

  • ユーザ側：一般消費者、ユーザ企業
  • デベロッパー側：開発者、企業

• では、テストでやることは？

  • 本番で使われる前に期待通りの動作をするかを確認する
  • 故障がある場合は、修正しそれがなくなるまで、テストをすることで、本番での故障の発生の可能性を低くする

• テストの活動は大きく分けると↓のようになる (詳しくは、テストプロセスで。)

  • テスト実行前作業
  • テスト実行中作業
  • テスト実行後作業
  • テスト全体にかかわる作業

テストの目的

• 作業成果物の評価
  • 主にレビューで行う
  • 作業成果物の妥当性を確認
  • 作業成果物の質の評価
    • 読みやすさ
    • 誤解のない表現
    • 構成の一貫性
    • 社内のルールに遵守しているか
• 検証(Verification)
  • 開発したいものを、期待通りに開発できているか？を確認
  • テストレベル(コンポーネント、統合、結合)毎に行う
  • 作業成果物が、要件に対して妥当か確認・・・作業成果物に注目した確認
  • コンポーネントやシステムの動きが、要件に対して期待通りの動きか検証・・・動きに注目した確認
• 妥当性確認(Validation)
  • 開発したものが、顧客の期待するものになっているか？を確認
  • 主に受け入れテストで行う
    • ステークホルダーの期待する動作になっているか確認
    • 欠陥の検出は目的ではない
    • リリース時に、ソフトウェアの品質を確認し、どんなリスクを含んでいるのかをステークホルダーに情報提供する
• 欠陥の作り込みの防止
  • テスト活動の結果から、開発・テスト活動の改善を行う
  • テストで検出された故障・欠陥の原因を分析する
  • 分析結果により、「作業成果物の評価」での活動の観点を見直す
  • 分析結果から、開発の改善を行う
• 故障・欠陥の発見
  • 欠陥を修正するために、欠陥を見つける
  • ※テストとデバッグは、別物！
  • 故障を見つけて、欠陥があることを示すのがテスト/ 欠陥の原因を突き止めることがデバッグ
    • 開発担当・・・デバッグに責任を持つ
    • テスト担当者・・・テストに責任を持つ
• 品質のレベルを確証（「意思決定のための情報提供」と近い）
  • 全テストレベルのテストの結果を包括して確認する
  • メトリクス分析を行い確証のある情報をまとめる
  • ステークホルダーへの情報提供
• 意思決定のための情報提供（「品質のレベルの確証」と近い）
  • 品質のレベルの確証し、ステークホルダーへ情報提供する
  • 欠陥が未修整のままリリースする場合、確証できない部分も適切に評価
    • どんなインパクトがあるのか
    • 回避策はあるのか
    • 修正の見通は立っているのか　など
• 不適切なソフトウェア品質のリスクレベルを低減する
  • 要するに、意図しない副作用の流出を防ぐ
  • 不適切なソフトウェア品質のリスクレベルを下げる
    • 以前検出されなかった故障が運用環境で発生するとか
    • 注目・変更していたソフトウェア変更箇所以外で、故障が発生するとか
  • リグレッションテストにより↑不適切なソフトウェア品質のリスクレベルを下げる
    • 実行済みのテストを再実行する
• 対象が契約・法律・規則上の要件や標準に遵守・準拠していることの検証
  • 国際・業界規格に準拠した開発/テストであることを検証する
  • 例えば、自動車業界なら
    • ISO26262やASPICEなどに開発/テストが準拠しているかどうかを検証する

目次へ戻る

1.2 テストの必要性

なんでテストは、必要なのか？
➡ ソフトウェアの本番稼働時、市場利用時に、問題・不都合が発生するリスクを低減するために必要
↓「テストとは何か？」より

テストとは、ソフトウェアの本番稼働時、市場利用時に、問題・不都合が発生するリスクを低減する活動

• 各開発レベルでのテストの必要性
  • 要求分析
    • 正しくない機能を開発するリスク低減
    • テストできない機能を開発するリスクを防ぐ
      • 作ったのにこれテストできなくね？は、機能検討が不十分な可能性が高い。テストができるように機能を開発する必要がある
  • システム設計
    • コンポーネント間のデータのやりとりアンマッチのリスクを防ぐ
    • 同様の処理を複数のコンポーネントで実装してしまうというリスクを防ぐ
    • 設計の欠陥が混入するリスクを防ぐ
    • 設計者の誤りによる欠陥の混入するを防ぐことができる
    • レビューに参加することで、設計内容の欠陥を検出
    • レビューに参加することで、設計に対するテストを考える
  • コード開発・コンポーネントテスト
    • テストケースに欠陥が混入するリスクを低減
      • 不適切なテストケースでテストが合格になってしまったら、不具合流出させてしまうリスクがある
  • 統合テスト・システムテスト・受入テスト
    • 実際に動かすことで、レビューだけでは見つからない欠陥の混入リスクの低減
    • テストしなければ見逃してしまう故障の検出をする
      • レビューだけで欠陥混入防げるならそれでいいけど、そうはいかないよね。
      • 故障が起きた時の様々な情報を欠陥レポートに残すことで、デバッグの助けになる
• 品質保証活動でのテストの必要性
  • 品質保証への貢献
    • 品質保証
      • 品質保証は適切なプロセスを遵守するための活動
      • 作業成果物への欠陥侵入を防止する目的
    • テストはどう貢献する？
      • テスト結果や欠陥情報により、プロセス改善につなげることができる
  • 品質コントロールへの貢献
    • 品質コントロール
      • プロダクトが適切なレベルの品質を達成するための活動
    • テストはどう貢献する？
      • システムの品質を確保することができる
        • テストにより、欠陥のないことを証明できれば自信をもってリリースできる
        • テストにより、欠陥を見つけられれば、デバッグでき、それを修正することができる
      • テスト結果を当たり前品質の評価指標にできる
        • テストケースの実行数・欠陥の検出数を計測する
      • 非機能要件の品質計測 を行うことができる
        • 性能テストで応答時間を計測すれば、システムの性能効率性・信頼性の評価ができる
        • (テストのデータがないと、どれだけ非機能要件に対する品質が確保できているのか評価できない)
  • 品質マネジメントへの貢献
    • 品質マネジメント
      • 品質に関する組織の方針をっ示し、品質目標を定義して、コントロールする
      • 品質保証と品質コントロールの大枠
    • テストはどう貢献する？
      • 品質保証と品質コントロールへの貢献の内容の通り
      • テストのデータを提供することで、プロセス改善につながる
      • テストのデータを提供することで、プロダクトの品質に確証を持てる
      • テストのデータを提供することで、当たり前品質の評価ができる
      • テストのデータを提供することで、非機能要件の品質計測ができる

テストの用語

• エラー(誤り) error
  • 間違った結果を生み出す人間の行為
  • 欠陥の埋め込みの最初の原因となる行為・条件を根本原因という
• 欠陥 defect
  • 作業成果物に存在する、要件または使用を満たさない不備・欠点
  • バグ＝フォールト＝欠陥
• 故障 failure
  • テストによりプログラムを動かしたときの、不正なプログラムの実行結果
  • ※不正なテスト結果(テストのミス実行による結果など)は、故障とは別。

目次へ戻る

1.3 テストの7原則

• 原則1. テストは欠陥があることは示せるが、欠陥がないことは示せない
  • 内容
    • 故障が"ある"ことは示せる
    • 故障が"ない"ことは証明できない
  • だからどうする？
    • テストを適切・戦略的に実施し、テスト結果の妥当性に確証を得る必要がある
• 原則2. 全数テストは不可能
  • 内容
    • 膨大なテストパターンを有限な時間で行うことは難しい
  • だからどうする？
    • ソフトウェアの性質・目的・使われ方から、重点的にテストする機能を絞る
    • 優先順位を決めてテストする
• 原則3. 早期テストで時間とコストを節約
  • 内容
    • 欠陥の作り込みから発見が遅くなるほど、修正コストは指数関数的に大きくなる
    • 開発者の頭がコーディング内容に対してホットなうちに欠陥を見つけないと、デバッグに時間がかかる
    • 欠陥が複数作り込まれてしまい、欠陥の関連個所が多くなると、間違った直し方をしてしまう可能性も高まる
  • だからどうする？
    • 欠陥は早期に見つけるべき
    • シフトレフト
      • 欠陥を早期に取り除くために、開発ライフサイクルの開発工程にテスト分析・設計を近づける
      • 例えば、テストケースの開発を設計工程の上流で行うことで、基本設計上の不備を見つけることが可能となる
• 原則4. 欠陥の偏在
  • 内容
    • ソフトウェアの品質は均一ではない
    • ソフトウェアの欠陥がみつかる場所は、ある部分に集中する
    • 各機能が一体となって、ソフトウェアとして動くため、その一部に欠陥があると他へも影響してしまう
  • だからどうする？
    • 効果的にテストを行うために欠陥偏在を過去の不具合分析や直近のテスト結果によって予測し、テスト箇所を絞り込むとよい
• 原則5. 殺虫剤のパラドックス
  • 内容
    • 同じテストを何度も繰り返すと、新しい欠陥を見つけられなくなる
    • ソフトウェアは、テストセットに対する耐性を作っていく
  • だからどうする？
    • 新しい内容のテストを常に作っていく必要あり
    • 入力パターンを変える
    • 視点を変えたテストを作る
  • ※リグレッションテストは、デグレードの確認が目的のため、繰り返しの実行で問題ない
• 原則6. テストは状況次第
  • 内容
    • テスト対象や開発方法などの状況を考えず、闇雲にテストをしては、失敗する
  • だからどうする？
    • ↓を考慮して戦略的にテストをやりましょう
      • どんなシステムなのか
      • どんな機能があるのか
      • どんな機能は優先的にやるのか
      • どんな開発方法なのか
      • プロジェクトの状況はどうか
      • 誰が使うシステムなのか
    • システムの目的にマッチしたテストケースを開発する必要がある
      • 過負荷、多重入力、割り込みのテストをしたほうがいいか？を考える
      • 正確性、セキュリティのテストをしたほうがいいか？を考える
      • 使用性（簡単に使えるとか）のテストをしたほうがいいか？を考える
    • システムの開発方法や状況にあわせてテストを実施する必要がある
      • ウォーターフォール：テストは一気にまとめて実施すべきか？を考える
      • アジャイル：リグレッションを毎日回す必要があるか？を考える
• 原則7. 「バグゼロ」の落とし穴
  • 内容
    • 開発者は、仕様に対して欠陥のデバッグと修正を行い、バグゼロを目指す。
    • 欠陥を修正し、バグがゼロになっても、システム全体の機能や性能がユーザにとって使い勝手の良いものでなければ意味がない
    • 機能としては、「～できない」故障は解決できてもソフトウェアとして使い物にならない（処理重いとか）になったら意味がない
  • だからどうする？
    • システム全体の妥当性を考えてデバッグ・修正を行う必要がある
    • 妥当性確認を実施し、仕様自体がステークホルダーにとって有益なものかを考える必要がある

目次へ戻る

1.4 基本的なテストプロセス

• 基本的なテストプロセス

  • テスト計画
  • テストのモニタリングとコントロール
  • テスト分析
  • テスト設計
  • テスト実装
  • テスト実行
  • テスト完了

• なんでテストプロセスが必要か？

  • 行き当たりばったりなテストはダメ　例えば↓
    • テストを実行しかしてない
    • テストケースの抽出・テスト手順作成をテスト実行と並行で実行
  • 行き当たりばったりなテストは、こうなる
    • テストケースが漏れる
    • テストの時間が足りない
    • 故障を見つけられない
  • 行き当たりばったりなテストから抜け出す必要ある
    • テスト計画を立て、正しいテストプロセスを実行する必要がある

• テストプロセスとは

  • テストの準備から終了までの一連の作業
  • テストの目的を達成するための活動のセット
  • 組織によりテストの目的が異なるため、テストプロセスも異なる
    • 組織ごとのテスト活動の基本的な考え方は、"テスト戦略"として取りまとめておくとよい
    • 組織によりソフトウェア開発ライフサイクルモデルは、異なる
      • 独自マネジメント手法 or 標準マネジメント手法(ex.PMBOK)とか
      • ビジネスドメインに最適なプロセスで開発を行う
    • ソフトウェアテストプロセスも最適化して回していく必要がある
  • ソフトウェアテストプロセスに影響を与えるもの
    • プロジェクト個別の事情
    • 予算規模
    • 開発期間
    • 開発体制
    • ミッションクリティカル度合い
    • 遵守すべき法律、標準
    • 組織自体の開発標準、管理手法

• テスト計画

  • テストの目的を明確にする（検討事項↓(目的に関わる項目の例)）
    • テスト対象のリリース時期
    • テスト対象の存在理由
    • テストレベル

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

  • テストのモニタリング
    • アクティビティとタスクの状況把握
    • 順調か客観的に把握
  • テスト実行中
    • テスト計画と進捗の乖離を計測
    • 欠陥情報(発生情報とテストケース内容)の進捗からテスト対象の品質を分析
    • テスト進捗レポートとしてステークホルダへ共有
  • テストのコントロール
    • モニタリング結果をもとに、テスト計画やプロジェクト計画を見直す

• テスト分析　

  • テスト条件を抽出するプロセス。
  • テスト条件は、「何をテストするのか？」（テストケースよりも抽象度が高いもの）
  • ※テストケースを書き出す前に頭で考えていることを、テスト分析というプロセスを通して実行する
    • テストベースの入手（テストベース：テスト対象の機能要件、非機能要件、構成・構造、設計情報が記されたあらゆるドキュメント）
    • 情報の取捨選択・再収集・新規作成の検討
    • どのフィーチャー(コンポーネントやシステムの機能・属性)がテスト可能なのか識別・判断
  • アクティビティ
    • テストベースを分析する
      • テストレベル毎にテストベースは異なる
    • テストベースとテストアイテムを評価して、欠陥の識別
      • テストケースを実装する上で阻害要因となる事項（＝テストベース内の欠陥）を識別
      • こんな仕様じゃ、テストケース作れねーよ！は、仕様書の検討漏れ・不正確・曖昧・抽象的な箇所である
      • テスト担当者の主観でテスト結果が左右されるのを防ぐため、上記のような仕様書の不備をなくす必要がある
    • テストすべきフィーチャーとフィーチャーのセットを識別する
      • フィーチャー：明示的、暗示的に規定したコンポーネントやシステムの属性(例えば、信頼性、使用性、設計上の制約など)である（ISO9126）
      • 一言で表すと、テスト対象の機能・属性
      • テストすべきフィーチャーは、「テストすべき対象の属性はなんだろう」「対象の何をテストするか？(ここで言う"何を"が品質特性から抽出されたりする)」
      • フィーチャーセット：例えば、特定のテストレベルでテストできるフィーチャーとして識別した、複数のフィーチャー
        • フィーチャーセットは、テストレベル毎に用意したフィーチャーの集まり（例:↓）
          • コンポーネントテスト：構造、カバレッジ…
          • 統合テスト：インターフェース、機能…
          • システムテスト：非機能…
          • 受入テスト：信頼性、使用性…
      • 各フィーチャーのテスト条件を決める
        • テスト条件：特定のテスト目的を達成するためにテストベースを調べた結果として識別できたテストベースの一部
        • テストベースから検討することの例↓
          • テスト実行に使える期間
          • 担当者の資格・スキル・技術
          • テストアイテムごとの機能非機能に対する仕様の送還や依存性、類似点、ソフトウェアの構造
          • テスト条件を決めたら、優先順位をつける
          • プロダクトリスクに対して、どのつと条件が関連するかということを考慮するとよい
        • テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する

• テスト設計　

  • テスト条件「なにをテストするか？」を満足する、ハイレベルテストケース「それをどうテストするか？」を決定する
    • テストケースを設計する
      • テスト条件を満足するため、ハイレベルテストケース(高位レベルテストケース)を設計する
      • テスト設計では、「どうテストするか？」を決定する
    • アクティビティ
      • テストケースとテストケースのセットを設計し、優先度を割り当てる
        • テストベースがそろっていること、テスト分析によりおおよそテスト条件が出ていることを条件に、テスト設計を開始
        • テスト計画で示したテストアプローチ・テスト設計方針に基づいて、テスト条件を具体化（大項目から中項目と変換してく)
          • ※いきなり、テスト手順や期待結果などの詳細から検討せず、テスト条件を網羅できるようにテスト技法を用いて、設計していく
        • テスト条件に対する抽出したテストケースの網羅性を満たすために、カバレッジで評価
          • 要件や仕様に対するカバレッジ（ブラックボックス系）・・・ユーザ指向、要件指向
          • 構造に対するカバレッジ（ホワイトボックス系）・・・フォールト指向（欠陥を見つけに行く指向）、設計指向
        • テストアプローチを基、テストケースごとに優先度をつけていく
      • テスト条件とテストケースを支援するために必要なテストデータを識別する（※ここでは、識別。実際の値を決めるのではなく、どんなデータが必要か検討）
        • テストデータ；1つ以上のテストケースを実行するための、事前条件・入力値を満たすデータ・・・要するに、テストケースに入れるデータ
        • どんなテストデータが必要になるのかを識別する（例えば↓）
          • アイテムレベル・・・テストツールで自動生成したデータ
          • アイテムを結合したシステムレベル・・・実測データ、本番データ
          • テスト環境を設計し、必要なインフラ、ツールを識別する
          • テスト実行に必要な環境を識別
            • 物理的環境はどうするか？
              • Ex.組み込み：シミュレーション、試作機、量産試作機、実機とか
            • 論理的環境はどうするか？
              • Ex.組み込み：テストドライバ、テストツール、テストデータ（生データ？ダミーデータ？加工したデータ？)
        • 必要なものをどう準備するのかを検討
      • テストベース、テスト条件、テストケース、テスト手順のトレーサビリティ確立

---

※テスト分析～設計までの成果物の整理

テストベースから、テスト条件を作成し、ハイレベルテストケース、ローレベルテストケースと段階を踏んで、具体化していくことがポイントである。

• テスト分析
  • テスト条件
    • 「何をテストするのか？」
• テスト設計
  • テスト設計仕様書(高位(ハイ)レベルテストケース)
    • 「どうテストするのか？」
    • テスト条件を満たすための情報
    • 具体的な入力値・期待値は必要ない
  • テストケース(低位(ロー)レベルテストケース)
    • 「(具体的に)どんなデータでどのようにテストするのか？」
    • テスト実行のための詳細な情報
    • 具体的な入力値・期待値・テスト実行順序、実行優先度が必要

現場では、初めからローレベルテストケース相当のテストケースを作成するが多いが、段階を踏んで具体化していくことで、↓の効果がある

• テスト条件に対する過不足を確認ができる、
• テストベースの変化に対して、どうテストケースを変更（追加）すべきかが特定しやすい。
• テスト環境・テストデータ変更時に、テスト設計仕様書（高位レベルテストケース）は再利用可能

---

• テスト実装

  • テストケースに基づいて、実行の手順、詳細なテストケース、テスト手順書、テストスクリプトというテストウェアへ変換、テスト環境の構築
  • アクティビティ
    • 前段階
      • テスト担当者のスキルセットを定義しておく
        • プログラミングスキル、ドメインスキル
          • テスト手順や段取りなどについて、どれだけ詳細に記述しておくかを把握するため
          • テストの妥当性が低下、目的から外れる、を防ぐため。
      • テストの手順を開発して、優先順位を割り当てる。自動化テストの場合は、テストスクリプトを作成する
        • テストケースは、そのもととなるテスト条件をまたがって、テストスイートとしてまとめることがしばしばおこる
        • このテストケースとこのテストケースは、いっちょの手順でやろう見たいなのをテストセットという
        • で、それを実行する手順をテスト手順という
        • なので、1つのテスト手順のなかで、複数のテストケースを実行することもある
      • テスト手順やテストスクリプトからテストスイートを作成
        • テスト実行のためのテストスイートを作成
        • 特定のテストサイクルで実行するテストのテストケースとテスト手順のセットをテストスイートと呼ぶ
          • Suite:組、一組、的な。
          • スウィートルーム : 《ホテルで寝室・居間・浴室のひと揃いの部屋》.
      • 効率的にテスト実行できるように、テストスイートを調整する
    • テスト実行時の、テスト手順やテストハーネス準備、後片付けなどの効率を考慮し、組み合わせるテストケースを考えて、テストスイートを作成する
    • テスト環境を構築する。またセットアップの確認を行う。
      • テスト対象のセットアップ、
      • インフラ(テストツールやテストハーネス、シミュレーション環境、計測器など)の準備・セットアップ
      • テストを実行する操作以外の準備はここで完了させる
      • テストデータを準備し、テスト環境に適切に読み込ませてあることを確認する
        • テストデータの準備
          • 派生開発なら、以前利用したデータを用意
          • 情報を加工したデータを用意することもある
          • ホワイトボックステストなら、ソースコードに対するカバレッジ計測のために、ソースを静的解析し、テストデータを自動生成することもある
      • テストデータをテスト環境に読み込ませる（テスト環境にテストデータを入れておく）
    • テストベース、テスト条件、テストケース、テスト手順、テストスイートの間でトレーサビリティ確立

• テスト実行

  • テスト実行スケジュールに従ってテストを実行する
  • アクティビティ
    • 実行前
      • テストアイテム(テスト対象)、テストツール、テストウェアのIDとバージョンを記録
    • 実行時
      • 手動またはテスト実行ツールを使用してテストを実行する
    • 実行後
      • 実行結果と期待結果を比較する
        • 合格・不合格のログ記録
        • 単に計測目的の場合は、実行済みとログ記録
      • 不正を分析して、可能性がある原因を特定する
        • 実行結果とテストベースの記載を照らし合わせ、何が不正な動作であるか分析
        • テスト対象を操作した順番、使用するテストデータ、など不正の事象が再現するパターン・ケースを特定。
          • バグの原因を特定するわけではない。
          • どんな条件で、不正が発生するのかを特定するのみ
      • 故障を観察して欠陥を報告する
        • 不正の分析結果から故障や欠陥が認められたら、欠陥レポートにして報告
          • 内容
            • 故障の直接的な事象
            • 他の要因で同一の問題が起きるかどうか。
            • 当該テストケースが他にも影響が出ていないか　など
            • 欠陥レポート＝不具合報告書＝バグレポート＝問題点処理票などとも呼ぶ
        • テスト実行の結果を記録（合格、不合格、ブロック）
          • テストケースごとに記録
          • 結果を期待値と比較した結果を合格/不合格/ブロックで記録
            • ブロック：テスト実行が外部要因で阻まれたということ。
          • 外部要因には、テストアイテムのソフトウェアライセンス購入待ち、テスト実行環境の仕様順番待ちとか。
          • エビデンスの記録：テスト対象のソフトウェア、ソフトウェアの実装環境、テストツール、構成、テストウェアのIDなど
      • 不正への対応結果・計画したテストの一環として、テスト活動を繰り返す。
        • 欠陥が修正対応されれば、確認テストを実施する
        • 修正版リリース直後or確認テストを集約して行う
        • リグレッションテストを行う（不正の修正が、既存機能に悪影響を及ぼしていないかの確認）
      • テストベース、テスト条件、テストケース、テスト手順、テストスイートの間でトレーサビリティ確立

• テスト完了

  • テストウェア（テストケース、テスト実行レポート、欠陥レポート）、プロジェクト上のテストに関する情報のまとめ
  • テスト計画時のテスト目的を果たせているかどうか分析
    • カバレッジは満たせているか？
    • 非機能要件に対するテストは十分に稼働を想定したものとなっているか
    • テスト対象の機能やシステム構成の組み合わせ要因を十分に網羅できたか
  • テスト終了基準に基づいて、終了判断
    • テスト終了基準
      • 合否判定や測定結果から直接判断する基準
      • バグ管理図により判断
        • バグ管理図
          • テストケースの消化率と欠陥検出推移
          • 欠陥が収束しているか
          • まだ欠陥が検出できるのではないか
          • 検出した欠陥はテストの目的で狙ったものか
      • テスト実行結果、テスト進捗状況、欠陥の検出/修正状況が基準を満たすか評価
        • 場合によっては、テスト打ち切りということもある
  • アクティビティ
    • 全ての欠陥レポートのクローズを確認。未解決として残されている欠陥については、変更要求かプロダクトバックログアイテムを作成。
    • 解決されている欠陥に関するレポート（チケット）をクローズ
    • 未解決の欠陥に対して　欠陥の漏れが出ないようにすることを徹底（うやむやにしない）
      • 次のテストレベルで修正されると決まっている場合は、次のテストレベルへ引き継ぐ
      • 未対策ということでプロダクトバックアイテムとして記録
    • テストサマリーレポートを作成して、ステークホルダーに提出
      • テスト結果と終了基準との比較・分析結果から、最終的にそのテストレベルを終了できるかの判定をドキュメント化する
      • ドキュメント化したテストサマリーレポートをステークホルダーに報告
      • サマリーレポート(ISO/IEC/IEEE 29119-3:テスト完了レポート)
        • 合格基準を満足しているか
        • 欠陥レポートの報告件数・対応状況のまとめ
        • サマリーレポートの結論（テスト完了・終了・打ち切り）に対して、ステークホルダーからぐ意を得る
    • テスト環境、テストデータ、テストインフラ、その他テストウェアを次回も使えるように整理し保管する
      • 再利用のための整理・メンテナンス
      • ガイドラインやトレーニング資料の整備
      • テストスクリプトをテストツールのバージョンアップに対応できるようにしておく
      • テストウェアをメンテナンスチーム、他のプロジェクト、ステークホルダーへ引き継ぐ・展開する
      • 保守部門が、テスト結果をプロダクトの品質状況を把握するのに使用
      • リリース後に欠陥が発見された時の、トラブルシューティングに活用
      • 収集した情報をテストプロセスの成熟度をカイゼンするために利用する
    • ポストモーテムの開催
      • ポストモーテム：振り返り会
      • テストコントロールにおける課題や問題、テスト結果やその分析・評価の情報をもとに、テスト活動全体の良かった点、悪かった点を出し合う会議
      • 振り返り、アクションリストを作成し、マネジメント層がチェックすることで、その場限りの振り返りでなく、改善につなげることが大切

目次へ戻る

1.5 テストの心理学

• テストの印象がロールによって違う
  • 開発者の気持ち
    • 「欠陥を指摘する」は自分への非難
    • 重箱の隅をつつくようなてすとでは、テスト担当者の性格を疑っちゃう
    • 開発者本人は、に内部構造を熟知しているがゆえに、確証バイアスが働く
    • テストはコスト高い＆生産性に寄与していない
  • テスト担当者の気持ち
    • 「欠陥を指摘する」は品質向上のための重要な活動
    • テストは、欠陥を見つけるだけでなく、正しく動作していることの確認もしているのだよ。認めておくれ。
• 重要なこと：開発者・テスト担当者の気持ちが異なるからこそ、互いに持つべき認識
  • 協調姿勢
    • ゴールは高品質のシステム開発
  • テストの利点を強調していく
    • 開発担当者にとっての利点
      • 欠陥情報は、品質向上とスキル向上に役立つ
    • 組織にとっての利点
      • テストで欠陥を検出して修正できれば、時間と経費の節約になるし、プロダクト品質のリスクも低減できる
  • テスト担当者は、中立立場であること
    • 発見事項を中間的な立場で伝え、決して開発担当者を非難しないこと
    • 客観的かつ事実に基づいて欠陥レポートを書き、発見事項のレビューを行う
  • テスト担当者は、周囲の否定的な反応の理由を理解するように努め
    • 欠陥内容の優先度や日程的に、開発担当者が修正に着手できないことを理解して、協調する
  • 互いに情報伝達が意図した通りであることを確認する
    • 自分の説明が理解されていることを確認し、相手の説明を正しく理解できているかを確認する
  • 各ロールはマインドセットを持ち、壮途に能力を発揮して補完しあう必要がある
    • コミュニケーションが大切

目次へ戻る

以上　第1章.テストの基礎

参考になれば幸いです。

目次へ戻る