JSTQB FL シラバス2023解説【第 1 章:テストの基礎】

【この記事を書いた人】


アオパパ

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

この記事の対象読者
・最新のシラバス「2023V4.0.J01」に対応した解説を探している
・JSTQB FL(FoundationLevel)のシラバスを勉強しようと思っている
・JSTQB FL(FoundationLevel)のシラバスの勉強方法が知りたい
・JSTQB FL(FoundationLevel)のシラバスを勉強しているけど意味がわからない
・JSTQB FL(FoundationLevel)のシラバスの問題集を探している

JSTQB FL シラバスの解説の前に・・・

JSTQB FL シラバスの解説の前にシラバスの勉強方法をレクチャーしますね。

ほとんどの人が読み飛ばしてしまう箇所に大事な大切なことが書かれています。

0.5 試験対象の学習の目的と知識レベル

学習の目的はビジネス成果を支援し、テスト技術者資格制度 Foundation Level の試験問題作成を行うた
めに使用する。
全体を通して、本シラバスの 1 章から 6 章のすべての内容は、K1 レベルで試験対象である。つまり、受
験志願者は本シラバスの 6 つの章で説明されているキーワードと概念について認識し、記憶し、想起す
ることになる。本シラバスでは各章の先頭で以下の分類にて「学習の目的」を示している。
⚫ K1：記憶
⚫ K2：理解
⚫ K3：適用
学習の目的の詳細と例は付録Aに添付する。各章の章見出しの下にキーワードとしてリストアップされて
いるすべての用語の定義は、「学習の目的」には明示的に述べられていないとしても「記憶」しておく
べき（K1）レベルとなる。

出典: ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J01

上記の文章より、JSTQB Foundation Level の試験問題は学習の目的に沿って作成されることがわかりますね。
なので学習の目的をしっかりと確認・把握した上でシラバスを読み込み理解していく必要があります。

こちらの記事内のシラバス解説では学習の目的に沿って作成しています。
以下の3STEPを各章ごとに実施していくとスムーズに勉強できます。

JSTQB Foundation Levelの詳細は以下の記事で解説しています。

第 1 章:テストの基礎の学習テーマ

第1章のテーマは以下になっています。
●テストに関わる基本的な原理、テストが必要となる理由、テスト目的について学ぶ。
●テストプロセス、主なテスト活動、テストウェアを理解する。
●テストに必要不可欠なスキルを理解する。

第 1 章:テストの基礎の学習の目的

第 1 章の学習の目的は以下になっています。
1.1 テストとは何か？
FL-1.1.1 （K1）典型的なテスト目的を識別する。
FL-1.1.2 （K2）デバッグとテストを区別する。
1.2 なぜテストが必要か？
FL-1.2.1 （K2）テストが必要な理由を例示する。
FL-1.2.2 （K1）テストと品質保証の関係を想起する。
FL-1.2.3 （K2）根本原因、エラー、欠陥、故障を区別する。
1.3 テストの原則
FL-1.3.1 （K2）テストにおける 7 原則を説明する。
1.4 テスト活動、テストウェア、そして役割
FL-1.4.1 （K2）さまざまなテスト活動とタスクを要約する。
FL-1.4.2 （K2）テストを取り巻くコンテキストがテストプロセスに与える影響を説明する。
FL-1.4.3 （K2）テスト活動を支援する多くのテストウェアを区別する。
FL-1.4.4 （K2）トレーサビリティを維持することの価値を説明する。
FL-1.4.5 （K2）テストにおけるさまざまな役割を比較する。
1.5 テストに必要不可欠なスキルとよい実践例
FL-1.5.1 （K2）テストを行うために求められる一般的なスキルについて例を挙げる。
FL-1.5.2 （K1）チーム全体アプローチの利点を想起する。
FL-1.5.3 （K2）テストの独立性の長所と短所を区別する。

1.1 テストとは何か？

FL-1.1.1 （K1）典型的なテスト目的を識別する。

テストを行う主な理由や目的は、以下のようなものがあります：

