ソフトウェアテスト

ソフトウェアテストとは、テスト対象物であるソフトウェアの品質を評価して改善する方法です。
ソフトウェアの品質は、利用者や顧客の要求や要件を満たすことを指して、テスト対象物を利用価値が高いものにすることです。
品質とテストは同義ではなく、テストは品質コントロール(QC)を実施しすることになります。
また、プロセスの実装と改善のアプローチとして、品質保証（QA）があります。

JSTQBでは、ソフトウェアテストにテスト活動（分析・設計・実装・実行）とマネジメントをする役割の2つが主要な役割と記載されています。

ソフトウェアテストの目的

JSTQBでは、ソフトウェアテストの目的を以下が記載されています。

JSTQBでは、欠陥や故障など以下のように定義されています。

ソフトウェアテストの原則

JSTQBには、ソフトウェアテストの原則があります。
ソフトウェアテストの原則は、JSTQBのテストのガイドラインとし以下7つが記載されています。

テストアナリスト

テストアナリストとは、ソフトウェアやシステムの品質を評価するためにテストの分析、設計、実装、実行を行うテスト技術者です。
ビジネスドメイン（以下ドメインと省略）の観点から貢献して、テスト技法やリスクベーステストなどテストの技術面でテストプロセスに参加して品質の向上に貢献します。

JSTQBのシラバス上では、テスト担当者やテストエンジニアも記載されていますが、これらの役割は主にテストの実行のみに特化しています。
JSTQBのシラバスにはテストテクニカルアナリストの記載がありますが、テストアナリストと比べて技術領域と担当するテストの品質特性が異なります。

テストプロセスにおけるテストアナリストのタスク

テストアナリストのタスクは前述している通り、テストの分析、設計、実装、実行です。
テストアナリストが担当するソフトウェア品質特性として、機能適合性や使用性がメインになります。

ソフトウェア品質特性とテストアナリストのタスク

ソフトウェア品質特性とは、品質を標準化して一定のレベルを保つために定められた主要なカテゴリです。
JSTQBのシラバスでは、ISO/IEC 25010が利用されており、ISO/IEC 25010では以下のように8つのカテゴリがあります。

テストアナリストが実施するソフトウェア品質特性については、ソフトウェア品質特性の章で詳細を記載します。

利用時の品質モデル

ISO/IEC 25010には、ソフトウェア品質特性以外にも利用時の品質モデルがあり、利用者が実際に利用するときの品質を定義しています。
利用時の品質モデルには、以下の5つの定義があります。

テストプロセス

テストプロセスとは、ソフトウェアテストを進めるための工程や流れです。
JSTQBのシラバスによるとテストプロセスは以下の7つのプロセスが定義されています。

テストプロセスは、前の工程が全て完了していなくても、並行して次の工程を進めることが可能です。
これにより、完了した部分から順次次の工程に移行できます。

1

テスト計画

テスト計画は、テスト活動全体の戦略を定めて、テストポリシーとテスト戦略に基づいてテスト計画書を作成します。
テスト計画にはテスト目的、テストのスコープとテストアイテム、テストベース、開始基準・終了基準、テスト成果物、適用可能なテスト技法、測定指標とメトリクス、テストツール、リソース、要員およびグループ、標準への準拠を確認して記載します。
テスト計画には、マスターテスト計画（プロジェクトテスト計画）とレベルテスト計画（フェーズテスト計画）があります。
テストのスコープでは、テストすべき機能や品質特性とテストしない機能や品質特性を定義します。

2

テストのモニタリング、コントロール

テストのモニタリングは、テスト計画で定めた通りにテスト活動が進んでいるか監視します。
主に、リスク、欠陥、テスト、適用範囲をモニタリングします。
コントロールでは、モニタリング結果からテスト活動を調整するプロセスです。

テストのモニタリングとコントロールはテストが完了するまで継続します。 テスト進捗レポートを作成してテストの進捗をレビューします。

3

テスト分析

テスト分析は、テストベースを分析し、テスト可能なフィーチャーを識別して関連するテスト条件を定義し、優先順位を付けます。
関連するリスクとリスクレベルの分析やテスト対象を評価して欠陥の識別、試験性のアセスメントを行います。
テスト分析とは「何をテストするか？」が主な作業内容です。

