【無料】JSTQB AL シラバス解説【第1、2章】 

【この記事を書いた人】


アオパパ

私はテストエンジニアとしての経験が豊富で、以下の実績があります。
・テストエンジニア歴15年以上
・現役のテストリーダーとしての経験
・テストエンジニアの採用担当経験
・ソフトウェアテストの資格「JSTQB Foundation Level」保持
・テスターから派遣社員としてのキャリアチェンジ経験
これらの経験をもとに、信憑性の高い情報提供を心掛けております。

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

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

TA-1.2.1 （K2）対応するソフトウェア開発ライフサイクルモデルに応じて、テストアナリストが関与するタイミングとその関わり方がどのように異なるのか、またその理由を説明する。

テストアナリストの役割とSDLC（ソフトウェア開発ライフサイクル）

テストアナリストは、ソフトウェア開発プロジェクトにおいて重要な役割を果たします。
テストアナリストの関与するタイミングと方法は、選択されたSDLCモデルによって異なります。
SDLCモデルには、シーケンシャル（逐次的）、イテレーティブ（反復的）、インクリメンタル（段階的）、またはこれらのハイブリッドなどがあります。

• シーケンシャルモデル（例：V字モデル）:
  このモデルでは、テストプロセスは段階的に進行します。
  プロジェクト計画と同時にシステムテスト計画を開始し、テスト完了までモニタリングとコントロールを継続します。
  テストアナリストは、システム要件仕様や設計仕様に基づいてテスト分析と設計を行います。
• イテレーティブおよびインクリメンタルモデル:
  これらのモデルでは、テスト活動はより柔軟に行われます。
  イテレーティブモデルでは、各イテレーションごとにテスト活動のセットを使用し、計画作業はプロジェクトの開始時に、完了タスクは終了時に行います。
• アジャイルソフトウェア開発:
  アジャイルでは、形式ばらないプロセスが使用され、テストアナリストの役割は明確に定義されません。
  テストは開発の初期段階から行われ、プロジェクト全体を通じて継続します。

TA-1.2.1 （K2）対応するソフトウェア開発ライフサイクルモデルに応じて、テストアナリストが関与するタイミングとその関わり方がどのように異なるのか、またその理由を説明する。

テストアナリストは、選択されたSDLCモデルに基づいて、テスト活動のタイミングと関与の方法を調整する必要があります。
シーケンシャルモデルでは、テストはより段階的に進行し、イテレーティブやインクリメンタルモデルでは、テスト活動はより柔軟に、アジャイルモデルでは、開発の初期段階から継続的に行われます。
これらの違いは、プロジェクトの要件や目標に応じてテストアナリストがどのように関与するかを決定します。

＜SDLCモデルの特徴を簡単に解説＞

シーケンシャル（逐次的）モデル

• 例：ウォーターフォールモデル
• 特徴：各段階（要件定義、設計、実装、テスト、デプロイ）が順序立てて進行。
• 利点：シンプルで理解しやすい。
• 欠点：柔軟性が低く、後戻りが難しい。

イテレーティブモデル

• 特徴：開発を小さなサイクル（イテレーション）で繰り返し、各サイクルで製品を改善。
• 利点：フィードバックを早期に取り入れ、途中で要件の変更が可能。
• 欠点：計画と管理が複雑になることがある。

インクリメンタルモデル

• 特徴：製品を部分的に開発し、各部分（インクリメント）を段階的に組み合わせていく。
• 利点：初期の段階で部分的な製品をリリースできる。
• 欠点：全体の設計を初期に固める必要がある。

アジャイルモデル

• 特徴：小規模なチームが短いサイクルで開発を進め、頻繁に製品をリリース。
• 利点：変更に対して非常に柔軟で、顧客のフィードバックを迅速に反映。
• 欠点：文書化が少なく、プロジェクトの進行が不透明になることがある。

ハイブリッドモデル

• 特徴：上記のモデルを組み合わせたもの。例えば、ウォーターフォールとアジャイルの要素を併用する。
• 利点：異なるモデルの利点を活用。
• 欠点：複数のアプローチを管理する必要があり、複雑になることがある。