1. 作業成果物の評価：テストは、要件やユーザーストーリー、設計、コードなど、ソフトウェア開発の過程で作成されるさまざまな成果物を評価するために行われます。
2. 欠陥の発見：テストの一つの大きな目的は、ソフトウェアに存在する欠陥やバグを見つけることです。
3. カバレッジの確保：テストを通じて、ソフトウェアのすべての部分が適切にテストされていることを確認します。
4. リスクの低減：ソフトウェアの品質が不十分な場合のリスクを下げるためにテストが行われます。
5. 要件の検証：テストは、ソフトウェアが仕様や要件に従って正しく動作しているかを確認するために行われます。
6. 法律や規制の遵守：ソフトウェアが契約や法律、規制などの要件を満たしているかを確認するためのテストもあります。
7. 情報提供：テストは、ステークホルダーにソフトウェアの品質や状態に関する情報を提供するために行われます。
8. 信頼の構築：テストを通じて、ソフトウェアの品質に対する信頼を積み上げることができます。
9. 妥当性の確認：テストは、ソフトウェアが期待通りに動作するかどうかを確認するために行われます。

ただし、テストの目的は、テスト対象やテストのレベル、リスク、ソフトウェア開発の方法、ビジネスの背景など、さまざまな要因によって異なることがあります。

FL-1.1.2 （K2）デバッグとテストを区別する。

テストとデバッグは、ソフトウェア開発の中で行われる異なる活動です。

1. テスト:
   • 目的: ソフトウェアの欠陥を発見すること。
   • 動的テスト: ソフトウェアを実行して、欠陥による故障を発生させるテスト方法。
   • 静的テスト: ソフトウェアを実行せずに、コードやドキュメントを直接調査して欠陥を発見する方法。
2. デバッグ:
   • 目的: 故障の原因（欠陥）を特定し、それを修正すること。
   • 手順:
     1. 故障の再現: 故障を確認する。
     2. 診断: 故障の根本原因を特定する。
     3. 修正: 原因となる欠陥を修正する。

デバッグの後、確認テストを行い、修正が正しく行われたかを確認します。
さらに、修正が他の部分に問題を引き起こしていないかを確認するためのリグレッションテストも実施されることがあります。

1.2 なぜテストが必要か？

FL-1.2.1 （K2）テストが必要な理由を例示する。

テストが必要な理由：

1. 欠陥の検出と品質向上
   テストは、ソフトウェアや製品に存在する欠陥を見つけるための効果的な方法です。これらの欠陥を検出し、デバッグ（テストとは異なる活動）を通じて修正することで、製品の品質が向上します。
2. 品質の評価
   ソフトウェア開発ライフサイクル（SDLC）の様々な段階で、テストは品質を直接評価する手段として機能します。この評価結果は、プロジェクト全体の管理や、次の開発段階への移行の判断などに役立ちます。
3. ユーザーの視点の提供
   テストは、製品が実際にユーザーに使用される状況を模倣することができます。テスト担当者は、開発の過程でユーザーのニーズが適切に考慮されているかを確認します。理想的には、実際のユーザーを開発プロジェクトに関与させるのが最良ですが、これはコストがかかるため、また適切なユーザーを見つけるのが難しいため、通常は実現しづらいです。
4. 契約や法律の要件の満足
   いくつかのケースでは、テストは契約や法律の要件を満たすため、または特定の規制基準に準拠するために行われます。

FL-1.2.2 （K1）テストと品質保証の関係を想起する。

「テスト」と「品質保証」（QA）は、しばしば同じ意味で使われることがありますが、実際には異なる概念です。

1. テスト:
   • テストは、品質コントロール（QC）の一部として行われる活動です。
   • QCは、製品の品質を確保するための活動に焦点を当てています。これは、製品が期待通りの品質を持っているかを確認するためのアプローチです。
   • テストはQCの主要な方法の一つで、他にも形式的手法やシミュレーション、プロトタイピングなどの方法があります。
2. 品質保証（QA）:
   • QAは、プロセスの品質を確保するための活動に焦点を当てています。
   • これは、良いプロセスが正しく実施されれば、良い製品が生まれるという考え方に基づいています。
   • QAは、開発プロセスとテストプロセスの両方に適用され、プロジェクトに関与するすべての人がその責任を持っています。

テストの結果は、品質の確保（QC）と品質保証（QA）の両方で使用されます。QCでは、欠陥を修正するために使用され、QAでは、開発とテストのプロセスがどれだけうまく機能しているかのフィードバックとして使用されます。

FL-1.2.3 （K2）根本原因、エラー、欠陥、故障を区別する。