4

テスト設計

テスト設計は、テスト条件を具体的なテストケースやテストウェア（テストチャーターなど）に変換する作業です。
カバレッジアイテムを識別し、テストデータの要件定義、テスト環境の設計、必要なインフラやツールの識別も行います。
テスト設計とは「どのようにテストするか？」が主な作業内容です。

5

テスト実装

テスト実装は、テスト実行に必要なテストウェアの作成や取得を含みます。
テストケースをテストプロシジャーに編成し、テストスイートにまとめます。
テストケースのレビューを実施します。
手動および自動のテストスクリプトを作成し、効率的なテスト実行のために優先順位を付けて配置します。
テストデータの作成やテスト環境を構築し、正しく設定されていることを検証します。

6

テスト実行

テスト実行は、スケジュールに従って手動または自動でテストを行い、結果を記録し、期待結果と比較します。
テスト実行は、欠陥を検出して品質向上に貢献します。テスト結果は建設的な方法で伝えます。
検出した欠陥を分析し、原因を特定して報告します。

7

テスト完了

テスト完了は、終了基準を満たしているか確認し満たしている場合に完了します。
テストウェアを識別して、保管または適切なチームに引き渡します。
レポートを作成して必要なステークホルダーに提供します。

テストアナリストの主な業務は、前述している通り3～6の分析、設計、実装、実行のプロセスです。
具体的な業務については各プロセスの詳細で説明します。
テスト計画、モニタリング、コントロール、テスト終了はテストマネージャーの役割に含まれます。
これらについては、テストマネージャーの章で詳しく説明します。

テストアナリストは、テスト計画、モニタリング、コントロール、テスト終了の各プロセスにおいて、テストマネージャーから依頼された業務を遂行し、必要な情報を提供する必要があります。
例えば、テスト計画ではテストに関わるスケジュールを作成して提供し、モニタリングやコントロールでは進捗レポートや正確な欠陥情報を提供することで、プロジェクトの推進に貢献します。

テストレベル

テストレベルとは、ソフトウェア開発でテスト活動を段階で実施するテストの種類です。
4種類のテストレベルがあります。

テストレベルはレベルごとに目的や目標が異なります。

テストタイプ

テストタイプとは、ソフトウェア品質特性をまとめたものです。
JSTQBのシラバスでは、以下の4つのタイプが定義されています。

機能テストでは、「何をするのか」で非機能テストは「どのように動作するのか」に重点をおいてテストします。

テストレベルとテストタイプ

すべてのテストタイプはすべてのテストレベルで実行できます。
テストレベルで、どのテストタイプを実行するはテスト計画で定義します。

静的テスト

ソフトウェアを実行しないで、ドキュメントやソースコードをレビューして欠陥を検出するテスト実施方法です。

動的テスト

ソフトウェアを実行して、その結果から欠陥を検出するテスト実施方法です。

テストの独立性

テストの独立性は、テストを実施する際に、テスト担当者が開発チームや他の関係者から独立しているかです。
独立していることで、テストを客観的に実行できて品質や信頼性の向上が期待できます。
独立したテストは以下のような利点があります。

独立したテストのデメリットとして、テスト担当者に情報が共有されなかったりテスト担当者がボトルネックとして扱われる場合があります。

テストの独立性についてはテストマネージャーの章で詳しく記載します。

テストに必要な用語

テストに関する用語を以下に記載します。

テストが主導するソフトウェア開発

通常は、プログラムの実装時にコードを記載してからテストケースを定義しますが、テストが主導するソフトウェア開発ではテストケースを定義してからコードを記載します。

テスト分析

テストアナリストは、テスト計画で定義された範囲からテストベースを分析します。
テスト計画のテスト目的とテストベースを分析して、テスト条件を識別します。
テスト分析では、何をテストするかを決めます。

リスク分析とテスト計画で識別した優先度基準は、分析から実行するまでテストプロセス全体を通して維持する必要があります。

テスト分析のタスク

テストアナリストがテスト分析で実施するタスクには以下に記載します。

トレーサビリティを確立することは、テストのモニタリングとコントロールが効果的になり、カバレッジの評価とテスト監査時のITガバナンスの基準を満たすのに役立ちます。

テスト分析を開始するために満たす開始基準