各モデルは、プロジェクトの要件やチームの動作スタイルに応じて選択されます。モデルによって、テストのアプローチやタイミングも変わってきます。

練習問題

1.3 テスト分析

TA-1.3.1 （K2）分析の活動を行う際に、テストアナリストにとって適切なタスクをまとめる。

テストアナリストは、テスト計画の範囲内で以下の分析の活動を行います：

1. テストベースの分析:
   • テストベース（要件、ユーザーストーリーなど）を分析し、欠陥を識別します。
2. テスト条件とフィーチャーの識別:
   • テスト対象の条件や特徴を特定し、優先度を割り当てます。
3. トレーサビリティの確立:
   • テストベースの各要素と関連するテスト条件間の双方向トレーサビリティを確立します。
4. リスクベースドテストの実行:
   • リスクに基づいたテスト活動を行います。

<開始基準の確認>

テストアナリストは、以下の開始基準が満たされていることを確認する必要があります：

• テストベースが存在し、適切にレビューされていること。
• テスト対象に対して、必要な予算とスケジュールが確保されていること。

＜テスト条件の識別＞

• テストベースとテスト目的を分析してテスト条件を識別します。
• ドキュメントが古い、または存在しない場合は、ステークホルダーとの協議を通じて条件を特定します。
• アジャイル開発では、ユーザーストーリーの受け入れ基準がテスト設計の基盤となります。

<テスト条件の定義>

• テスト条件は、異なる詳細度で定義されます。例えば、大まかな対象から具体的なテストケースまで。
• プロダクトリスクが定義されている場合、それに対処するためのテスト条件を特定します。

<テスト技法の適用>

• テスト戦略やテスト計画で識別されたテスト技法を適用することで、テスト分析活動が促進されます。

TA-1.3.1 （K2）分析の活動を行う際に、テストアナリストにとって適切なタスクをまとめる。

テストアナリストがテスト計画の範囲内で行うべき主なタスクは上記した内容です。
これには、テストベースの分析、テスト条件の識別と定義、リスクベースドテストの実行、トレーサビリティの確立などが含まれます。
また、テストアナリストは、テストベースの存在と適切なレビュー、必要な予算とスケジュールの確保など、テスト分析を開始する前にいくつかの基準が満たされていることを確認する必要があります。

1.4 テスト設計

TA-1.4.1 （K2）ステークホルダーがテスト条件を理解する必要がある理由を説明する。

シラバスでは上記タイトルの通り「TA-1.4.1」と記載されているが、「ステークホルダーがテスト条件を理解する必要がある理由」が記載されているのは「TA-1.4」である。
よってこの項目では「TA-1.4」の解説を行います。

<テストプロセスの概要>

テストプロセスは、テスト計画に基づいて進行し、テストアナリストがテストケースを設計、実装、そして実行する一連の活動を含みます。このプロセスは以下のような重要なステップで構成されています：

1. テストケースの適切性の判断:
   • ローレベルテストケースとハイレベルテストケースのどちらが特定のテスト領域に最適かを判断します。
2. テスト技法の選択:
   • 必要なカバレッジを確保するためのテスト技法を選定します。
3. テストケースの設計:
   • 識別されたテスト条件をカバーするためのテストケースやセットを設計します。
4. テストデータの識別:
   • テスト条件とテストケースに適合するテストデータを識別します。
5. テスト環境の設計:
   • テスト環境を設計し、必要なインフラストラクチャーやツールを特定します。
6. トレーサビリティの確立:
   • テストベース、テスト条件、テストケース間の双方向トレーサビリティを確立します。
7. リスク分析と優先度基準の適用:
   • リスク分析とテスト計画で識別された優先度基準をプロセス全体に適用します。

<テストケース設計の留意点>

テストアナリストは、テストケースを設計する際に以下の点に注意を払う必要があります：

• テスト条件のみの定義:
  • 実行手順を指定するテストスクリプトよりも、テスト条件のみを定義して対処する場合があります。この場合、テスト条件はテストスクリプトなしでテストを行う際のガイドとして使用できるように定義する必要があります。
