JSTQB 1章テストの基礎 - テストエンジニアの備忘録だよっ

■基本用語
・エラー、誤り：人間の動作の誤りを指す
・バグ、欠陥、フォールト：故障を引き起こすコンポーネントやシステムの欠陥を指す
・故障：コンポーネントやシステムが期待される結果とならないことを指す
・インシデント：障害のことで、原因がバグによるものだけに限らず調査が必要とされるようなイベントを指す
・テストアイテム：テスト対象。IEEE829では関連するドキュメントとしてテストアイテム送付レポートが標準化されている
・テストベース：テストの根拠となる要求仕様書などのドキュメントを指す
・テストケース：テストの為に入力値、実行前の状態、予想結果、実行後の状態を定義したもの
・テスト条件：コンポーネントやシステムで1つ以上のテストケースによって検証できるアイテムやイベントを指す
・テストスイート：関連するテストケースの集まりを指す
・テスト手順：テストを実行する為の手順
・テスト環境：テストを行う為に必要なハードウェア、計測機器、シュミレータ、ソフトウェアツールを指す
・テストハーネス：テストを行う為に必要なスタブやドライバからなる環境を指す
・テストオラクル：テスト結果を比較するための予想結果を決定するもので、現行システムを指す
・テストウェア：テストに関するものすべての成果物を指す
・テストプロセス：テストが計画とコントロール→分析と設計→実装と実行→評価とレポート→終了作業と勧められる
・IEEE829：テスト計画書、テスト設計仕様、テスト結果記録、インシデントレポート、テストサマリレポートのドキュメントが標準化されている

■テストの7原則
・原則その1：テストは欠陥があることしか示せない
・原則その2：全数テストは不可
・原則その3：初期テスト
・原則その4：欠陥の偏在
・原則その5：殺虫剤のパラドックス
・原則その6：テストは条件次第
・原則その7：「バグゼロ」の落とし穴

■ソフトウェアライフサイクル
・ソフトウェアライフサイクル
ソフトウェアの一生という意味で、ソフトウェアを企画してから廃棄されるまでの期間を指す。この活動をソフトウェアサイクルプロセスと呼ぶ
・V字モデル：開発ライフサイクルの活動の前後関係とテストベースとテストの対応関係を表すモデル
・ライフサイクルモデル：シーケンシャル開発モデルとイテレーティブインクリメンタル開発モデルがあり、テストのアプローチが異なる
・シーケンシャル開発モデル：V字モデルに沿って順番に進めるライフサイクルモデルである
・イテレーティブ-インクリメンタル開発モデル：V字モデルを繰り返すライフサイクルモデルである

----追加要素----

・ソフトウェアサポートにかかるコスト

ソフトウェアが意図したとおりに正しく動作しないことにより、起こる問題として経済的な損失がある

サポート業務の中でも、特にクレーム受付や製品回収にかかるコストである

・ソフトウェア設計、ソフトウェアテスト設計にかかるコスト

開発コストになる

・ソフトウェア構成管理にかかるコスト

開発コストでもあり、保守にかかるコストになる

・納期のプレッシャーによって起こる事象

エラー、誤りで起こる

・テストの充分性を決める為に考慮すべきリスク

リリース後に、技術の課題が残ってしまうリスク、開発者が退職してしまうリスク、安全性に問題が残るリスク、仕様変更が入るリスク

・テストメンバーの作業割り振り

・テスト実行前作業

テストマネージャー：テスト計画

テストリーダ：テスト計画

テスト担当者：テスト条件の選択、テスト設計、

・テスト実行時

テストマネージャ：テスト終了基準の検証、テスト結果の報告

テスト担当者：実行時のチェック

■テスト実行後の作業

テスト担当者：テストウェアの整理

■全体を通して行われる作業

テストマネージャ：テストコントロール

■テスト計画

・スコープとリスクを特定し、テストの目的を定義する

・どのようにテストをすべきか、プロジェクトや規格のゴールに沿ったテスト目的を定める

・テストの目的を達成したか、完了するかどうかの定義を決める、この基準はステークホルダー間で合意を得ることができるものでなけれなならない

・どのようにテストを進めるか、テスト結果を評価するか、終了基準を決める

・テスト実施場所、動作環境、テスト対象のバージョン、テストツールなど活動にリソースを割り当てる

・ブラックボックスなら要求仕様書、企画書、RFPなどのドキュメントを用意する

ホワイトボックスならアーキテクチャ定義書、基本設計書、詳細設計書、モデル定義書、データベース設計書など用意し、テスト分析と設計の活動をスケジューリングする

