ゼロから始める「JSTQB認定テスト技術者資格」（４日目）
本日は、「1.4 基本的なテストプロセス」について学びます。
◆いきなりまとめ
今回の「基本的なテストプロセス」は内容が盛りだくさんでした。
合理的で効率的なテストに取り組むためには、テスト計画が欠かせないことや、「テストプロセス」で、すべての作業の手順や段取りを検討したり、テストの結果を評価・分析したりするとのことです。
テストプロセス（以下、主要なアクティビティ：計画とコントロール、分析と設計、実装と実行、終了基準の評価とレポート、終了作業）自体を調整していく事が重要であることが分かりました。
以上、いきなりまとめ。
以下、詳細です。
1.4_基本的なテストプロセス
1.4.1_ソフトウェアテストの原則
合理的で効率的なテストに取り組むためには、テスト計画が欠かせない。
正しいテストプロセスを実行する必要がある。
「テストプロセス」とは、すべての作業の手順や段取りを検討したり、テストの結果を評価・分析したりする。
以下、テストプロセス全体の主要アクティビティ
◇計画とコントロール
◇分析と設計
◇実装と実行
◇終了基準の評価とレポート
◇終了作業
どのような流れでテストのアクティビティやそれに付随するタスクを行うかを計画立てて検討し、テストプロセス自体を調整していく事が重要。
1.4.2_テスト計画作業とコントロール
テスト計画の策定では、テストの目的が何かを最初に明らかにする。その目的は、プロダクトの出荷時期や、存在理由によって異なる。
目的を明確化することにより、どんなテストを「何のために」行うかというテストの使命を明らかにする。
コントロールで大切なのは、テストの一連のプロセスをコントロールできるように、テストのアクティビティやタスクの状況を把握すること。つまり、モニタリングを行うこと。モニタリングなしでは、間違った方向にテストが進んでいるのか、それとも順調なのかを客観的に理解できない。
◆テスト計画
◇スコープとリスクを特定し、テストの目的を定義する
まず、テスト対象とする範囲（スコープ）を決定する。どのようなテストを行うのかという目的（欠陥検出主眼、疎通確認の網羅など）を定める。
テストの目的はテスト対象やスコープによって異なる。
スコープを限定することも行う。
さらに、テストの目的を達成するときに障害となり得る要因を挙げる。プロジェクト全体に及ぶようなリスクならば、テスト計画で取り上げるのではなく、プロダクト計画のリスクとして管理する必要がある。
◇テストに対する包括的なアプローチを定義する。これには、テストレベル、開始基準、終了基準なども含む
このタスクでは、テストのポリシーや戦略を決定する。つまり目的の具体化。プロジェクトや企画のゴールに沿ったテストの目的を定めてから、実際にテストで実行することを決める。
戦略に沿ったテストとなるよう以降のアクティビティ（テストケース作成など）を定義する。テストの目的を達成できたかどうか、テストを完了してよいかどうかを判断するための基準はこの段階で決定する。
この基準は、ステークホルダ間で合意を得ることができるものでなければならず、テスト終了基準となる。
テストケースの実施率や合格率だけでなく、予め決めたカバレッジ(注1)を満たしているかどうか、インシデントは収束しているかなど、総合的に判断できるように、複数の基準を決める。
◇何をテストするか、テスト活動でどのような職務を実行するか、いつどのようにテスト活動を進めるか、テスト結果をどのように評価するか、いつテストを終わらせるか（終了基準）を決める
テストレベル毎に適用するテスト技法を決めたり、そのようなテストアイテムが必要かを決める。
テスト結果を正しく評価し、テストをいつ終わらせて良いかを判断できるよう、終了の検討も行う。テストの目的を考えてからカバレッジを決める。
◇定義した色々な活動にリソースを割り当てる
物理的リソースとしてテスト環境がある。場所、動作環境、対象のバージョン、テストツールなどを検討する。
人的リソースとして、ヘッドカウント（人数）、技術者のテクニカルスキルやドメインスキルなど。
◇テストの分析と設計の活動をスケジューリングする
テスト対象を理解するための分析は、分析材料をそろえることから始める。
ブラックボックステスト(注2)を行うのであれば、要求仕様書や企画書やRFP（提案依頼書 Request for Proposal）といったドキュメントを揃える。
グレーボックスやホワイトボックス的な観点ならば、アーキテクチャ定義書、基本設計書や詳細設計書、モデル定義書、データベース設計書といったテスト対象が持つ核となる処理やアルゴリズムといった内部構造を理解できる材料が必要となる。
材料の入手や仕様の問い合わせといった、分析のためのオーバーヘッドを計算に入れる必要がある。
また、分析やテスト設計の速さは、テスト技術者が持つスキルが大きく影響する。
テストの分析と設計の活動をスケジューリングする際には、様々な要因を考慮して、プロジェクトの早い段階でスケジュールを立てる必要がある。
◇テストの実装と実行、テスト結果の評価にかかる活動をスケジューリングする
計画の段階では、概算スケジュールになる。テスト計画段階の初期において、大枠の工数やリソースを割り当てるために用いる。マネージャ等が見積もりを行う。
詳細スケジュールを立てる段階では、実際にテストケースを作成（実装）したり、テストを実施する開発担当者が詳細見積を行う。実際にテストを行う担当者でないと工数予測が立てにくい作業が多い。
テスト実施中の段階では、事前準備、復旧作業、インシデント発生時の工数も必要。実施結果の分析や、品質評価も行うため、実施担当者でないと、精度の高い見積もりを行うのは難しい。
◆テストのコントロール
テストの実施段階では、以下のタスク等を行うことで、テスト計画で定めたテストの目的を達成し、テスト戦略に合致したテストの実施になるようにコントロールする。
◇テスト実施の評価は、合格判定が伴う項目だけではない。
パフォーマンス測定やリソース利用率などは、基準値の近似値または単に測定するだけを行う場合もある。計測値をもとに統計処理を施し、妥当なパフォーマンスが得られているかを分析することも行う。
分析結果や計測値から合否判定を行う場合もある。ホワイトボックステストであれば、コードカバレッジをテスト実施とともに計測し、カバレッジを満たさない様なら、テストケースを追加・修正する。
◇進捗、テストカバレッジ、終了基準のモニタリングと文書化
テスト進捗を消化率や合格率、テストケースあたりの故障発生率、機能単位の欠陥混入率といったメトリクスを用いて、日々、テストそのものの妥当性を随時モニタリングする。
プロジェクトへのフィードバックや妥当性の検証は、毎日または週に一度のプロジェクトミーティングなどで日次報告や週間報告といった形式でドキュメント化し、関係者が把握できるようにする。
テストの進捗状況を把握する頻度は、テストの開発規模（総工数、期間、機能の複雑度）や品質、納期によって異なる。
プロジェクトに適したモニタリングとフィードバックを行いながら、テスト実行をコントロールする。
◇欠陥修正の開始
欠陥の修正とテスト実行は平行で行われる。修正したコンポーネントのテスト対象への反映は、プロジェクト計画やテスト計画で定められた構成管理のタイミングで実施していく。また、インシデントが発生しなくなったかどうかを再度テストで確認するタイミングも、テスト計画で定められたタイミングになる。
欠陥の影響度合いにより回帰テストを行い、既存機能を破壊していないかも検証する。
テストの進捗全体を止めるようなインシデント（アーキテクチャに大影響、基本機能欠陥）等が発生した場合は、いったんテストを中断し、テストの前段階に差し戻して開発作業をやり直すかどうかを検討する。
◇意思決定
テスト進捗のモニタリングを行い、テストの中断、再開、終了といった意思決定を行う。意思決定は管理層、プロジェクトマネージャー、ユーザーが参画する必要もある。
意思決定には開発組織でのエスカレーション手段を備えておく必要がある。
1.4.3_テストの分析と設計
テストの分析と設計は、テストの実装とは別のアクティビティである。
テストの分析では、テスト計画で定めたテスト戦略に基づいてテストを行う情報（テスト対象の性質や品質、特徴などが記されたテストベース）を収集したうえで、情報の取捨選択、再収集、新たに作成することを検討する。
テスト設計は、分析を経てテスト対象に対して手段や戦術を検討すること。
◇テストベース（要件、ソフトウェア完全性レベル（リスクレベル）、リスク解析レポート、アーキテクチャ、設計、インターフェース仕様）をレビューする。
テスト設計の入力となるテストベースをテスト設計する技術者がレビューする。
テストベースには、RFPや企画書、購買仕様書など発注者やユーザーの視点のドキュメントや、要求仕様書やアーキテクチャ定義書、リスク解析レポート、設計仕様書、インターフェース仕様書、標準文書（RFCやISO/IEC標準といった公なものから、社内標準、組織内標準など、組織内での規定も含む)など、テストスコープにより様々なものがある。
また、テストベースには明文化されたものだけでなく、議事メモ、メール等の正規ドキュメント以外も含まれる。
◇テストベースやテスト対象のテスト容易性を評価する
テストベースのレビューを行ったと、テストケースの実現性を検討する。
人に依存しない検証とするために、定性的な評価を定量的な評価に置き換えるテスト設計が必要。段階的な評価を可能とするための基準や、標準といった「ものさし」を用いるか、自ら用意するかを検討する。
テストの容易性は、テスト対象がもつ構造的な観点からも考える。基本設計や詳細設計段階からテスト実施時に、結果が確認できるためのメカニズムを実装に組み込んだり、予めテストツールの利用を見越した設計が必要となる。
「テスト容易性」の開発段階初期での作りこみは、テストの結果や効率といった点からも重要かつ有効である。
◇テストアイテム、仕様、動作、ソフトウェアの構造などの分析に基づいて、テスト条件を識別し優先順位をつける
テストベースの収集からレビューを通した分析により、テストで検証すべき条件や要件を明らかにする。スケジュール面の制約やテスト技術者の資格要件といったものも検討材料とする。
テストアイテムごとの仕様の相違、類似点などをアイテム自身の動作や、ソフトウェアの構造などを分析することによりテスト条件を識別する。
テスト条件が明らかになったら、テストの目的（戦略）に沿うように、テスト条件の優先付けをおこなう。
◇高度なテストケースを設計し、優先順位をつける
テストベースが揃い、テスト分析ができる条件が明らかになれば、テスト設計を開始する。
テスト設計では、テスト計画で示したテストアプローチやテスト設計方針に基づいて、テスト条件をテストの大項目から中項目といった粒度で変換する。いきなり手順や結果値などの詳細を検討せず、テスト条件（要件）を網羅するようにテスト技法を用いて設計する。
「高度なテストケース」とは、抽象度の高いテストケースのことを指す。
網羅性を満たすには、要件や仕様に対するカバレッジとコードカバレッジの両方の視点が重要。テスト設計は、基本的にこれら２つのカバレッジを満たすように行う。
主要なテスト設計の視点例
・「ユーザー志向」テスト対象を利用者の視点で
・「フォールト志向」欠陥を見つける視点で
・「要件志向」要件の妥当性を見る視点で
・「設計志向」設計通りにテスト対象が動作するかの視点で
以上のようにテスト設計を行うと同時に、テストアプローチを基にテストケースごとの優先順位をつける。
◇テスト条件やテストケースをサポートする上で必要なテストデータを識別する
テストアイテム間の機能的連携、アイテムレベルの結合やシステムレベルでの実測データ、本番データの仕様などの検討を行い、必要となるデータの識別を行う。
◇テスト環境を設計し、必要となるインフラストラクチャーやツール類を識別する
テスト実施に必要な環境を物理・論理とそれぞれの側面から識別する。
論理的な側面として、テスト実施におけるミドルウェアやファームウェアの可変パラメータに対するデフォルト値や、チューニング可能なテーブル設定の組み合わせといったことを検討する。
テストの有用性を損なわないようにして代替項目の検討を行う。
品質とテスト実施におけるコストとのトレードオフから、テストの必要性の有無を判断する。
◇テストベースとテストケースの間で双方向のトレーサビリティを作成する
開発の成果物においてトレーサビリティ（追跡可能性）を確保しておかなければ、一貫性と整合性を保った製品開発は出来ない。このことは、テスト設計の基となるテストベースと、テスト設計の結果であるテストケースにおいても同様。
トレーサビリティは、トレーサビリティマトリクスを作成したり、要求管理ツールやALM（ApplicationLifecycleManagment）ツールを導入することで確保する。
1.4.4_テストの実装と実行
「テストの分析と設計」タスクで行われたテストの大・中項目の定義に基づいて、実際にテストを実施するための手順や確認項目の詳細となるテストケースやテスト手順、テストスクリプトといったテストウェアへ変換する。また、テスト実装だけでなく、テスト環境の構築もこのタスクで行う。
前段階として、テスト実施者のスキルセット（プログラミングやドメインスキルなど）を定義する。テストウェアを記述する粒度に直接影響する。
テストの実装と実行アクティビティは以下の１０個のタスクで構成される。
①テストケースを決定し、実装し、優先順位をつける。
ISTQBではIEEE829に準拠した作成物の定義をしているため、テストケースと手順書は分かれている。
優先順位は、テスト計画やテスト設計で決めた優先順位に基本的に準拠する。
②テスト手順を開発し、優先順位を付け、テストデータを作成する。場合によってはテストハーネスを準備し、テストの自動実行スクリプトを書く
手順の作成とデータの作成、テストハーネスの準備は平行して行なうことが多い。
③効率よくテストを実行するため、テスト手順ををベースにしてテストスイートを作る
テストスイートは手順やハーネスの準備、後片付けなどのテスト実行率を考えたうえで、テストケースを組み合わせて考えていく。
基本的に、実施目的、実施効率に直接影響するため、テスト実施に責任を持つ技術者自身がテストスイートを作る。
④テスト環境を正しくセットアップしたことを確認する
テスト実施に先立ち、実施環境全体（テスト対象、ツール、ハーネス、計測機器など）の必要な設備のすべての整備を行う。タスクとしては、セットアップと準備とを必要に応じて分けて管理する。
⑤テストベースとテストケースの間での双方向のトレーサビリティを確認し更新する
テストの分析と設計において、トレーサビリティマトリクスを作成する。
テストの実装と実行では、仕様変更やインシデントへの対応に伴ってテストベースが変更され立時点で、関連したテストケースも変更（削除、修正、追加）していく。
⑥計画した順番に従い、テスト順序を入力、もしくはテストツールで実行する
テストケースの実行には、テストスイートまたはテストケースレベルで規定されたテスト実施の最小粒度ごとに行う事前準備、実行、後片付けの全てが含まれる。
⑦テストの実行結果の記録を取り、テスト対象のテストウェア、テストツール、テストウェアのIDとバージョンを記録する
テスト結果をテストケースや手順で定めた方法に従って記録として残す。
⑧実行結果と期待する結果を比較する
テストケースやて手順の確認項目や判定項目、テスト全体の合否を規定した標準文書の定義とテスト結果を比較する。
結果が一致した場合や、計測だけの場合は、実施済みとして、ログを残し、次のテストケースのじっこうに移る。
⑨両者が一致しない場合、インシデントとして報告し、原因（コード、テストデータやテストドキュメントの欠陥、テスト実行方法の誤りなど）を解明するためにインシデントを分析する
インシデントログ（インシデントレポート、不具合報告書やバグレポート、問題点処理票）にまとめる。
⑩実行結果と期待する結果が一致しないケースごとに、テスト活動を繰り返す。確認テストや回帰テストを行う
確認テストとは、修正が正しいことを確認するため、前回不一致となったテストケースを再実行すること
回帰テストとは、改訂版のテストケースや元のテストケースを実行したり、変更していないプログラム部分に新たな欠陥が入り込んでいないことや、欠陥修正により陰に隠れていた欠陥が現れないことを確認すること。
1.4.5_終了基準の評価とレポート
このタスクでは、テスト終了段階でテストレベルごとに設定した終了基準に対して、テスト実施結果やテスト進捗状況、欠陥の検出/修正状況が、基準を満たしているかどうかを評価する。
終了基準の評価のアビリティは、以下の３つのタスクで構成される。
①テスト結果の記録をテスト計画作業で定義した終了基準と比較する
具体的には、コードカバレッジを満たしているかどうか、要件や仕様に対するカバレッジが十分なテストを実施しているかどうか、非機能要件に対するテストは十分実行稼働を想定したものとなっているかどうか、テスト対象の機能やシステム構成などの組み合わせ要因を十分に網羅しきれたかなどを見る。
②追加テストが必要か、あるいは定義した終了基準を変更すべきかを判断する
③ステークホルダーにテストサマリレポートを書く
1.4.6_終了作業
テスト結果と終了基準の分析から、当該テストレベルを終了することに対して、ステークホルダから合意が得られれば、そのテストレベルの終了が宣言される。
終了作業は以下の７つから構成される。
①計画にある成果物がリリースされたかをチェックする
チェック自体はテクニカルレビューで行い、成果物の有無のチェックはプロジェクトレビューで行う。
②インシデントレポートを終了させるか、もしくは未対策の欠陥を変更記録に乗せる
③システムを受け入れるために文書を作成する
テストを実施を通して妥当であると検証できた内容にまとめ、文書化する。
④次回も使えるように、テストウェア、テスト環境、テストのインフラストラクチャをまとめ、文書に記録する
⑤テストウェアを保守部門に引き渡す
リリース後にインシデントが起きたときのトラブルシューティングなどにおいてテストウェアを利用する
⑥次のリリースやプロジェクトのために教訓とすべきことをまとめる
⑦その情報をテストの成熟度を改善するために利用する
「⑥と⑦」のタスクはセットで行う。テスト終了宣言を受けて該当テストのステークホルダ全員が集まる「ポストモーテム（検死）」を開催する。
ポストモーテムとはテストコントロールにおける課題や問題、テスト結果やその分析・評価をもとに、プロセスやテストウェアを継続的に改善するためにテストのアクティビティ全体の良かった点、悪かった点を包み隠さず話し合う会議のこと。
(注1)テストカバレッジ（てすとかばれっじ）
ソフトウェアテストにおいて、テスト対象となるソフトウェア全体のうち、テストした部分／しようとしている部分が占める割合のこと。一般にパーセンテージで表現される。
情報システム用語事典：テストカバレッジ（てすとかばれっじ） - ITmedia エンタープライズ
(注2)ブラックボックステスト（ぶらっくぼっくすてすと）
ソフトウェアプログラムの内部構造を参照することなく、外部からみた機能や性能について検証を行うソフトウェアテスト技法の総称。テスト対象をブラックボックス（内部が見えない箱）とみなすことから、このようにいう。
情報システム用語事典：ブラックボックステスト（ぶらっくぼっくすてすと） - ITmedia エンタープライズ
最後までお読み頂きありがとうございました。