• 合格／不合格基準の明確化:
  • 合格または不合格の基準を明確に識別する必要があります。
• テストケースの理解可能性:
  • テストケースは、作成者だけでなく他のテスト担当者やステークホルダー（開発者、監査担当者など）にも理解できるように定義する必要があります。(レビューや承認を行う必要がある為)
• テスト対象の全相互作用のカバレッジ:
  • テストケースは、ユーザーインターフェースを通じてのみならず、テスト対象とのすべての種類の相互作用をカバーすべきです。
• テスト設計の労力とリスクレベルのバランス:
  • テスト設計の労力は、リスクレベルとビジネス価値に合致するように優先度を割り当て、バランスを取る必要があります。

TA-1.4.1 （K2）ステークホルダーがテスト条件を理解する必要がある理由を説明する。

ステークホルダーがテスト条件を理解する必要がある理由は、テストケースがレビューや承認のプロセスにおいて、開発者や監査担当者などの他のステークホルダーにも理解しやすい形であるべきだからです。
テストケースの明確な定義と理解は、テストプロセスの透明性を高め、品質保証の観点から重要な役割を果たします。ステークホルダーがテスト条件を適切に理解することで、テストの効果を最大化し、プロジェクトの成功に貢献することができます。

TA-1.4.2 （K4）特定のプロジェクトシナリオに対して、テストケースの適切な設計レベル（ハ
イレベルまたはローレベル）を選択する 。

シラバスでは上記タイトルの通り「TA-1.4.2」と記載されているが、「ハイレベルまたはローレベル」が記載されているのは「TA-1.4.1」である。
よってこの項目では「TA-1.4.1」の解説を行います。

<テストケースの設計レベル>

テストアナリストは、テストケースを設計する際に、ローレベルテストケースとハイレベルテストケースのどちらを使用するかを決定します。これらの設計レベルは、それぞれ異なる特徴を持ち、プロジェクトの要件や目的に応じて選択されます。

<ローレベルテストケース：具体的>

• 長所:
  • 詳細な情報と手順を提供し、経験の少ないテスト担当者でも実行可能。
  • 異なる担当者が実行しても同じ結果を得やすい。
  • 自明ではない欠陥の検出に有効。
  • 監査のような独立した検証が可能。
  • テストケースの自動化において、実装時間の削減が期待できる。
• 短所:
  • 作成とメンテナンスに多大な労力が必要。
  • テスト担当者の創造力を制限する可能性がある。
  • テストベースの明確な定義が必要。
  • テスト条件のトレーサビリティ確保に労力が必要。

<ハイレベルテストケース：抽象的>

• 長所:
  • テストすべきものに関するガイドラインを提供し、テスト実行時の柔軟性を持つ。
  • ローレベルテストケースよりも優れたリスクカバレッジを提供する可能性がある。
  • 要件プロセスの初期に定義可能。
  • テストアナリストの経験を活用できる。
  • 形式的なドキュメントが不要な場合に定義可能。
  • 再利用性が高い。
• 短所:
  • 再現能力が低く、検証が困難。
  • 経験豊富なテスト担当者が必要になることがある。
  • 自動化時に詳細情報の不足により、誤った結果の検証や重要なアイテムの見逃しが発生する可能性がある。

TA-1.4.2 （K4）特定のプロジェクトシナリオに対して、テストケースの適切な設計レベル（ハイレベルまたはローレベル）を選択する。

プロジェクトの特定の状況や要件に応じて、ローレベルテストケースとハイレベルテストケースのそれぞれの長所と短所を理解し、適切な設計レベルを選択することの重要性を示しています。
例えば、詳細な情報が必要で再現性が求められる場合はローレベルテストケースが適しているが、テスト実行の柔軟性やリスクカバレッジを重視する場合はハイレベルテストケースが適しています。
また、要件が明確になり安定した場合、ハイレベルテストケースからローレベルテストケースへと進むことがあり、実行にはローレベルテストケースのみを使用することが一般的です。

TA-1.4.3 （K2）テストケース設計で考慮すべき問題を説明する。