・テストケース作成、テスト環境の整備といった工数など、テストの実装と実行や、事前準備、データや設定値などの復旧処理、インシデントにかかる工数などテスト結果の評価にかかる活動をスケジューリングする。これらはテスト担当者が見積もりを行う。

・テストコントロール

・テスト結果の計測と分析

・進捗、テストカバレッジ、終了基準のモニタリングと文書化

・欠陥修正の開始

・意思決定

■テスト分析と設計

・テストベースをレビューする

・テストベースやテスト対象の基礎や標準といったものさしを用いるかどうかテスト容易性を評価する

・テスト条件を識別し、優先順位をつける

・テストケースを設計し、優先順位をつける

・テスト条件やテストケースをサポートする上で必要なテストデータを識別する

・テスト環境を設計し、必要となるインフラストラクチャやツール類を識別する

・テストベースとテストケースの間で双方向のトレーサビリティを作成する

■テスト実装と実行

・テストベース、リスク解析レポート、アーキテクチャ、設計をレビューする

・テスト者の主観によって結果が左右されないようにものさしを定義する

・テストアイテム、仕様、動作、ソフトウェアの構造などの分析に基づいてテスト条件を識別し優先順位を付ける

・テスト条件（テスト要件）を網羅するようにテスト技法を用いて設計する。

テスト設計の視点例

・ユーザ指向：テスト対象を利用する視点でみる

・フォールト指向：欠陥を見つけるため

・要件指向：要件の妥当性を見つけるため

・設計指向：設計通りにテスト対象が動作するかを見る

・テスト条件やテストケースをサポートする上で必要なテストデータを識別する

・テスト環境を設計し、必要となるインフラストラクチャやツール類を識別する

・テストベースとテストケースの間で双方向のトレーサビリティを作成する

■テスト実装と実行

・テストケースを決定し、実装し、優先順位を付ける

・テスト手順を開発し、優先順位を付け、テストデータを作成する。場合によったはテストハーネスを準備し、テスト自動実行スクリプトを書く

・効率よくテスト実行するため、テスト手順をベースにしてテストスイートを作る

・テスト環境を正しくセットアップしたことを確認する

・テストベースとテストケースの間で双方向のトレーサビリティを確認し更新する

・計画した順番に従い、テスト手順を人力、もしくはテストツールで実行する

・テスト実行結果の記録を取り、テスト対象のソフトウェア、テストツール、テストウェアのIDとVerをエビデンス（証拠）を記録する

・実行結果と期待する結果を比較する

・両社が一致しない場合、インシデントとして報告し、原因を解明するためにインシデントを分析する

・実行結果と期待結果が一致しないケース毎にテスト活動を繰り返す

確認テスト：前回不一致となったテストケースを再実行

回帰テスト：変更していない部分に新たな欠陥がはいりこんでいないか確認する

■終了基準の評価とレポート

終了基準の評価は以下の３つのタスクになる

・テスト結果の記録をテスト計画作業で定義した終了基準と比較する

：要件や仕様に対するカバレッジが十分なテスト実施したか等。

・追加テストが必要か、あるいは定義した終了基準を変更すべきか判断する

：終了基準を満たしていない場合はさらに追加テストが必要かどうか判断する

・ステークホルダーにテストサマリーレポートを書く

：テストレベルを終わらせた後に直接的/間接的に影響を受ける関係者に近況報告をする

■終了基準

終了作業は以下の７つから構成されている

・計画にある成果物がリリースされたかをチェックする

・インシデントレポートを終了させるか、もしくは未対策の欠陥を変更記録に載せる

・システムを受け入れるために文書を作成する

・次回も使えるように、テストウェア、テスト環境、テストのインフラストラクチャをまとめ、文書を記録する

・テストウェアを保守部門に引き渡す

・次回のリリースやプロジェクトのために教訓とすべきことをまとめる

・その情報をテストの成熟度を改善するために利用する

■テストプロセスの主要な作業

計画とコントロール、分析と設計、実装と実行

・ソフトウェアサポートにかかるコスト

ソフトウェアが意図したとおりに正しく動作しないことにより、起こる問題として経済的な損失がある

サポート業務の中でも、特にクレーム受付や製品回収にかかるコストである

・ソフトウェア設計、ソフトウェアテスト設計にかかるコスト

開発コストになる

・ソフトウェア構成管理にかかるコスト

開発コストでもあり、保守にかかるコストになる

・納期のプレッシャーによって起こる事象

エラー、誤りで起こる

・テストの充分性を決める為に考慮すべきリスク

リリース後に、技術の課題が残ってしまうリスク、開発者が退職してしまうリスク、安全性に問題が残るリスク、仕様変更が入るリスク