テストアナリストが、テスト分析を効果的に進めるために満たすための基準を以下に記載します。

テスト分析では、テスト条件を様々な詳細度合いで定義する必要があります。
テスト条件は、抽象的な条件で識別していき、具体的な条件を識別する階層アプローチで実施していきます。

詳細度合いは、ハイレベルとローレベルで定義することがあります。
ハイレベルは抽象的なアプローチで、ローレベルは具体的なアプローチです。
ハイレベルとローレベルの詳細と例を以下に記載します。

ハイレベル（アーキテクチャ）

システム全体を抽象的に捉えて、テストの設計指針や基本的な方向性を記載します。
ハイレベルでは、具体的な記載がないため、テスト実施者によってテストケースが異なります。
以下に例を記載しますが、何を買うかやいくら入れるかの記載がありません。

例）自動販売機にお金を入れて、飲み物を購入する。
期待結果：入れる金額や購入する飲み物などテスト実施者の内容によって異なる。

ハイレベルの長所と短所

ハイレベルの長所について以下に記載します。

ハイレベルの短所について以下に記載します。

ローレベル（コンポーネント）

テストを具体的にし記載します。
そのため、テストを実行者による違いがなく、同じ結果になります。
詳細なテスト手順をドキュメント化し、実施するテストをスクリプトテストともいいます。

ハイレベルの設計を基にして具体的な内容に落とし込んで、実際のテストケースやシナリオを作成してその流れでテストが実行できるように記載します。
以下に例を記載しますが、何をいくら入れて買うかも記載します。

例）自動販売機に150円を入れて、120円の水を購入する。
期待結果：水がと30円のおつりがでること。

ローレベルの長所と短所

ローレベルの長所について以下に記載します。

ローレベルの短所について以下に記載します。

プロダクトリスクが定義済みの場合、各リスクに対処するためのテスト条件を識別し、リスクアイテムに遡る必要があります。
テスト戦略やテスト計画で識別されたテスト技法を適用することで、テスト分析活動を促進してテスト分析の目的達成が容易になります。

テスト分析の目的

テスト分析の目的は、以下の4つです。

テスト分析の完了は、テスト領域が明確で次のテスト設計が行えるようになっていることです。

テスト設計

テストアナリストは、テスト分析で決めたテストする項目をどのようにテストするかテスト設計で決めます。
テスト分析で、何をテストするかが決まりテストベースとテスト計画と戦略からテストの詳細を定義します。

テスト設計のタスク

テストアナリストがテスト設計で実施するタスクには以下があります。

テストケースを設計するときには、テストケースは再利用・検証・トレーサビリティがを考慮する必要があります。

テスト設計の留意点

テストアナリストが、テスト設計を実施するときに留意する点を次に記載します。

テスト設計の識別するアイテム

テストアナリストが、テスト設計を実施するときに識別するアイテムを次に記載します。

テスト実施後の期待結果は、テストオラクルが必要になることが多いです。
テストオラクルがない場合、誤った期待結果を記載したり、期待結果の作成に長い時間を費やすこともあります。

テスト設計では、テスト成果物の文書化に影響を与える要素として、プロジェクトリスク、付加価値、標準や規制、SDLC、トレーサビリティなどがあります。
また、テストケースやリスク分析などの成果物は、テスト設計のレビュー対象です。
そのため、テスト分析およびテスト設計は、静的テストとみなされることがあります。

終了基準は測定可能で、次のプロセス以降で必要な情報が提供され、準備が整っていることが求められます。

テスト実装

テストアナリストはテスト分析とテスト設計に基づいて、テスト手順とテスト実行を行うために必要なものを全て準備します。
テストを開始する基準やテストスイートの最終チェックを実施します。

テスト実装のタスク

テストアナリストがテスト実装で行う作業を以下に記載します。

通常、テストケースを作成してスクリプトテストを実施しますが、アジャイルなど経験ベースのテスト技法ではスクリプトがない場合もあります。
経験ベースのテスト技法を正しく実施できない場合、期間と予測が困難になり欠陥の検出も低下することが考えられます。

テスト実装では、テスト計画で決定したバランスのとれたアプローチでテストを実装します。例えば、リスクベースのテスト戦略と対処的テスト戦略を組み合わせることがあります。
リスクベースのテスト戦略は次の章で説明します。

