[初心者向け]テストプロセス-その2

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

テスト作業成果物

テストプロセスごとの主なテスト成果物は以下のようになる。

テストプロセス	テスト作業成果物	内容
テスト計画	テスト計画書	テストベース・トレーサビリティ・終了基準
テストのモニタリングとコントロール	テスト進捗レポート・テストサマリーレポート	テスト実行結果の要約・タスクの完了状況・リソースの割り当てや使用状況・工数などのプロジェクト管理事項
テスト分析	テスト条件・テストベース欠陥レポート・テストチャーター	優先順位をつけたテスト条件・テスト条件とテストベース間のトレーサビリティ
テスト設計	テストケース・テストデータの設計・テスト環境の設計・インフラとツールの選定	ハイレベルテストケース・テストケースと条件のトレーサビリティ
テスト実装	テスト手順書・テストスイート・テスト実行スケジュール・自動化テストスクリプト・ローレベルテストケース・テスト環境	テスト手順の優先度・テストケースをまとめたもの・テストデータをテスト環境に準備・テスト手順とテストベースのトレーサビリティ
テスト実行	テストケース/テスト手順ごとのテストのステータスを記したレポート・欠陥レポート	実行可能、合格、不合格、ブロック、スキップなどのステータス・テストアイテム、テスト対象、テストツール、テストウェアの記述・テスト手順とテスト実行のトレーサビリティ
テスト完了	テストサマリーレポート・アクションアイテム・変更要求/プロダクトバックログ・最終的に完成したテストウェア

テスト計画プロセスの作業成果物

テスト計画プロセスでの成果物は、テスト計画書である。
テストベース（テストケースを考えるもと）に関する情報やトレーサビリティに関する情報、テストのモニタリングとコントロールで使用する終了基準が記述されている。

テストのモニタリングとコントロールプロセスの作業成果物

テストが予定通り進捗しているかを監視（モニタリング）し、計画と差異があったら予定通りに修復するようにコントロールする作業のこのプロセスにおいての作業成果物は、テストレポート（テスト状況報告）である。
テストレポートには、随時または定期的に作成するテスト進捗レポートや、テスト完了時に作成するテストサマリーレポートがある。

これらのレポートには、

• テスト実行結果の要約（テストパターンごとのテスト数と欠陥数、改修済み数など）
• タスク（テスト作業の具体的項目）
• 完了状況
• リソース（テスト要因など）の割り当てや使用状況

などが含まれる。

テスト分析プロセスの作業成果物

テスト分析プロセスでは、各テストレベルにおけるテストベースを分析して、どのようなテストを行うかに関する方針を決定する。このプロセスの成果物の1つはテスト条件である。

テスト条件とは、機能や特徴、品質属性、構造要素などをどのようにテストするかを表した総称のこと。

他にも欠陥レポート（テストベースに含まれる欠陥）を作成することもある。
また、探索的のテスト分析では、テストチャーターを作成する場合もある。

テスト設計プロセスの作業成果物

テスト設計は、テスト分析プロセスの作業成果物であるテスト条件をどのようなテストケースでテストするか、どのようなテストデータを使うか、テスト環境はどうするかなど、テスト条件を具体的な設計に落とし込む作業である。

テストケース

ソフトウェアテストを実行する手順やデータ、期待される結果などをリスト化したものである。
テスト条件を満たすテストケースを作成しておけば、テスト担当者はそこに記載されている手順に従ってテストを実行できるため、チェック漏れを防止する事ができる。

ハイレベルテストケース

抽象的な事前条件、入力データ、期待結果、事後条件、ネオキャリア予備アクションを含むテストケースのこと。
テスト設計プロセスで作成するテストケースとテストケースセットはハイレベルに当たる。

具体例

事前条件	入力データ	期待結果
合計金額により送料無料となるかどうかを確認する	しきい値未満としきい値以上、それに0円の場合も確認する	0円もしくはしきい値未満以上の送料は無料になる

ローレベルテストケース

ハイレベルテストケースを具体的にしたもの。
テスト実装レベルで作成するものだが、ローレベルまで記載せず、テスト担当者の裁量に任せることも多い。

具体例