1. エラー（誤り）：人間が行う作業中に起こるミスや誤りのこと。例えば、プログラムを書いているときに、間違ったコードを書いてしまうこと。人はさまざまな理由（疲れ、トレーニング不足、時間的なプレッシャーなど）でエラーを起こすことがあります。
2. 欠陥（フォールト、バグ）：エラーが原因で生じるソフトウェアやドキュメントの問題点。例えば、要件仕様書やソースコードに間違いがある場合。欠陥は、特定の状況下でしか故障にならないものや、絶対に故障にならないものも含まれます。
3. 故障：システムが正しく動作しない状態。欠陥が原因で起こることが多いが、環境条件（例：放射線や電磁波）によっても発生することがある。
4. 根本原因：問題が発生する最も深い理由。例えば、なぜエラーが起こったのか、なぜ欠陥が生じたのかを探るときに、その背後にある主要な要因を指します。根本原因分析を行うことで、同様の問題を未来に防ぐための対策を考えることができます。

練習問題

1.3 テストの原則

FL-1.3.1 （K2）テストにおける 7 原則を説明する。

テストにおける7つの原則の説明：

1. テストは欠陥があることは示せるが、欠陥がないことは示せない
   • テストはソフトウェアに問題があるかどうかを示すことができますが、完全に問題がないことを100%確認することはできません。
2. 全数テストは不可能
   • すべてのシナリオや条件をテストすることは現実的ではありません。そのため、重要な部分やリスクが高い部分に焦点を当ててテストする必要があります。
3. 早期テストで時間とコストを節約
   • プロジェクトの初期段階でのテストは、後の段階での問題やコストを削減するのに役立ちます。
4. 欠陥の偏在
   • 一部のシステムコンポーネントには多くの問題が集中していることが多いです。これを理解することで、テストの効率を向上させることができます。
5. テストの弱化
   • 同じテストを繰り返すと、新しい問題を見つける能力が低下します。そのため、テストの変更や新しいテストの追加が必要です。
6. テストはコンテキスト次第
   • テストの方法やアプローチは、プロジェクトや状況によって異なります。
7. 「欠陥ゼロ」の落とし穴
   • ソフトウェアが完全に問題がないと考えることは危険です。ユーザーのニーズやビジネスの目標を満たすためには、ただテストするだけでは不十分です。

練習問題

1.4 テスト活動、テストウェア、そして役割

FL-1.4.1 （K2）さまざまなテスト活動とタスクを要約する。

テストプロセスの要点説明：

1. テストプロセスの構成:
   • テストプロセスは、さまざまな主要な活動のグループで構成されます。これらの活動は、順番に行われるように見えますが、実際には繰り返しや同時に行われることが多いです。
2. テスト計画:
   • テストの目的を定義し、その目的を最も効果的に達成する方法を選択します。詳細は5.1節で説明されています。
3. テストのモニタリングとコントロール:
   • テスト活動を継続的にチェックし、進捗をテスト計画と比較します。目的を達成するための行動も取り入れます。詳細は5.3節で説明されています。
4. テスト分析:
   • テストの基盤を分析し、テスト可能な特徴やテスト条件を定義します。テスト技術を使用して「何をテストするか？」を決定します。
5. テスト設計:
   • テスト条件をテストケースやその他のテストウェアに変換します。「どのようにテストするか？」を決定します。
6. テスト実装:
   • テスト実行に必要なテストウェアを作成または取得します。テスト環境を構築し、正しく設定されていることを確認します。
7. テスト実行:
   • テスト実行スケジュールに従ってテストを行います。テスト結果は、期待される結果と比較されます。
8. テスト完了の活動:
   • プロジェクトの重要な段階で行われ、未解決の問題や変更要求に対応します。テスト活動を分析し、教訓や改善点を識別します。

練習問題

FL-1.4.2 （K2）テストを取り巻くコンテキストがテストプロセスに与える影響を説明する。

テストは、開発の一部として行われる活動です。つまり、ソフトウェアやアプリケーションを作成する過程の中で、その品質を確認するためのステップとしてテストが行われます。このテストの方法やアプローチは、さまざまな要因によって変わることがあります。