シラバスでは上記タイトルの通り「TA-1.4.3」と記載されているが、「テストケースの設計」が記載されているのは「TA-1.4.2」である。そもそも「TA-1.4.3」の項目はないです。。
よってこの項目では「TA-1.4.2」の解説を行います。

テストケースの設計は、テスト条件を特定し、それに基づいてテストケースを作成するプロセスです。
以下は、テストケース設計に関する主要なポイントとその詳細な説明です。

1. テストケースの特性:
   • テストケースは、再利用可能、検証可能であるべきです。
   • テストベース（例: 要件）との間にトレーサビリティが確保されている必要があります。
2. テスト設計で識別すべきアイテム:
   • テスト実行の目的
   • プロジェクトの要件やテスト環境の事前条件
   • テストデータ要件
   • 期待結果の明確な合格/不合格基準
   • テスト実行後の事後条件
3. 期待結果の課題:
   • 期待結果を手動で計算するのは時間がかかり、エラーが発生しやすいため、自動化されたテストオラクルの使用が推奨されます。
   • テストベースが不明確、曖昧、または存在しない場合、テストアナリストは専門知識を持つか、情報にアクセスできる必要があります。
4. テストレベルとテスト目的:
   • テスト分析および設計時には、テストレベルとテスト目的を考慮する必要があります。
5. テスト作業成果物の文書化:
   • テスト作業成果物の文書化の範囲はプロジェクトによって異なりますが、リスク、付加価値、準拠する標準や規制、トレーサビリティの要件などが影響を与えます。
6. テストインフラストラクチャー:
   • テスト設計時にテストインフラストラクチャーの要件を定義することがあります。これには、場所、機器、ソフトウェア、ツールなどが含まれます。
7. テスト分析および設計の終了基準:
   • 終了基準はプロジェクトにより異なるが、測定可能であり、以降の手順に必要なすべての情報が提供されていることが重要です。

TA-1.4.3 （K2）テストケース設計で考慮すべき問題

テストケースの品質:
・テストケースは再利用可能、検証可能であるべき。
・テストベース（要件など）までのトレーサビリティが確保されていること。
テスト設計の詳細:
・テストの目的、事前条件、テストデータ要件、期待結果、事後条件を明確に識別する必要がある。
期待結果の課題:
・期待結果を手動で計算するのは時間がかかり、エラーが発生しやすい。
・テストベースが不足しているか、曖昧である場合、期待結果の識別が困難になる。
テストオラクルの重要性:
・期待結果の定義が困難な場合、テストオラクルが必要。
・アジャイルソフトウェア開発では、テストオラクルはプロダクトオーナーである可能性がある。
テストベースの問題:
・テストベースのドキュメントが曖昧であるか、矛盾を含んでいるか、存在しない場合がある。
テストインフラストラクチャーの要件:
・テスト対象およびテストウェア以外のものも含め、テストインフラストラクチャーの要件を定義することがある。
終了基準の確立:
・テスト分析および設計の終了基準を明確にし、それが測定可能であることを確認する。

1.5 テスト実装

TA-1.5.1 （K2）テスト実装の活動を行う際に、テストアナリストにとって適切なタスクをまとめる。

テスト実装は、テスト分析と設計の成果を基に、テスト実行に必要な準備を行う段階です。
この段階での主な活動は以下の通りです。

1. テスト手順と自動テストスクリプトの作成:
   • テスト実行に必要な手順や、自動化が可能な場合はテストスクリプトを作成します。
2. テストスイートの整理:
   • テスト手順と自動テストスクリプトを特定のテストランで実行するテストスイートとして整理します。
3. テストケースとテストスイートの優先度付け:
   • テストマネージャーと相談し、実行するテストケースとテストスイートの優先度を決定します。
4. テスト実行スケジュールの作成:
   • テストケースの実行を開始するためのスケジュール（リソース割り当て含む）を作成します。
5. テストデータとテスト環境の準備:
   • テストデータの準備とテスト環境の設定を完了します。
6. トレーサビリティの更新:
   • テストベース、テスト条件、テストケース、テスト手順、テストスクリプト、テストスイートなどの間のトレーサビリティを更新します。

<テストアナリストの役割>