事前条件	入力データ	期待結果
合計金額が0円の場合に送料有料を確認する	0円の商品をカートに入れる	カートで商品0円、送料600円、合計金額600円と表示される
合計金額が5,000円未満の場合に送料有料を確認する	4,999円の商品をカートに入れる	カートで商品4,900円、送料600円、合計5,599円と表示される
合計金額が5,000円以上の場合に送料無料を確認する	5,000円の商品をカートに入れる	カートで商品5,000円、送料0円、合計金額が5,000円と表示される

テスト実装プロセスの作業成果物

テスト実装プロセスでは、テスト手順の作成、テストスイートの作成・整理、テスト環境の準備、テストデータの準備を行う。

作業成果物（ドキュメント）

テストウェアの中でもドキュメントベースの作業成果物として次の3つを示す。

• テスト手順とそれらの順位付け
• テストスイート（テストケースを分類したもの）
• テスト実行スケジュール

トレーサビリティ

テスト実装におけるトレーサビリティでは、テスト手順とテストベースの関係性を検証する。
テストベースの記載内容をチェックできるテスト手順になっているかどうかを付き合わせて、テストベースの書き漏れやテスト手順の設定漏れがないことをチェックする。

ツールで作成する作業成果物

サービス仮想化ツールを使って構築したサービス仮想化や、テスト自動化ツールを使って作成した自動化テストスクリプトも作業成果物に当たる。

サービス仮想化について参考

シフトレフト

テストを行うのは、全てのモジュールが完成してからとは限らない。
まだ実装できていないモジュールがある場合でも、代わりに表面的なインターフェースの振る舞いを行う仮想モジュールを作ってテストケースを実行し、なるべく早くテストを行うこともある。これをシフトレフトという。

仮想モジュール

仮想モジュールには、テストドライバ（test driver）とスタブ（stub）がある。

テストドライバ

呼び出し側。テストケースを実行するのに必要な値をテスト対象モジュールに私てテストを行う事ができる。

スタブ

呼ばれる側。テスト対象モジュールから呼ばれたスタブは、テストケースに沿った値を返す。

サービス仮想化

こうした仮想的なテスト環境を作成することをサービス仮想化（service virtualization）という。
サービス仮想化を行うための専用ツールも多く出回っている。
モジュールが未完成の場合の代用の他に、外部アプリケーションとの連携において、その代替物としてインターフェースの確認を行う際にもよく使われる。

ドキュメント以外の作業成果物

テスト実行作業で構築したテスト環境やテストデータ、それらの検証結果に関するドキュメントなども作業成果物に含まれる。
テスト実装プロセスでは、テストケースに具体的な中井順平緑地と期待結果を割り当てたローレベルテストケースを準備する。
具体的なテストデータを使って得られた期待結果は、テストオラクルを用いて合否判定する。

テストオラクルとは

テストオラクル（test oracle）とは、ソフトウェアテストの正しさや妥当性を判断するための期待結果のソースである。
例えば、あるテストケースで期待さえた結果が「正常に動作すること」となっていたとする。この場合のテストオラクルは、テスト担当者の常識や専門知識になる。また、期待結果が「旧システムと同じ」だとしたら、テストオラクルは旧システムになる。

⏬こちらの記事がわかりやすくて面白かった
https://www.kzsuzuki.com/entry/2021/04/12/083000

探索的テスト

探索的テストの場合、テスト設計とテスト実装とテスト実行が同時に行われる場合がある。その時は、テスト設計とテスト実装プロセスの作業成果物をテスト実行時に作成する事がある。

テスト実行プロセスの作業成果物

テスト実行プロセスの作業成果物は、テストケースやテスト手順に基づいたテストのステータス（実行状態）を記したレポートである。
テストした結果がどうだったかをテストケースやテスト手順ごとにステータスで報告し、テストのモニタリングとコントロールプロセスでは、それらを集計してテスト状況を判断する。

ステータス

主なステータスは以下のようである。

ステータス	定義
実行可能	テストが実行可能な状態（準備完了）
合格	実行結果が期待結果と一致して、合格と判定
不合格	実行結果と期待結果を比較して不合格と判定
ブロック	実行の前提条件が満たされていないため、テストを実行できない状態
スキップ	テストを実行可能であるが、何らかの理由で実行を延期している状態
エラー	テスト環境の不備などにより、テストを実行できない状態
確定不能	実行結果が不明確で、調査が必要