1. ステークホルダー: これはプロジェクトに関わる人々のことを指します。彼らのニーズや期待、要件などによって、テストの方法が変わることがあります。
2. チームメンバー: チームのスキルや経験、トレーニングの必要性などによって、テストのアプローチが変わることがあります。
3. ビジネスドメイン: これはテストする製品やサービスの業界や分野のことを指します。このドメインの重要性やリスク、市場のニーズなどによって、テストの方法が変わることがあります。
4. 技術的要因: 使用するソフトウェアの種類やアーキテクチャ、技術などによって、テストの方法が変わることがあります。
5. プロジェクトの制約: プロジェクトのスコープや時間、予算などの制約によって、テストのアプローチが変わることがあります。
6. 組織的要因: 組織の構造やポリシー、実践例などによって、テストの方法が変わることがあります。
7. ソフトウェア開発ライフサイクル: 開発の方法や実践例によって、テストのアプローチが変わることがあります。
8. ツール: 使用するツールの利用可能性や使用性、標準適合性などによって、テストの方法が変わることがあります。

これらの要因は、テストの戦略や技法、自動化の度合い、ドキュメントの詳細度、レポート作成など、テストに関する多くの点で影響を与えます。

練習問題

FL-1.4.3 （K2）テスト活動を支援する多くのテストウェアを区別する。

テストウェアの説明：

テストウェアは、テスト活動を行う際に作成されるさまざまな作業成果物を指します。これらの作業成果物は、テストの各段階で必要となるもので、組織やプロジェクトによってその内容や形式が異なることがあります。以下に、主なテストウェアの種類とその内容を示します：

• テスト計画の作業成果物：テストの全体的な計画やスケジュール、リスクの一覧や評価、テストを開始や終了するための基準などが含まれます。
• テストのモニタリングとコントロールの作業成果物：テストの進行状況やリスク情報、コントロールの指示などが文書化されています。
• テスト分析の作業成果物：テスト条件やテストベース内の欠陥に関する報告などが含まれます。
• テスト設計の作業成果物：具体的なテストケースやテストデータ、テスト環境の要件などがまとめられています。
• テスト実装の作業成果物：テストの手順や自動テストのスクリプト、テストデータ、テスト環境などが含まれます。
• テスト実行の作業成果物：テストの結果や発見された欠陥に関する報告などがまとめられています。
• テスト完了の作業成果物：テストの終了報告や得られた教訓、改善のための提案などが含まれます。

練習問題

FL-1.4.4 （K2）トレーサビリティを維持することの価値を説明する。

トレーサビリティの価値についての説明：

トレーサビリティとは、テストの各段階や要素がどのように関連しているかを明確にすることです。具体的には、テストの基盤となる要素（テストベース）と、それに関連するテストウェア（テスト条件、リスク、テストケースなど）、テストの結果、そして見つけた欠陥との関係をしっかりとつなげることを指します。

このトレーサビリティがあると、以下のような利点があります：

1. カバレッジの評価：トレーサビリティは、テストがどの程度の範囲をカバーしているか（カバレッジ）を評価するのに役立ちます。例えば、テストケースと要件の関連性を確認することで、特定の要件がテストケースできちんとテストされているかを確認できます。
2. リスクの評価：テスト結果とリスクの関連性を通じて、テスト対象の残存リスクのレベルを評価することができます。
3. 変更の影響の判断：トレーサビリティがあると、何か変更があったときにその影響を判断しやすくなります。
4. テストの監査の容易化：トレーサビリティは、テストの監査を行う際に、どの要素がどのように関連しているかを明確にするので、監査が容易になります。
5. 情報の提供：トレーサビリティは、プロダクトの品質やプロジェクトの進捗に関する情報を提供し、ステークホルダーにテストの技術的な側面をわかりやすく伝えるのに役立ちます。

練習問題

FL-1.4.5 （K2）テストにおけるさまざまな役割を比較する。

テストには主に2つの役割があります。一つは「テストをする役割」、もう一つは「テストマネジメントをする役割」です。

1. テストマネジメントをする役割:
   • この役割はテストの全体的な管理やリーダーシップを担当します。
   • 主な活動はテスト計画の作成、テストの進行状況のモニタリングとコントロール、そしてテストが完了したときの活動に焦点を当てています。
   • この役割の具体的なタスクは状況によって異なります。例として、アジャイルソフトウェア開発の環境では、テストマネジメントの一部のタスクはアジャイルチームが担当することがあります。しかし、複数のチームや組織をまたがる大きなタスクは、専門のテストマネージャーが担当することもあります。