対処的テスト戦略は、戦略を策定せずに発生したインシデントにに都度対応していく手法です。
そのため、対処的テスト戦略は軽量で欠陥検出には有効ですが、以下の短所もあります。

テストアナリストは、イテレーティブやインクリメンタル開発モデルのときに開発側のリリースとテスト可能な順序を調整します。

終了基準として、テスト環境が構築されてすべてのテストスクリプト・テストウェア・ツールなどテスト実行に必要なものが使用可能であることです。
この作業で、構成管理・欠陥マネジメント・テスト結果の記録と管理が行えるようになっています。
また、終了基準を評価するテスト結果レポートの作成に必要なデータ収集手順も検証します。

テスト実行

テストアナリストは、テスト実装で実装したテストスイートやテストウェアを利用してテスト計画で定めたスケジュールに沿ってテストを実施します。
テスト実行はテスターとテストアナリストが実施します。
欠陥レポートの作成します。

テスト実行のタスク

テスト実行で実施する作業を以下に記載します。

テストアナリストはテスト実行中に以下のタスクも行います。

テスト担当者は、テスト手順に従って実行しますが自由裁量もあります。
テスト結果に応じて、確認したい内容などがあれば追加でテストします。

テストマネージャー

本章では、Advanced Level シラバス 日本語版 テストマネージャーについて記載します。
JSTQBのFoundation Level(FL)についても記載しています。

テストプロセス

テストプロセスは、テストアナリストの章で記載していますのでそちらを参照してください。
テストマネージャーのテストプロセスは、テスト計画・モニタリング・コントロール・テスト終了が主なタスクになります。

テスト計画

テストマネージャーは、テスト戦略とテスト目的に基づいて、何のテスト（テスト対象のテストアイテム）をどれぐらいの期間や工数（必要なリソース）で実施するかを決めます。
テスト戦略はどのようにテストを実施するかで、テスト目的は何のためにテストを実施するかです。
テスト戦略とテスト目的は、テスト計画前に明確になっている必要があります。

テスト戦略とテスト目的以外にもプロジェクトに合わせてテーラリングされた規格や標準なども確認する必要があります。
テーラリングとは、規格や標準などが全てのプロジェクトに適合しないことがあり、規格や標準などをプロジェクトに合わせて調整したものです。

テストマネージャーは、各ドキュメントとテクニカルテストとテストアナリストと協力して、何のためにどのようにテストするかのテスト計画書を作成していきます。
テスト計画書は、ISO/IEC/IEEE29119のテンプレートベースがあります。
一般的に記載する代表的な項目とテストマネジャーが検討する内容を以下に記載します。

項目 内容
テストの目的 テスト対象、テストレベル、リスク、SDLCなどを考慮して目的を記載します。
テストプロジェクト制約 テスト実施時に技術的な制約を記載します。
対象テストレベル 結合テスト、システムテスト、受入テストなど実施するテストレベルを記載します。
システム改修内容 テストする対象のシステムのシステム改修内容を記載します。
テストアイテム テストする対象のアイテムをリストで記載します。（何のテストを実施するか。）
テストタイプ テストレベルやテストアイテムから標準で定めた品質ポリシーやソフトウェア品質特性を記載します。
テストスコープ テスト対象をどこまでテストするかを記載します。テスト対象とテスト対象外になるものを明確にします。
リスク プロダクトリスクの可能性、影響、軽減に関する情報とプロダクトリスク一覧を記載します。
テスト観点 テストタイプやリスクからテスト実施すべき内容を記載します。
テスト技法 標準や目的、テストレベルやテストタイプなどからテスト技法を記載します。テストアナリストやテクニカルテストアナリストが設計するテスト技法に影響しますので。
ステークホルダー プロジェクトマネージャー、テストアナリスト、テクニカルテストアナリストなどテストを実施するにあたり、重要になる登場人物を記載します。テスト要員もアサインする必要があります。また、外部に依存するステークホルダーとコミュニケーションを早期に行う必要があります。
予算 本ソフトウェアテストの予算を記載します。この予算からテスト実施内容やスケジュールなど予算内に収まるまたは予算に収まらない場合は調整が必要です。
スケジュール テストスケジュールを記載します。テストアナリストやテクニカルテストアナリストから提供されるスケジュールを基に作成します。
テスト環境 テスト環境を記載します。環境の構築スケジュールやテストツール・テストデータなども必要に応じて記載します。
成果物 テスト計画からテスト完了までに必要な成果物を記載します。テスト成果物は、要件を基に定義してトレーサビリティマトリクスを使用して、要件からテストの各ファイルに記載されているか追跡できるようにします。最新の仕様を参照する必要があります。
テスト開始/終了基準 テストを開始および終了するための基準を記載します。
テスト完了基準 テストプロセスが完了したと見なすための基準を記載します。
収集するメトリクス 計画順守と目的達成からテスト中に収集するメトリクスを記載します。メトリクスは過不足がないように中止する必要があります。メトリクスを決定すると使用するツール、トレーニングのスケジュール、文書化ガイドラインなども決まってきます。