欠陥レポート

テスト実行プロセスで見つけた欠陥や故障は、欠陥レポートに登録して修復作業に回す。
故障の原因が欠陥ではなく、テストウェアの不備に基づく偽陽性の場合モアpanelため、テストアイテム、テスト対象、テストツール、テストウェアも記載しておくと、欠陥や故障の原因究明に役立つ。

トレーサビリティ

テスト実行プロセスにおけるトレーサビリティの検証とは、テスト手順とテスト実行の突き合わせである。テスト計画の手順が全て実行されたか、実行した内容が手順に記載されているかを照らし合わせ、抜け漏れがないかを確認する。この結果、テストガバレッジ基準が満たされていることをステークホルダーに報告する。
テストガバレッジとは、テストの進捗度を表す指標で、テストで検証すべき項目のうちどれくらいテストが終わったかを割合で表したものである。

テストガバレッジは、テスト対象のソースコードのうち、どのくらいのコードがテストされたかを表す際にも使われる。
この場合は、コードガバレッジともいわれ、テストガバレッジツールを使うことで自動的に取得できる。

テスト完了プロセスの作業成果物

テスト完了プロセスの作業成果物は、テスト前半をまとめたテストサマリーレポートである。
他にも、今後のプロジェクトやイテレーションに役立つ

• アクションアイテム（テスト実行項目）
• 変更要求（どのような修正を要求したか）
• プロダクトバックログ（作業リスト）
• 最終的に完成したテストウェア

なども作業成果物に含まれる。

テストベースとテスト作業成果物との間のトレーサビリティ

テストプロセスとトレーサビリティ

トレーサビリティの検証が重要な理由は以下の二つ。

• 上流プロセスで定義した項目が下流のテストプロセスで実証されないことを防ぐ
• 下流のテストプロセスにおいて、上流プロセスの作業成果物の漏れに気づく

テストプロセスにおける双方向トレーサビリティは以下の通り。

テストプロセス	双方向トレーサビリティ
テスト計画	トレーサビリティに関する情報を計画する
テストのモニタリングとコントロール
テスト分析	テストベースの各要素と関連するテスト条件の間
テスト設計	テストベース、テスト条件、テストケースの間
テスト実装	テストベース、テスト条件、テストケース、テスト手順、テストスイートの間
テスト実行	テストベース、テスト条件、テストケース、テスト手順、テスト結果の間
テスト完了

トレーサビリティの効果

トレーサビリティとテストガバレッジ

テストベースの各要素と関連するテスト作業成果物との間でトレーサビリティを確立すると、テストガバレッジを評価できる。
望ましいのは、テストベースの項目のうちに下流のテストによって何項目がカバーされたかを数字で表すことである。例えば、要件定義で洗い出したユーザーストーリーの何%が検証されたかをテストガバレッジとする場合、これを計測するためにはユーザーストーリーとテストケースを対応づける必要がある。
たあだし、どのテストケースを実行したら、どのユーザーストーリーが検証されるかの関連性を持たせておかなければ、テストガバレッジは計算できない。

トレーサビリティ確立の利点

トレーサビリティを確立すると役立つこととして次の項目を挙げる。

• ソフトウェア変更の影響度を分析する
• テストを監査可能する
• テストベースの要素を含めることで、テスト進捗レポートとテストサマリーレポートを理解しやすくなる
• テストの技術的な側面を、ステークホルダーにとって馴染みのある言葉で説明する
• ビジネスゴールに対するプロダクトの品質、プロセス能力、およびプロジェクト進捗の評価に対する情報を提供する

テストベースのテストガバレッジを数値化すると、ステークホルダーのような高い視点で状況が理解しやすくなるメリットがある。

トレーサビリティを確立すると、変更した影響範囲を分析しやすくなる。
テスト状況が数値化されるため監査しやすくなり、それらの数値を使って、テストレポート（つと進捗レポートとテストサマリーレポート）の内容を定量化できる。

次回