徹底攻略 JSTQB Foundation教科書&問題集シラバス2018対応を勉強しているので、自分のメモとしてまとめています。第４弾。

テストプロセスとは

テストプロセスとは、どんなふうにテストを始めてどう終わるかという、テスト活動の最初から最後までの流れを表したもの。
万能なテストプロセスはないが、状況にあったテストプロセスはある。
組織の「状況」の例として以下を挙げる。

ソフトウェア開発ライフサイクルモデル
プロジェクト方法論（プロジェクト管理のやり方）
テストレベル
テストタイプ（目的に応じたテスト種別）
ビジネスドメイン（事業領域）
運用上の制約（予算、リソース、期間、複雑さ、契約や規制要件）
組織のポリシーと実践例
組織内の標準と組織外の標準
など

テストの活動とタスク

7つのテストプロセスの関係

テストプロセスは相互に関連し合う。

テストプロセスとテストの活動・タスクの関係

テストプロセスは、複数のテストの活動で構成される。
1つのテストの活動は、複数の個別のタスクで構成される。

テストプロセスの柔軟性

テストはシーケンシャルに行うだけではなく、テスト活動を重ねたり、組み合わせたり、同時に実行したり、省略したりすることもある。
また、アジャイル開発のように繰り返し行う反復型のケースも多い。
テストプロセスは複数のテスト活動で構成され、てすとかつどうがふくすうのたすくでこうせいされるという関係を理解しておく。

テスト計画プロセス

テスト計画プロセスでは、納期や予算などの制約の範囲内で、テストの目的を達成するためのアプローチを定義する。スケジュールやコスト、品質の計画を立てることが目的である。
スケジュールの計画ではガントチャートを使ってテストタスクの定義をしたり、品質の計画では各テストレベル（単体テスト・結合テスト・システムテスト・受入テスト）に見合ったテスト方法を選ぶ。
これらの計画は、テストのモニタリングとコントロールプロセスで把握した状況のフィードバックにより更新される場合がある。

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

テストモニタリングは、テストの進捗状況を監視してテスト計画と比較する作業のこと。
テストコントロールは、計画通りにテストが進捗するように対策を講じてリカバリーすること。
想像以上にバグが出た、テスト担当者が行機で休んだ、プログラミングが遅れてテスト開始が遅くなったなど、テスト計画通りに進まない要因は山のようにある。これらの状況をテスト計画書で定義したテストモニタリングのメトリクス（活動を定量化することでデータとして管理しやすくした指標）を使用して把握し、テスト担当者の増員やタスクの組み換えなどの対策を行って、計画通りに進めようとするのがテストコントロールである。状況によってはテスト計画を見直す必要が生じることも多く、そのようなテスト計画書の継続的な更新活動もテストコントロールに含まれる。
メトリクスでは、単に定量化するだけでなく指標化することがポイントである。テストモニタリングにおいては、テストの進捗度・欠陥検出数・不良率などが指標化する対象になる。

テスト分析プロセス

テストベース

テストベースとは、テストケースを考える際のソース（元となる資料、元ネタ）のことである。
テスト分析プロセスでは、テストベースを分析して、何のテストをするかを決定する。

テスト対象ごとのテストベース

テストレベルとテストで検証したい対象には深い関係がある。
要件に合致しているか、設計通りか、実装が間違っていないかなど、テスト対象によってそれぞれテストベースは異なる。

テスト対象	主なテストベース
要件	要件仕様・機能要件・ユーザーストーリー・ユースケース・ビジネス要件・システム要件・エピック・期待される機能および非機能要件
設計	設計及び実装情報・設計仕様・モデル図（UMLやER図）・コンポーネントやシステムの構造を指定する成果物・アーキテクチャ図・コールフローグラム・インターフェース仕様
実装	コンポーネントまたはシステム実装そのもの・コード・データベースのメタデータやクエリー・インターフェース
全体	リスク分析レポート・コンポーネントやシステムの機能、非機能、構造

上記表の用語説明

ユースケース：システムの利用シーンをユーザー目線で図解したもの
エピック：システムやビジネス全体の目的を表すもの
UML：システムの振る舞いや構造を図で表す標準規格
ER図：データベース設計をビジュアルに行う手法
アーキテクチャ図：システムの構造（アーキテクチャ）を図で表したもの
メタデータ：データそのものではなく、データを格納するための仕組みの情報
クエリ―：リレーショナルデータベースを操作するための標準言語

テスト対象とそれぞれに対応するテストベースは重要だ。テスト大正琴にどのようなものがテストベースとなるのか、関連性をよく理解しておく。

欠陥の種類を分析する

シラバスでは次のような種類の欠陥を挙げる。

曖昧
欠落
不整合
不正確
矛盾
冗長なステートメント（プログラミングコードが冗長で無駄に長くなっている状態）

例えば、曖昧に基づく欠陥が多ければ、設計のレビューを強化して曖昧な記述がないように改善するという対策をとる必要がある。
冗長なステートメントでは、ドキュメントであれば推敲作業で文章を読みやすくし、プログラミングであればリファクタリングという作業でコードをすっきりさせるなどの対応がある。

