JSTQB(ALTM) シラバス学習：1. テストプロセス
2020.09.19更新
- 1.1 イントロダクション
- 1.2 テストの計画作業、モニタリング、およびコントロール
- 1.2.1 テスト計画作業
- 1.2.2 テストのモニタリングとコントロール
- 1.3 テスト分析
- 1.4 テスト設計
- 1.5 テスト実装
- 1.6 テスト実行
- 1.7 終了基準の評価とレポート
- 1.8 テスト終了作業
1.1 イントロダクション
プロセスの改良
Advanced Level は Foundation Level とはテストプロセスの考え方が異なります。
テストのモニタリングとコントロールを効率化するため以下のように一部を独立したものと考えます。
プロセスの全体像
テストプロセス全体のイメージはITproの記事を参照いただくとイメージつきやすいと思います。
学習の目的
目的はシラバスから引用します。
「テストプロセス」の学習の目的
1.2 テストの計画作業、モニタリング、およびコントロール
TM-1.2.1 (K4)システムのテストニーズを分析して、テスト目的を達成するテスト活動およびテスト成果物を計画する。
1.3 テスト分析
TM-1.3.1 (K3)トレーサビリティを確保し、テスト目的、テスト戦略、およびテスト計画に基づいて定義されたテスト条件の完全性と一貫性をチェックする。
TM-1.3.2 (K2)テスト条件を指定する詳細度に影響を与える可能性がある要因および、詳細にテスト条件を指定することの長所と短所について説明する。
1.4 テスト設計
TM-1.4.1 (K3)トレーサビリティを使用し、定義されたテスト条件に基づいて設計されたテストケースの完全性と一貫性をチェックする。
1.5 テスト実装
TM-1.5.1 (K3)リスク、優先順位付け、テスト環境とデータ依存性、および制約を使用して、テスト目的、テスト戦略、およびテスト計画に対して完全性と一貫性のあるテスト実行スケジュールを作成する。
1.6 テスト実行
TM-1.6.1 (K3)トレーサビリティを使用し、テスト目的、テスト戦略、およびテスト計画との完全性と一貫性という観点で、テスト進捗をモニタリングする。
1.7 終了基準の評価とレポート
TM-1.7.1 (K2)終了基準に対する正確なレポート作成と評価を支援するために、テストプロセスにおける正確でタイムリーな情報収集が重要であることを説明する。
1.8 テスト終了作業
TM-1.8.1 (K2)テスト終了作業における 4 つのグループの作業を要約する。
TM-1.8.2 (K3)プロジェクトの振り返りを実行して、プロセスを評価し、改善する領域を発見する。
1.2 テストの計画作業、モニタリング、およびコントロール
1.2.1 テスト計画作業
ここでは分析結果を正しく活用できますか？ということが問われます。
TM-1.2.1 (K4)システムのテストニーズを分析して、テスト目的を達成するテスト活動およびテスト成果物を計画する。
K4 【分析】状況を分析し、適したものを提案できる
• 例:ステークホルダ、状況、およびソフトウェア開発ライフサイクルモデルを含むプロ ジェクトニーズを分析し、最適なテスト活動を識別する
K4の場合、状況を分析し、シラバスに書かれている内容をもとに適し たものを提案できることが求められる引用元：ALTM過去問題解説
計画作業について
作業範囲
テスト計画作業はの以下の各テストレベルで継続的に実施します。
目的の明確化
まずは目的を明確に定義します。
テストだけではありませんが、作業を開始する際には、その作業が何のために行うものであるのか明確にする必要があります。
目的達成のために必要な要素の特定
目的を達成しプロジェクトを成功に導くために、テスト戦略を分析して必要な要素を特定します。
テスト活動の特定
分析結果からテストに対するアプローチ（テスト活動）を明確にします。
- 採用するテストレベル
- 各レベルの目標と目的
- 各レベルで使用するテスト技法
テスト環境の用意とリソースの特定
テストに必要な環境と、そのためのリソースとコストを明確にします。
- 初期のテスト環境仕様
- テスト環境設定要員
- テスト環境設定作業
- コスト
- スケジュール
さらに外部（外部のベンダや開発パートナーなど）との依存関係やSLA(Service Level Agreement)*1を明確にして、必要に応じて関係する各所と初期に連絡しておきます。
メトリクスの特定
テストの目的を明確にしても、メトリクス（基準）がなければ判断できません。
メトリクスを明確にすることで以下のことが可能となります。
活動例：戦略から戦術への落とし込み（タスク化）
戦略（リスクベースドテスト戦略）の分析
以下の戦略（目的）を実現するためにリスク分析を行います。
リスク分析を行いリスクを明確にすることで、対象となるリスクにフォーカスすることで、対応方法を効率的に計画できます。
- プロダクトリスクの軽減
- コンティンジェンシープラン*2の作成に必要な活動を軽減
分析結果から戦術へ
プロダクトリスク軽減の観点で分析結果から戦術に落とし込んでいきます。
セキュリティに関する深刻な潜在的欠陥を発見した場合
セキュリティテストを開発して実行するための工数を増強する。
設計仕様に関する深刻な欠陥が日常的に発見される場合
設計仕様の静的テスト(レビュー)を追加する。
システム性能に関するリスクが高いと判断される場合
ソフトが使用可能になった時点で性能テストを実行する。
スコープを絞り込む（対象フィーチャを一覧化）
機能一覧を元に探索的テストなどの動的テスト技法で対応する。
1.2.2 テストのモニタリングとコントロール
モニタリングとコントロールはテスト計画の実現のため、継続的に行う必要のある活動です。
テストを適切にコントロールをするためにはテスト計画作業を詳細に行い、計画と進捗を比較して必要に応じて計画作業を是正していくことが重要です。
モニタリングフレームワークの定義
一般的なケース
テストのコントロールを行うためのモニタリングフレームワークを定義します。
ステークホルダが求める測定値と対象が何であるかを明確にして、モニタリングに使用する測定値と対象をフレームワークに含める必要があります。
この測定値と対象は一般的には以下のようなアイテムで定義されます。
- 成果物（開発成果物、テスト成果物など）
- テストベース（要求仕様のカバレッジなど）
- リソース
- スケジュール
上記のアイテムは相互にトレースすることが難しいため、テスト条件を介すると分かりやすくなります。
テスト条件とは
テストベースに基づいてテストケース（手順書）が作成されます。
テストケースには一対一となるテスト条件と期待値が必要となります。
ここで大切なのは、作成したテスト条件はステークホルダの要求を満たすために十分な内容であるか検証することです。
ステークホルダの関心
ステークホルダが関心を持つ測定値と対象が、仕様で定義されているものではない場合があります。そのため、ただ仕様を満足させれば良いのではなく、仕様書では見えないところの要求を見える化するために、ステークホルダとのコミュニケーションは重要な活動になります。
プロジェクトの初期の段階でステークホルダが関与することによって、ステークホルダが求める測定値と対象を定義するのに役立ちます。そして、これらの測定値と対象がテストの進捗を正確にモニタリングするのに役立つだけでなく、上記で示したフレームワークのアイテムの作成にも役立ちます。
テストコントロールについては別の機会に説明します。
1.3 テスト分析
テスト分析を行い目的からテスト条件を明確化して、テスト設計によりテストケースに落とし込みます。
概要図
テストの目的から分析を行い、テスト条件からテストケースを定義しします。それぞれの段階で、トレーサビリティを確保します。
テスト分析の詳細度
テスト分析を行いテスト条件の詳細度を決めるためには、考慮すべき要因がいくつかあります。それぞれの要因の詳細度との関係とメリット・デメリットを記載します。
◎：メリット、✖️：デメリット、◉：効果的な状況
1.4 テスト設計
テストレベルによるテスト設計
1.5 テスト実装
概要
具体的なテストケースをテスト手順、テストデータとして実装する活動です。
組織によって文書化の方法が異なります。
- IEEE829に準拠している組織：テストケース仕様で入力と期待結果を定義し、テスト手順仕様でテスト手順を定義し、それぞれを分けて文書化
- 一般的な組織：入力と期待結果、テスト手順をまとめて文書化
事前確認
実装を開始する前に以下を確認します。
- テストチームがテストを開始できる準備が整っていること
- テスト環境、テストデータ、テストコードが整っていること
- テストケースのレビューが終了していること
- 対象のテストレベルの開始基準（明示的、暗黙的）
- 特定の順序や装置でテストを実行するリスクや優先度などの制約条件
- テスト環境やテストデータの依存関係
注意点
実装作業時は以下の点に注意します。
早期のテスト実装
早期のテスト実装では、「ソフトウェア開発ライフサイクル」または「テストが可能なソフトウェアフィーチャかどうか」を理解してから着手することが、後戻り工数の発生を防ぐため重要となります。以下は早期にテスト実装する場合のメリットとデメリットです。
メリット
- 具体的なテストでは正しい動作状態の稼働例を提供できる
- 具体的な情報によりソフトウェア仕様のさらなる弱点を識別できる
- 必要とされる動作の明確な説明を設計開発者に提供できる
デメリット
１）変化しやすい開発ライフサイクル（アジャイルなど）
- テストスクリプトの陳腐化
２）その他の開発ライフサイクル
イテレーション*3がある場合や要件が頻繁に変更されるようなケース
- 信頼性の低下
- 頻繁な保守
1.6 テスト実行
テスト実行は開始基準を満たしたときに開始され、結果を終了基準によって評価します。
テストマネージャーは、テスト実行がテスト計画に従って進んでいるか進捗をモニタリングして、必要に応じてコントロール活動を行います。
ツール
テストの実行に使用される代表的なツールがあります。
- テストマネジメントツール：テストプロセス管理の支援
- 欠陥追跡ツール：欠陥レポートによるトレーサビリティの確保
- 自動化ツール：テスト効率化と個人のスキルによるテストのばらつき排除
ただし、自動化ツールの導入に関してはメリットばかりではなく、デメリット（導入コストや保守にかかる工数など）もあるため環境に応じた使い分けが必要です。
テスト実行の自由度
基本的にはテスト実行は手順に従って進めますが、ある程度の自由度が必要です。
その理由は、テストは手順通り進めることが目的ではなく、ソフトウェアが期待通り動作することを確認することが目的です。
テスト結果を評価するための基準を用意することは必須ですが、評価基準だけでは判断できない挙動が出ることもあります。また、その基準と異なる挙動に気づくための感度もテストメンバーには大切な要素です。この感度は経験にも左右されますが、品質に関するこだわりによる影響が大きいと考えます。
なぜならテスト実行は、ソフトウェアがステークホルダーの求める品質を満たしているか確認するプロセスなのです。 そして、気づいたときに調査を進めるためは、ある程度自由な時間が必要になります。
1.7 終了基準の評価とレポート
テストは上記の通り、期待通り動作することを確認する作業です。
期待する動作でなければインシデント（欠陥とは限らない）となり、原因の分析が必要となります。
この期待通り動作することを判断する基準が終了基準となります。
評価のための情報
評価の要件定義と情報収集は以下のプロセスで行います。
テストマネージャはこれらのプロセスで用意した情報を、テストチームが必要なときに正確かつタイムリーに提供できるようにしておく役割があります。
- テストの計画
- モニタリング
- コントロール
1.8 テスト終了作業
テスト実行のアウトプットを次工程の担当者に引き渡すか保管する作業がテスト終了作業です。
この終了作業はプロジェクトを永続的に改善するために必要でとても重要な作業ですが、次のプロジェクトのリソースやスケジュールの影響で実施されないことも多くあります。そのようなことを避けるため、テスト計画の段階からタスクに組み込む必要があります。
テスト完了チェック
全ての作業が以下のいずれかの状態で終了していることを確認します。
- 期待通りの結果で終了している。
- 意図的にスキップしている。
- 欠陥を修正して確認テストをしている。
- 欠陥を将来のリリースで対応する。
- 欠陥を制約として許容している。
テスト成果物の提供
永続的な改善を実現するために必要な成果物を提供します。
- 残課題（未改修や許容されている事象）の情報をシステム利用者やサポート担当に提供する。
- テストケースとテスト環境を保守テストチームに提供する。
- 回帰テストセットを文書化して保守テストチームに提供する。
学習した教訓
優れた点は繰り返し、過ちは繰り返さないように、重要な教訓をまとめます。
- 品質リスクの分析：欠陥の偏在パターンから今後の分析セッションに召集するメンバの選出に役立ちます。
- 見積もりの正確性：見積もりと実績の差分を明確にして分析することで、今後の見積もり精度が向上します。
- 欠陥の原因分析及び影響分析の傾向と結果：遅いタイミングで欠陥が発生したテストについて、実施タイミングが適切だったのかなど、欠陥の原因分析から悪い習慣の兆候を見つけます。
- プロセス改善
- 計画との差異：計画と異なる予期しない出来事を明確にすることで、今後の計画の精度が向上します。
構成管理システムで成果物を保管
例えば、テスト計画とプロジェクト計画の両方を計画用のアーカイブに保管して、これらに関係するシステムやバージョンのトレーサビリティを確保します。