テストアナリストは、以下のような重要な役割を担います。

• テスト手順の作成と定義:
  • 効率的な実行順序を特定し、テスト手順を作成します。
    制約や依存関係を考慮し、初期条件や実行後の活動を明確に記述します。
• テストスイートの整理:
  • グループ化可能なテスト手順と自動テストスクリプトを特定し、テストスイートに整理します。
• テスト実行スケジュールの配置:
  • 効率的なテスト実行を実現するために、テストスイートをテスト実行スケジュールに配置します。リスクレベルや他の要因を考慮してテストケースの実行順序を決定します。
• テスト環境の設定とメンテナンス:
  • テスト環境の作成およびメンテナンスを担当し、テストウェアやテストサポートツールが使用可能であることを確認します。

TA-1.5.1 （K2）テスト実装の活動を行う際に、テストアナリストにとって適切なタスクをまとめる。

テストアナリストにとって適切なタスクは、テスト手順の作成、テストスイートの整理、テスト実行スケジュールの配置、テストデータと環境の準備、トレーサビリティの更新、テスト環境の設定とメンテナンスなど、テスト実行に必要なすべての準備と計画を含みます。

これらのタスクは、テストプロセスの効率と効果を最大化するために重要です。

また、テストアナリストは、テストの実行順序を決定する際にリスクレベルや他の要因を考慮し、テスト環境の変更が実行済みのテストケースに与える影響を評価する必要があります。

1.6 テスト実行

TA-1.6.1 （K2）テスト実行の活動を行う際に、テストアナリストにとって適切なタスクをまとめる。

テスト実行の活動は、テストアナリストにとって重要な役割を担います。これらの活動は、テスト実行スケジュールに従って行われ、以下のようなタスクを含みます：

1. 手動テストの実行:
   • 探索的テストを含む手動でのテスト実行。
2. 自動テストの実行:
   • 自動化されたテストスクリプトの実行。
3. 実行結果と期待結果の比較:
   • テストの実際の結果を期待される結果と比較する。
4. 不正の分析と原因特定:
   • テスト中に発見された不正（エラー）を分析し、その可能性のある原因を特定する。
5. 故障の観察と欠陥報告:
   • 故障を観察し、それに基づいて欠陥を報告する。
6. テスト実行結果の記録:
   • テストの実際の結果を記録する。
7. テスト結果の検討とトレーサビリティの更新:
   • テスト結果を検討し、テストベースとテストウェア間のトレーサビリティを更新する。
8. リグレッションテストの実行:
   • 以前に修正されたバグが再発しないことを確認するためのテスト実行。

これらのタスクは、テスト担当者またはテストアナリストによって行われます。さらに、テストアナリストは以下の追加タスクを行う可能性があります：

1. テスト対象の特定部分の特定:
   • 欠陥が集中している可能性のあるテスト対象の特定部分を特定し、さらなるテストが必要か判断する。
2. 探索的テストからの提案作成:
   • 探索的テストからの発見事項に基づいて、将来の探索的テストに対する提案を作成する。
3. 新しいリスクの識別:
   • テスト実行タスクを行う際に得られた情報から新しいリスクを識別する。
4. テスト手順の改善提案:
   • テスト実装活動からの成果物を改善するための提案を作成する（例：テスト手順の改善）。

TA-1.6.1 （K2）テスト実行の活動を行う際に、テストアナリストにとって適切なタスクをまとめる。

テストアナリストが行うべき主要なタスクとして、手動テストの実行、自動テストの実行、実行結果の比較、不正の分析、故障の観察と報告、テスト結果の記録、テスト結果の検討とトレーサビリティの更新、リグレッションテストの実行が挙げられます。

さらに、テスト対象の特定部分の特定、探索的テストからの提案作成、新しいリスクの識別、テスト手順の改善提案などの追加タスクも重要です。

第 2 章：リスクベースドテストにおけるテストアナリストのタスク

2.2 リスク識別　2.3 リスクアセスメント　2.4 リスク軽減

TA-2.1.1 （K3）特定の状況で、リスク識別に参加し、リスクアセスメントを実行し、適切なリスク軽減策を提案する 。