フィーチャーとフィーチャーセットを洗い出す

フィーチャー（feature）

日本語で「特徴」「機能」「要望」などと訳される。
システム開発におけるフィーチャーは、ユーザーの立場から見たソフトウェアの機能や特徴のことを指すことが多く、要件仕様で規定したコンポーネントやシステムの要件、信頼性、使用性（ユーザビリティ）、設計上の制約などを指す。

フィーチャーセット

フィーチャーをセットにしたもの。
例えば、使用性に関するフィーチャーをまとめたものをセットとして扱い、使用性テストの計画を立てる。
テスト分析では、テストすべきフィーチャーセットを分類すると、それぞれでどのようなテストを実施するかに関する計画を立てることができる。

アジャイル開発の手法に、フィーチャー駆動開発（FDD）というものがある。
ユーザー駆動開発ともいわれ、ユーザー目線で価値のある機能（フィーチャー）を中心に開発を進める手法で、この場合のフィーチャーは機能、フィーチャーセットは機能パッケージを意味する。

テスト設計プロセス

テスト分析プロセスでは「何をテストするか」を決定してテスト条件を作成するのに対し、テスト設計プロセスではテスト条件をもとにして「どうテストするか」をテスト技法を使って具体的な内容の落とし込む。

テスト条件

テスト条件（test condition）とは、機能や特徴、品質属性、構造要素などをどのようにテストするかを表した総称である。どのようなテストケースで、どのようなテストデータを用意し、どのようなテスト環境でテストを行うかを決めていく。
テスト設計は、テスト分析で得られたテスト条件を具体的なテスト設計に落とし込む作業になる。

主な活動は以下になる。

テストケース
テストデータ
テスト環境
トレーサビリティ

テストケースやテストケースのセットの設計

テスト設計では、テストケースや、テストケースを目的ごとにグルーピングしたテストケースセットを作成し、優先度を割り当てる。テストケースには、抽象的なテスト内容を記載するハイレベルと、具体的な事前条件やテストデータ、期待される結果を記載するローレベルがある。テスト設計で作成するのはハイレベルになる。

テストデータ

テスト設計では、テスト条件を満たすテストケースを作成するのに必要なテストデータを識別する。
具体的なテストデータそのものを決めるのではなく、このような種類のデータを準備すべきという想定にとどめる。

テスト環境

テスト設計では、テストに必要なインフラストラクチャーとツールを識別する。
具体的なテスト環境ではなく、どのようななインフラやツールが必要かという方針を決めることになる。

トレーサビリティ

トレーサビリティ（traceability）とは、trace(追跡)とability(可能性)を組み合わせた英単語で、「追跡可能性」と訳される。ここでは追跡というよりも関係性という意味合いになる。
テストベースとテスト条件、テストケースの間で双方向のトレーサビリティ（関係性）に注目することを意味している。
テストケースとテスト条件の関係であれば「あるテスト条件を確認するためのテストケースを作成する」や「このテストケースがテスト完了すれば、テスト条件のこの部分が確認されたことになる」などが当てはまる。

テスト実装プロセス

テスト設計プロセスは「どうテストするか」を具体的な内容に落とし込むことであるのに対し、テスト実装プロセスは「テスト実行に必要なものをすべて準備すること」である。

テストウェアの作成

テストウェア（testware）とは、テストプロセス（計画、設計、実行など）で必要となる作業成果物全般を指す言葉である。

テスト手順書、テストスクリプト、テストスイート、テスト環境、セットアップとクリーンアップ処理手順、テストデータ（入力と期待結果）、ファイル、データベース、テストで使用するツールやユーザビリティなど

テストスイートの作成・整理

テスト実装では、効率的にテストを実行できるようにテストスイートを作成・整理する。
テストスイート（test suit）とは、類似のテストケースを束ねたもの。
ソフトウェアテストでは、多くのテスト目的などによりテストケースをいくつかのグループに分類するが、この分類された束をテストスイートと呼ぶ。

テスト環境とテストデータの準備

テスト環境の準備では、

テストハーネス
サービス仮想化
シミュレータ

などの環境構築を行う。

テストハーネスとは、テストを実行するために必要なソフトウェアのことで、システムが完成していない段階でソフトウェアが正しく動作するかどうかを確認するための疑似的な動きを行う。
サービス仮想化とは、テストハーネスと同じような目的で使われる技術で、システム環境が本番同様になっていない段階で、必要なサービスを模擬的に実行してくれるものである。
テストデータの準備は、テストを効率的に実施するためのテストデータを準備して、テスト環境にセットする。

トレーサビリティの検証

テスト実装におけるトレーサビリティとは、テストベースやテスト条件、テストケース、テスト手順、テストスイート間の関係性である。テスト実装プロセスではこれらを検証して明らかにする。

探索的テストの場合

探索的テストなどの経験に基づいたテストでは、テスト設計とテスト実装はテスト実行と一緒に行われる場合がある。

探索的テスト（exploratoty testing）とは、最初にテストケースをすべて作成するのではなく、テストの状況に応じて、テスト担当者が自分の経験を活かして柔軟にテスト内容を作成、変更するテスト方法である。