・テストメンバーの作業割り振り

・テスト実行前作業

テストマネージャー：テスト計画

テストリーダ：テスト計画

テスト担当者：テスト条件の選択、テスト設計、

・テスト実行時

テストマネージャ：テスト終了基準の検証、テスト結果の報告

テスト担当者：実行時のチェック

■テスト実行後の作業

テスト担当者：テストウェアの整理

■全体を通して行われる作業

テストマネージャ：テストコントロール

■テスト計画

・スコープとリスクを特定し、テストの目的を定義する

・どのようにテストをすべきか、プロジェクトや規格のゴールに沿ったテスト目的を定める

・どのようにテストを進めるか、テスト結果を評価するか、終了基準を決める

・テスト実施場所、動作環境、テスト対象のバージョン、テストツールなど活動にリソースを割り当てる

・ブラックボックスなら要求仕様書、企画書、RFPなどのドキュメントを用意する

・テストコントロール

・テスト結果の計測と分析

・進捗、テストカバレッジ、終了基準のモニタリングと文書化

・欠陥修正の開始

・意思決定

■テスト分析と設計

・テストベースをレビューする

・テストベースやテスト対象の基礎や標準といったものさしを用いるかどうかテスト容易性を評価する

・テスト条件を識別し、優先順位をつける

・テストケースを設計し、優先順位をつける

・テスト条件やテストケースをサポートする上で必要なテストデータを識別する

・テスト環境を設計し、必要となるインフラストラクチャやツール類を識別する

・テストベースとテストケースの間で双方向のトレーサビリティを作成する

■テスト実装と実行

・テストベース、リスク解析レポート、アーキテクチャ、設計をレビューする

・テスト者の主観によって結果が左右されないようにものさしを定義する

・テストアイテム、仕様、動作、ソフトウェアの構造などの分析に基づいてテスト条件を識別し優先順位を付ける

・テスト条件（テスト要件）を網羅するようにテスト技法を用いて設計する。

テスト設計の視点例

・ユーザ指向：テスト対象を利用する視点でみる

・フォールト指向：欠陥を見つけるため

・要件指向：要件の妥当性を見つけるため

・設計指向：設計通りにテスト対象が動作するかを見る

・テスト条件やテストケースをサポートする上で必要なテストデータを識別する

・テスト環境を設計し、必要となるインフラストラクチャやツール類を識別する

・テストベースとテストケースの間で双方向のトレーサビリティを作成する

■テスト実装と実行

・テストケースを決定し、実装し、優先順位を付ける

・テスト手順を開発し、優先順位を付け、テストデータを作成する。場合によったはテストハーネスを準備し、テスト自動実行スクリプトを書く

・効率よくテスト実行するため、テスト手順をベースにしてテストスイートを作る

・テスト環境を正しくセットアップしたことを確認する

・テストベースとテストケースの間で双方向のトレーサビリティを確認し更新する

・計画した順番に従い、テスト手順を人力、もしくはテストツールで実行する

・テスト実行結果の記録を取り、テスト対象のソフトウェア、テストツール、テストウェアのIDとVerをエビデンス（証拠）を記録する

・実行結果と期待する結果を比較する

・両社が一致しない場合、インシデントとして報告し、原因を解明するためにインシデントを分析する

・実行結果と期待結果が一致しないケース毎にテスト活動を繰り返す

確認テスト：前回不一致となったテストケースを再実行

回帰テスト：変更していない部分に新たな欠陥がはいりこんでいないか確認する

■終了基準の評価とレポート

終了基準の評価は以下の３つのタスクになる

・テスト結果の記録をテスト計画作業で定義した終了基準と比較する

：要件や仕様に対するカバレッジが十分なテスト実施したか等。

・追加テストが必要か、あるいは定義した終了基準を変更すべきか判断する

：終了基準を満たしていない場合はさらに追加テストが必要かどうか判断する

・ステークホルダーにテストサマリーレポートを書く

：テストレベルを終わらせた後に直接的/間接的に影響を受ける関係者に近況報告をする

■終了基準

終了作業は以下の７つから構成されている

・計画にある成果物がリリースされたかをチェックする

・インシデントレポートを終了させるか、もしくは未対策の欠陥を変更記録に載せる

・システムを受け入れるために文書を作成する

・次回も使えるように、テストウェア、テスト環境、テストのインフラストラクチャをまとめ、文書を記録する

・テストウェアを保守部門に引き渡す

・次回のリリースやプロジェクトのために教訓とすべきことをまとめる

・その情報をテストの成熟度を改善するために利用する

■テストプロセスの主要な作業

計画とコントロール、分析と設計、実装と実行