2. テストをする役割:
   • この役割はテストの技術的な側面を担当します。
   • 主な活動はテストの分析、設計、実装、そして実行に重点を置いています。
   • さまざまな人がこの役割を担うことがあります。例えば、テストの管理タスクはチームリーダーやテストマネージャー、時には開発マネージャーが行うことがあります。また、一人の人がテストとテストマネジメントの両方の役割を同時に担うことも考えられます。

練習問題

1.5 テストに必要不可欠なスキルとよい実践例

FL-1.5.1 （K2）テストを行うために求められる一般的なスキルについて例を挙げる。

テストを行う際には、特定のスキルや知識が求められます。以下は、テスト担当者にとって特に重要なスキルや知識の一部です：

1. テスト知識：テスト技法を活用して、テストの有効性を高めることができます。
2. 徹底さ、慎重さ、好奇心、細部へのこだわり、理路整然さ：これらの特質は、特に発見しにくい欠陥を見つけるために役立ちます。
3. コミュニケーションスキル、積極的な傾聴、チームプレーヤー：すべての関係者と効果的にコミュニケーションをとることができ、欠陥を報告し議論するためには、これらのスキルが必要です。
4. 分析的思考、批判的思考、創造性：これらの思考方法を持つことで、テストの有効性をさらに高めることができます。
5. 技術的な知識：適切なテストツールを使用することで、テストの効率を向上させることができます。
6. ドメイン知識：エンドユーザーやビジネス側の代表者を理解し、彼らとコミュニケーションをとるためには、この知識が必要です。

テスト担当者は、しばしば「悪い知らせ」を伝える役割を持っています。
人は、悪い知らせを伝える人を非難することがあります。
そのため、テスト担当者としては、コミュニケーションスキルが非常に重要です。
テスト結果を伝える際には、それがプロダクトやその作成者への批判と受け取られないように注意が必要です。欠陥や故障に関する情報は、建設的な方法で伝えるべきです。

練習問題

FL-1.5.2 （K1）チーム全体アプローチの利点を想起する。

チーム全体アプローチとは？
チーム全体アプローチは、エクストリームプログラミングに由来する考え方で、チームの全員が品質に対して責任を持つというアプローチです。
この考え方では、チームメンバーは特定の役割に縛られず、必要な知識とスキルを持っていればどの仕事でも行うことができます。

その利点は？

1. 情報伝達とコラボレーションの強化：チームメンバーが同じワークスペースを共有することで、情報の伝達や相互作用が活性化されます。
2. チームダイナミクスの向上：チーム全体アプローチは、チームの協力と連携を強化し、さまざまなスキルセットをプロジェクトの利益のために活用することができます。
3. テスト担当者の役割の拡大：テスト担当者は、他のチームメンバーとの連携を深めることで、品質レベルの達成をサポートし、テストに関する知識を広めることができます。

ただし、すべてのコンテキストでチーム全体アプローチが適切であるわけではありません。例えば、セーフティクリティカルな状況では、高いレベルのテストの独立性が求められることがあります。

FL-1.5.3 （K2）テストの独立性の長所と短所を区別する。

テストの独立性とは、テストを行う人が開発を行った人とは異なる、つまりテスト担当者が開発者とは別の立場でテストを行うことを指します。この独立性には、以下のような長所と短所があります。

長所：

1. 異なる視点でのテスト: テスト担当者は開発者とは異なる経歴や技術的視点、バイアスを持っているため、開発者が見逃してしまうような異なる種類の故障や欠陥を見つけることができます。
2. 仮定の検証: テスト担当者は、システムの仕様策定や実装時に設定された仮定を検証し、異議を唱えることができます。

短所：

1. 協調性の欠如: テスト担当者が開発チームから孤立してしまうと、情報伝達の問題や開発チームとの関係が悪化する可能性があります。
2. 品質に対する責任感の喪失: 開発者がテストを他者に任せることで、自らの品質に対する責任感を失うことがあります。
3. ボトルネックの認識: 独立したテスト担当者がリリースの遅れの原因として見られることがあります。

練習問題

おわりに

JSTQB FL シラバスを解説してきましたが、いかがでしたでしょうか？
シラバスを読むだけでは、頭に入ってこなですし、眠くなりますよね。

そうならない為の工夫として今回は各項目に練習問題を追加しました。
では次の章のJSTQB FL シラバス解説でお会いしましょう！

最後までご覧頂き、ありがとうございました。
良いテストエンジニアライフを！