テストアナリスト

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

ソフトウェアテスト

ソフトウェアテストとは、テスト対象物であるソフトウェアの品質を評価して改善する方法です。
ソフトウェアの品質は、利用者や顧客の要求や要件を満たすことを指します。
テストは、品質コントロール(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、トレーサビリティなどがあります。
また、テストケースやリスク分析などの成果物は、テスト設計のレビュー対象です。
そのため、テスト分析およびテスト設計は、静的テストとみなされることがあります。

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

テスト実装

テストアナリストはテスト分析とテスト設計に基づいて、テスト実行を行うために必要なものを全て準備します。

テスト実装のタスク

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

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

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

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

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

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

テスト実行

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

テスト実行のタスク

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

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

ソフトウェア開発ライフサイクルにおけるテスト

ソフトウェア開発ライフサイクル（以下、SDLCと省略）は、ソフトウェアを開発するプロセス（設計、開発、テストなど）を効率的かつ高品質なソフトウェアを作成するために定められた一連のプロセスや手順です。
このライフサイクルは、ソフトウェアの構想からリリース後の運用・保守に至るまでの各フェーズで構成されていて、それぞれのフェーズに特有のタスクが含まれます。
JSTQBのシラバスでは、以下が紹介されています。

SDLCは、テスト活動の以下に対して影響を与えます。

テストアナリストの関与

テストアナリストが関わるタイミングや関わり方、必要な時間、利用可能な情報、期待される内容は、使用するSDLCによって異なります。
テストアナリストは、他の関連組織に提供する情報の種類を理解しておくことが重要です。
JSTQBのシラバスには、以下のように提供先と提供する情報が記載されています

前述している通り、テストアナリストが関与するタイミングや内容はSDLC事で異なります。
テストアナリストが各SDLCで関与するタイミングや内容を各SDLC毎に記載します。

シーケンシャル開発モデル

シーケンシャル開発モデルとは、ソフトウェア開発プロセスを一連の順序にして工程で分けて進行する方法です。
各工程は明確に定義されていて、前の工程が完了するまでは次の工程に移行しません。

次の工程に移行することをステップ移行といい、一般的にはドキュメントやソースコードなどのチェックを行う審査があります。 V字モデルは以下の図のように、オレンジ色の工程が上流工程で、青色の工程が下流工程を示しています。

V字モデル

シーケンシャル開発モデルでは、要求分析が完了したら次の工程である要件定義を実施します。
要求分析には受け入れテスト、基本設計には結合テストと設計に応じてテストレベルが異なります。

ソフトウェア開発ライフサイクルの早い段階（要件定義や設計段階など）でテスト活動を行うことをシフトレフトテストといいます。
このアプローチを行うことで、バグやインシデントを早期に発見・修正して、後ろの工程で発生する修正コストやリスク軽減できます。

シーケンシャル開発にはWモデルがあり、それは従来のV字モデルで課題となっていた「手戻りが困難」「テスト活動が後ろの工程に集中」などの問題を改善するためのモデルです。
このモデルでは、シフトレフトテストなどのアプローチを活用し、開発工程とテスト工程を密接に連携させます。
各開発段階に対応するテスト活動を並行して進めることで、バグや問題を早期に発見し、品質を保証しながら効率的に開発を進めることが可能となります。

シーケンシャル開発モデルでのテストアナリストの役割

シーケンシャル開発モデルでは、テストアナリストがシステムテストを担当することが多くなります。
システムテストでは、プロジェクト計画と同時にシステムテストの計画をはじめ、システムテストが完了するまでテストマネージャーがモニタリングとコントールします。

テストアナリストは、以下のように対応します。

1

テスト分析・設計

要件定義に基づいて実施すべきテストを分析し、具体的なテストケースやテストシナリオを設計します。
テスト計画書に基づき、テストに必要な工数を見積もることで、テストスケジュールの詳細な調整や実行計画の策定を支援します。
このプロセスで作成されたスケジュールは、プロジェクト全体の進行スケジュールに影響を与える可能性があるため、テストアナリストには正確な分析力と協調性が求められます。

3

テスト実装

システムテストを実行するためには、テストを行う環境が必要です。
この環境構築はシステム設計時から開始する場合もありますが、コーディングやコンポーネントテストと同時に開始することも多いです。
そのため、システムテスト環境の準備がシステムテスト実行の開始数日前まで続くこともあり、スケジュールが不十分になるリスクもテストアナリストは考慮して進めます。

4

テスト実行

テスト実行するには、テストの開始基準と終了基準の事前条件を定義して、その条件を満たす必要があります。
条件を満たした場合にテストを開始することができますが、必要に応じて事前条件を免除する場合もあります。
テストの開始基準の事前条件は、リソースの可用性、テストウェアの可用性、テスト対象の初期品質レベルなどです。
テスト実行の事前条件にコンポーネントテストや統合テストの終了基準が満たされている必要があります。

5

テスト完了

テストの終了基準の事前条件には、テストケースの結果（達成されたカバレッジレベル、未解決の欠陥数、欠陥密度、テスト結果など）や、テスト計画で計画されたテストが計画通りに完了したことなどがあります。
システムテストの終了基準を満たした後に、システムテストの完了活動が実施されます。

システムテスト以外のテストレベルにもテストアナリストが関与することはあります。
テストレベルごとに目的や対象は異なり、開始基準と終了基準も定義されますので注意が必要です。

イテレーティブ・インクリメンタル開発モデル

イテレーティブ・インクリメンタル開発モデルとは、システムを小さな部分に分割し、その分割した部分ごとにソフトウェア開発プロセスを繰り返す方法です。
各イテレーションでは、静的テストと動的テストの両方が実行されます。 段階的な開発、繰り返しのプロセス、早期のフィードバック、リスク軽減などの特徴があります。

要件の変更が発生しやすいプロジェクトに向いていますのでユーザストーリなどテストが重要になります。
繰り返す作業が多いため、修正した機能と影響する機能にはリグレッションテスト（回帰テスト）が必要不可欠で、リグレッションテストを自動化することで効率よくテストを実施することができます。

イテレーティブ・インクリメンタルでは、以下のように小さな部分に分割したのを1つのイテレーションとして分割した分繰り返して実施します。
要件定義、設計、開発、テストの各活動をアクティビティといいます。

V字モデル

図のテストには、テスト分析、設計、実装、実行が含まれています。
そのため、イテレーションごとにテスト分析、設計、実装、実行を行います。

イテレーティブ開発モデルとインクリメンタル開発モデルでは、アクティビティの順序は変更可能でアクティビティを省略することもできます。
アクティビティはイテレーションごとに行い、プロジェクトの開始時に計画を立てて、終了時にタスクを完了させます。

テストアナリストは、イテレーションやインクリメンタルな活動中に、よりインタラクティブな役割を担います。

ハイブリッドモデル

ハイブリッドモデルとは、シーケンシャル開発モデル、イテレーティブ開発モデル、インクリメンタル開発モデルなどのSDLCを組み合わせて使用します。
それにより、シーケンシャル開発モデルのステップ移行を取り入れつつ、イテレーティブ開発モデルの繰り返しのサイクルを合わせます。
繰り返しのサイクルを取り入れつつ、各サイクルの中でV字モデルのように計画、設計、実装、テストを行います。
顧客の要件が変化することを前提として、柔軟に対応することができます。

アジャイルソフトウェア開発

アジャイルソフトウェア開発は、ソフトウェア開発の手法で世の中の変化に柔軟に対応します。
そのため、ステークホルダーと密な関係を気づいていくことが大切です。
前述したイテレーティブ・インクリメンタル開発モデルでスクラム・カンバン・エクストリームプログラミングなどがあります。

テストアナリストの役割が定義されていないことが多く、ドキュメントの作成も最低限になっています。
開始時点で、テスト活動を実施して定期的にコミュニケーションを実施することが大切です。

テストアナリストの役割

使用するSDLCに関わらず、テストアナリストは期待される関与の度合いとタイミングを理解する必要があります。
特定のSDLCに応じて、事前に定義されたロールモデルに固執しない活動と関与のタイミングを調整してソフトウェア品質に貢献します。

リスクベースドテストの問題→