テスト実行プロセス

テスト分析で何をテストするかを決め、テスト設計でテストの方法を設計し、テスト実装でテストの準備を行ったら、テスト計画で立てたスケジュールに基づいてテスト実行を行う。

主な活動は以下の順で行われる。

IDとバージョンの記録（テストアイテム、テスト対象、テストツール、テストウェアなど）
テストを実行（手動又はテスト実行ツール）
実行結果と期待結果を比較
不正を分析して原因を規定（偽陰性にも注意）
故障を観察して欠陥を報告
テスト実行結果を記録（合格、不合格、ブロックなど）
上記テスト活動を繰り返す（修正テストケース、確認テスト、リグレッションテスト）
トレーサビリティの検証（テストベース、テスト条件、テストケース、テスト手順、テスト結果）

IDとバージョンの記録

最初に、テストアイテム（項目）やテスト対象、テストツール、テストウェアなどのIDとバージョンを記録する。
テスト実行で欠陥を指摘したとき、それが本当に欠陥なのか偽陰性なのかを判断する材料になる。

テスト実行と、実行結果・期待結果の比較

手動又はテスト実行ツールを使ってテストを実行し、実行結果と期待結果を比較する。期待される結果はテストケースに書いていないこともあるが、不審に思った点は見過ごさずに確認することが大切。

原因を特定

不正（実行結果と期待結果の差異）が発見された場合、それを分析して可能性のある原因を特定する。欠陥と思ったものが正常である偽陰性もあるので注意。

欠陥の報告とテスト実行結果の記録

故障の状態を確認して欠陥を報告し、これらのテスト実行結果を記録する。
画面キャプチャを添付したり、操作手順を明確にしたりして、開発者が再現しやすいようにすることが大切。

テストの繰り返し

テストで見つかった欠陥が修正された際にも、欠陥が正しく修正されたかを確認するために同じテストケースでももう一度テストを行う。修正内容によってはテストケースを追加して再テストを行う場合もある。コードの修正によって、正常だった部分が不正となることもある。

リグレッションテスト

リグレッション（regression）とは、プログラムの変更・修正したときに、正常だった部分に影響が及んで不正になってしまうことである。そのような不正が起こっていないか確認するテストを、リグレッションテスト（回帰テスト、退行テスト）と呼ばれている。

デグレ―ション

リグレッションと似たような意味の言葉。
リグレッションは「元に戻る」、デグレ―ションは「悪くなる」という意味になるが、通常は同じ意味で使われる。

トレーサビリティの検証

テスト実行においては、テストベースやテスト条件、テストケース、テスト手順、テスト結果の愛他で双方向のトレーサビリティを検証する。
例えば、あるテスト結果を見てテストベースの書き漏れに気づいたり、テストベースに追記した内容をもとにテストケースを追加したりということがある。

テスト完了プロセス

テスト完了プロセスの活動は、ソフトウェアシステムがリリースされたとき、プロジェクトが完了したとき、アジャイル開発プロジェクトのイテレーションが完了したとき、テストレベルが完了したとき、メンテナンス版のリリースが完了したときなどに実施する。

テスト完了プロセスの役割は以下の２つ。

テストプロセスのテストのモニタリングとコントロールによる状況把握 → 終了基準を満たしていると判断された場合にテスト完了と判断する。
テスト活動から得た情報を改善に利用すること

テスト完了プロセスの主な活動は以下の手順で行われる。

欠陥のクロースの確認
未解決の欠陥のバックログ作成
テストサマリーレポートの作成
テストウェアの整理・保管
テストウェアの引継ぎ
テストで得た教訓をフィードバック
テストで得た情報を改善に利用

欠陥クローズの確認

テストでは、欠陥が発見された際に欠陥レポートを記録する。
このとき、還俗的には全ての欠陥レポートがクローズ（対応済）していることを確認する。

プロダクトバックログの作成

プロジェクトの状況によっては欠陥が残っている場合もある。
その時は未解決の欠陥についてプロダクトバックログを作成して、開発チームに対応を要求しておく。

プロダクトバックログ（product backlog）とは、プロダクトにおいて優先的に行うべき作業をリスト化したものである。

テストサマリーレポートの作成

テスト完了プロセスには、ステークホルダーに対して完了報告をする役割がある。
この報告書がテストサマリーレポートだ。未解決の欠陥が残っている場合もありますが、レポートにその情報とそれが引き起こすリスクの評価を記載して、本稼働するかどうかの判断材料を提供する。

テストウェアの整理・保管と引継ぎ

リリース後のシステムは稼働し続けるため、テスト環境やテストデータなどのテストウェアは使い捨てにせずに次回も使えるように整理して保管しておく。
これらのテストウェアをメンテナンスチームに引き継ぐことで、運用後のメンテナンスの際にテストに役立てる事ができる。

教訓のフィードバックと改善

テスト完了のもう一つの役割は、今後に活かす事である。
一連のテスト活動から得られた教訓を分析し、次のリリースやプロジェクトやイテレーションのための改善したり、収集した情報をテストプロセス全体の改善に利用したりする。