トレーサビリティマトリクスは前述している通り、要件定義で定義した要件をトレースしていきます。
要件をフェーズで順にINPUTとOUTPUTを以下の表のように記載します。

要件 基本設計 詳細設計 ユニットテスト 結合テスト システムテスト
要件1:ログイン 1-1:ユーザ名入力 基本仕様書 詳細設計書 テストケース テスト条件 テスト条件
1-2:パスワード入力 基本仕様書 詳細設計書 テストケース テスト条件 テスト条件

トレーサビリティは、テスト条件で指定する場合、「要件」→「テスト条件」→「ハイレベルのテストケース」→「ローレベルのテストケース」の順でトレースできるようにします。これにより、各要件がテスト条件に適切に分解され、各テスト条件がハイレベル並びにローレベルのテストケースに確実に関連付けします。

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

テストマネージャーは、テストプロセスが開始されたと同時にテストのモニタリングとコントロールも実施します。
テストのモニタリングとコントロールはテストが完了するまで継続します。
ステークホルダに対して、テスト進捗レポートを作成してテストの進捗もレビューします。

テストのモニタリング

テストのモニタリングは、テスト計画で定めた通りにテスト活動が進んでいるか監視します。
具体的には、テスト計画に記載のスケジュール・成果物とテスト活動のステータスを関連付けします。
この関連付けをモニタリングフレームワークといい、関連付けしたものと収集したメトリクス（テスト実施・リスク・欠陥など）で、テスト活動の進捗を確認します。

テストのコントロール

テストのコントロールは、テストのモニタリングから進捗情報に齟齬や問題を確認して、目的が達成できるようにテスト活動を調整します。

テスト分析

テスト分析は、テストベースを分析し、テスト可能なフィーチャーを識別して関連するテスト条件を定義、優先順位を付ける作業です。
テスト分析とは「何をテストするか？」が主な作業内容で、テストアナリストのタスクになりますので、テストアナリストの章を参照してください。 詳細は、テストアナリストの章を参照してください。

テスト設計

テスト設計は、テスト条件を具体的なテストケースやテストウェア（テストチャーターなど）に変換する作業です。 テスト設計とは「どのようにテストするか？」が主な作業内容で、テストアナリストのタスクになりますので、テストアナリストの章を参照してください。

テスト実装

テスト実装は、テスト実行に必要なテストウェアの作成や取得を含みます。
テストアナリストのタスクになりますので、テストアナリストの章を参照してください。

テスト実行

テスト実行は、スケジュールに従って手動または自動でテストを行い、結果を記録し、期待結果と比較します。
テクニカルテストアナリストやテストアナリストやテスターなどのタスクになりますので、テストアナリストの章を参照してください。

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

テストマネージャは、メトリクスを収集してテストが終了基準を満たしているか評価します。
レポートを提出しますが、頻度と詳細度合いはステークホルダーと協議します。

テスト終了作業

テスト終了作業は、終了基準を満たしているか確認し満たしている場合に完了します。
以下の4つの作業があります。

DDE（Defect Detection Effectiveness）

DDEは、ソフトウェアテストプロセスの効果を測定するためのメトリクスです。
DDEは、テストフェーズごとの効果を評価するために使用され、早期に欠陥を発見することでコストやリソースの削減が期待できます。 計算式は以下になります。

DDE=(テストプロセスで検出した欠陥数全体の欠陥数)×100
ソフトウェアテストの問題→