最終更新日: 2024年3月18日

JSTQB（ソフトウェアテスト技術者資格認定組織）は、Foundation LevelシラバスVersion 2023V4.0 日本語翻訳版（以下、2023年版）を2023年9月に公開いたしました。ISTQB (国際ソフトウェアテスト資格認定委員会) が 2023年5月にリリースした Foundation Level シラバスVersion 2023V4.0を日本語訳したものです。この記事では、「2．ソフトウェア開発ライフサイクル全体を通してのテスト」の章における2018年版からの具体的な変更点を解説いたします。なお、各章のタイトルや見出しは、最新版である2023年版に合わせております。

2 ソフトウェア開発ライフサイクル全体を通してのテスト（2018年版・2023版共通）

学習時間が100分から130分に変更となっています。

2023年版では、2018年版から以下のようにキーワードが追加・削除されています。

共通のキーワード2023年版において削除された
キーワード		2023年版において追加された
キーワード
•受け入れテスト
•コンポーネント統合テスト
•コンポーネントテスト
•確認テスト
•機能テスト
•統合テスト
•メンテナンステスト
•非機能テスト
•リグレッションテスト
•システム統合テスト
•システムテスト
•テストレベル
•テスト対象
•テストタイプ
•ホワイトボックステスト		 •アルファテスト
•ベータテスト
•変更関連のテスト
•市販ソフトウェア（COTS）
•契約による受け入れテスト
•影響度分析
•運用受け入れテスト
•規制による受け入れテスト
•シーケンシャル開発モデル
•テストベース
•テストケース
•テスト環境
•テスト目的
•ユーザー受け入れテスト		 •ブラックボックステスト
•シフトレフト

2018年版ではテストプロセス全般に関連するより広範なキーワードを含み、特に開発の初期段階からメンテナンスに至るまでの様々なテスト段階やテストの準備に関する項目が含まれています。一方で2023年版はテストの種類やアプローチに焦点を当てており、特に「シフトレフト」という現代的な開発プラクティスに言及している点が特徴的です。

2.1 コンテキストに応じたソフトウェア開発ライフサイクルでのテスト

タイトルが、「ソフトウェア開発ライフサイクルモデル」から「コンテキストに応じたソフトウェア開発ライフサイクルでのテスト」に変更されており、構成や文章が全体的に改変されています。特に、アジャイルな手法であるテスト駆動開発、DepOpsなどについて新たにセクションを設けて詳しく解説している点は、大きな変更点となっています。

2018年版と2023年版での構成の違いは以下の通りです。

2018年版2023年版
タイトル ソフトウェア開発ライフサイクルモデル コンテキストに応じたソフトウェア開発ライフサイクルでのテスト
構成 •2.1.1 ソフトウェア開発とソフトウェアテスト
•2.1.2 状況に応じたソフトウェア開発ライフサイクルモデル		 •2.1.1 ソフトウェア開発ライフサイクルがテストに与える影響
•2.1.2 ソフトウェア開発ライフサイクルとよい実践例
•2.1.3 テストが主導するソフトウェア開発
•2.1.4 DevOps とテスト
•2.1.5 シフトレフトアプローチ
•2.1.6 ふりかえりとプロセス改善

【冒頭の文章】

2018年版の冒頭では、ソフトウェア開発ライフサイクル（SDLC）モデルの概要を説明し、「ソフトウェア開発プロジェクトの各段階で実施する活動の種類と、これらの活動間の論理的および時系列的な関連を表している」としています。モデルによってテストに対するアプローチが異なることを指摘していますが、具体的なSDLCモデルの例や、それに関連する詳細なソフトウェア開発手法には触れていません。

2023年版では、SDLCモデルをより詳細に説明し、「ソフトウェア開発プロセスを抽象的かつハイレベルに表現したもの」と定義しています。また、「開発フェーズや活動の種類が論理的かつ時系列的にどのように関連しているかを定義する」役割を持つと述べています。

そして具体的なSDLCモデルの例（ウォーターフォールモデル、V字モデル、スパイラルモデル、プロトタイピング、統一プロセス）を挙げ、さらに詳細なソフトウェア開発手法やアジャイルプラクティス（ATDD、BDD、DDD、XP、FDD、カンバン、リーン IT、スクラム、TDD）についても言及しています。

2.1.1 ソフトウェア開発ライフサイクルがテストに与える影響（2018年版：2.1.1 ソフトウェア開発とソフトウェアテスト）

【共通点】

2018年版、2023年版ともに、SDLCモデルとソフトウェアテストの重要性について述べています。また、シーケンシャル開発モデル、イテレーティブ開発モデル、インクリメンタル開発モデル、およびアジャイル開発モデルの概念を共有しています。

【差分】

1.テストの原則と実践の詳細度:
2018年版では、テスト活動が開発ライフサイクルの早い段階から始めるべきであるという原則に重点を置き、テストレベルごとの特有の目的やテスト分析、設計の開始タイミングなど、テストプロセスの具体的な側面を詳細に説明しています。

2023年版では、SDLCへの適応という観点からテストの成功に必要な要素を概説しており、テスト活動の範囲、タイミング、ドキュメントの詳細レベル、テスト技法とアプローチ、自動化の範囲、テスト担当者の役割と責任に焦点を当てています。

2.開発モデルに対するテストの統合:
2018年版では、シーケンシャル（ウォーターフォール、V字モデル）、イテレーティブ、インクリメンタル、アジャイルモデルを通じて、テストがどのように統合されるべきかについて具体的な説明を提供しています。特に、V字モデルにおけるテストレベルの対応やアジャイル開発におけるテストの役割について詳しく述べています。

2023年版では、SDLCモデルの選択がテスト活動にどのように影響するかを概説しており、各開発モデル（シーケンシャル、イテレーティブ、インクリメンタル、アジャイル）におけるテストの実施方法の違いについて触れていますが、2018年版ほどの詳細は提供していません。

3.テスト自動化とテスト技法:
2018年版では、テスト自動化やテスト技法についての言及が少なく、テストの原則や開発モデルとの統合により焦点を当てています。

2023年版では、テスト自動化の範囲やテスト技法の選択がSDLCモデルによってどのように影響されるかについて言及しており、アジャイル開発における自動化の重要性や経験ベースのテスト技法について具体的に触れています。

2.1.2 ソフトウェア開発ライフサイクルとよい実践例（2018年版：2.1.2 状況に応じたソフトウェア開発ライフサイクルモデル

【共通点】

1.SDLCモデルの選択の重要性:
どちらも、SDLCモデルの選択とそのプロジェクトやプロダクトに対する適応の重要性を強調しています。

2.テスト活動の統合:
どちらも、開発活動に対応してテスト活動が存在すること、およびテストが開発ライフサイクルの早い段階から統合されるべきであることを指摘しています。

【差分】

1.焦点の違い:
2018年版では、SDLCモデルをプロジェクトやプロダクトの特性に応じて選択し、必要に応じて調整する必要があるという点に焦点を当てています。プロジェクトのゴール、プロダクトの種類、ビジネス上の優先度、リスクの識別など、多様な要因に基づいてSDLCモデルを適切に選択し調整することの重要性を強調しています。

2023年版では、選択されたSDLCモデルに関係なく、よいテスト実践には共通の要素があることを強調しています。これには、開発活動に対応するテスト活動の存在、異なるテストレベルでの目的の違い、テスト分析や設計の開始タイミングなどが含まれます。

2.テストレベルとテスト活動の詳細:
2018年版では、プロジェクトの状況に応じてテストレベルやテスト活動を組み合わせたり再編成したりする必要性について述べており、特定のプロジェクト状況やプロダクトタイプに基づいたSDLCモデルの選択と調整の例を提供しています。

2023年版では、テスト実践の一般的な原則に焦点を当てており、テスト活動がどのようにSDLCの各フェーズに統合されるべきかについてのガイドラインを提供しています。

2.1.3 テストが主導するソフトウェア開発（2023年版のみ）

2018年版には含まれていない内容です。
ここでは、テストが主導するソフトウェア開発アプローチであるテスト駆動開発（TDD）、受け入れテスト駆動開発（ATDD）、振る舞い駆動開発（BDD）について説明しています。これらのアプローチはいずれも、コードを書く前にテストケースを定義するため、開発プロセスにおいてテストを先行させることで、早期テストの原則を実装し、シフトレフトアプローチを採用しています。各アプローチは、イテレーティブ開発モデルをサポートし、コードの品質を向上させることを目的としています。

2.1.4 DevOps とテスト（2023年版のみ）

2018年版には含まれていない内容です。
ここでは、DevOpsとそのテストプロセスに関するアプローチについて説明しています。DevOpsは開発と運用の間の協力を促進し、迅速なフィードバック、継続的インテグレーション（CI）、継続的デリバリー（CD）を通じて高品質のコードの迅速なリリースを目指す組織的アプローチです。このアプローチはテストにおいても多くの利点を提供しますが、一定のリスクや課題も伴います。

2.1.5 シフトレフトアプローチ（2023年版のみ）

2018年版には含まれていない内容です。
ここでは、ソフトウェア開発ライフサイクル（SDLC）における「シフトレフト」アプローチとその実践方法について説明しています。シフトレフトは、テスト活動を開発プロセスのより早い段階に移動させることを提案し、これにより問題を早期に発見し、修正コストを削減することを目指します。

2.1.6 ふりかえりとプロセス改善（2023年版のみ）

2018年版には含まれていない内容です。
ここでは、プロジェクトやイテレーションの終了時、または重要なマイルストーンで行われるふりかえり（レトロスペクティブ）ミーティングと、それがプロセス改善にどのように貢献するかについて説明しています。ふりかえりは、プロジェクトチームが成功した点、改善が必要な点、そして将来に向けての改善策を議論し、記録するための重要な機会です。このプラクティスは、テストプロセスを含むプロジェクト全体の継続的な改善を目指します。

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

2018年版では「2.2 テストレベル」と「2.3 テストタイプ」の2つに分けて解説されていたものが、2023年版では一つにまとめられています。

2.2.1 テストレベル（2018年版：2.2 テストレベル）

2018年版、2023年版の比較は以下の通りです。

2018年版2023年版
テストレベルの説明 両者とも以下の点において共通している。
•系統的にまとめられ、マネジメントされるテスト活動のグループであること
•SDLC内の他の活動と関連付けられること
•個々のコンポーネントやシステム全体の開発段階に応じたテストプロセスのインスタンスであること
説明の詳細度 以下に挙げている属性を用い、各テストレベルを詳細に説明している。 2018年版ほどの詳細な説明は省略されている。
扱っているテストレベル •コンポーネントテスト
•結合テスト
•システムテスト
•受け入れテスト		 •コンポーネントテスト
•コンポーネント結合テスト
•結合テスト
•システムテスト
•受け入れテスト
テストレベルを特徴づける特性 •特定の目的
•テストベース（テストケースの導出時に参照）
•テスト対象（すなわち、テストするものは何か）
•典型的な欠陥と故障
•（そのテストレベルでの）アプローチと責務		 •テスト対象
•テスト目的
•テストベース
•欠陥、および故障
•アプローチと責務

2.2.2 テストタイプ（2018年版：2.3 テストタイプ）

テストタイプの定義の表現については、2018年版と最新版で若干異なっています。
2018年版と2023年版のテストタイプの定義は以下の通りです。2023年版（「2.2 テストレベルとテストタイプ」冒頭に記載）では、よりシンプルに表現されています。

2018年版2023年版
テストタイプは、以下に列挙する特定のテストの目的から見たソフトウェアシステム（あるいはシステムの一部分）の特性をテストするための活動を束ねたものである。
•機能の品質特性、例えば完全、正確および適切であることなどを評価する。
•非機能の品質特性、例えば信頼性、性能効率性、セキュリティ、互換性、使用性などを評価する。
•コンポーネントまたはシステムの、構造またはアーキテクチャーが正しく完全で仕様通りであることを評価する。
•欠陥が修正されていることを確認するなどの変更による影響を評価し（確認テスト）、ソフトウェアや環境の変更によって意図しない振る舞いの変化が発生していないかを探す（リグレッションテスト）。		 テストタイプは、特定の品質特性に関連するテスト活動のグループであり、それらのテスト活動のほとんどは、すべてのテストレベルで実行することができる。

なお、2023年版の「すべてのテストレベルで実行することができる」という内容ですが、2018年版においても、「2.3.5 テストタイプとテストレベル」のセクションにて、「すべてのテストタイプは、すべてのテストレベルで実行できる」ことが具体例を挙げて解説されています。

扱っているテストタイプは以下の通りです。

2018年版2023年版
•機能テスト
•非機能テスト
•ホワイトボックステスト
•変更関連のテスト		 •機能テスト
•非機能テスト
•ブラックボックステスト
•ホワイトボックステスト

2018年版では、各テストタイプの目的、実施方法、特定のテスト技法の使用例、テストが十分かを計測する方法など、詳細に説明されています。対して2023年版では、2018年版ほどの詳細度はなく、各テストタイプの基本的な目的や概念に焦点を当てています。

2018年版で「変更関連のテスト」に含まれている確認テストとリグレッションテストは、2023年版では上述した4つのテストタイプとは分けて解説されています。
確認テストおよびリグレッションテストにおける、2018年版と2023年版の説明の違いは以下の通りです。

2018年版2023年版
確認テスト 確認テストのプロセスをより具体的に述べている。 確認テストの目的と可能なアプローチをより一般的に説明している。
リソースの制約に対する対応策についても言及している。
リグレッションテスト リグレッションテストがなぜ必要なのか、その目的と変更がもたらす潜在的な副作用について説明している。
具体的には、コードの一部に対して行われた修正や変更（システムのバージョン、環境の変更も含む）が、意図せず他のコンポーネントやシステムに影響を及ぼす可能性があることに言及している。		 確認テスト済みの修正を含む変更が悪影響を及ぼさないことを確認するためにリグレッションテストが行われること、そしてこれらの悪影響がテスト対象や環境に及ぶ可能性があることが説明されている。また、リグレッションテストの効率を最適化するために影響度分析を行うことの重要性にも触れている。

また両者とも、確認テストとリグレッションテストについて以下のように言及しています。

•リグレッションテストスイートは何度も実行され、少しずつ拡充をしていくこと
•リグレッションテストの自動化が非常に重要であること
•確認テストおよびリグレッションテストがすべてのテストレベルで必要であること
•リグレッションテストの自動化は開発プロセスの早い段階で開始することが推奨されること

そのうえで2023年版では、以下についても言及しています。

•DevOps環境では、自動化されたリグレッションテストを継続的インテグレーション（CI）プロセスに組み込むことがよい実践とされていること。
•異なるレベルでのリグレッションテストを含めることが可能であること。

2.3 メンテナンス（保守）テスト（2018年版：2.4．メンテナンス（保守）テスト）

2018年版、2023年版ともに、メンテナンステストの重要性とその範囲を決定する要因について言及しています。また、メンテナンステストが変更の正確な適用を評価し、システムの他の部分での潜在的な副作用をチェックするために必要であるという点で一致しています。
また両者とも、メンテナンステストの範囲は、典型的には次に依存するとしています。

•変更のリスクの度合い
•既存システムの大きさ
•変更の大きさ

2018年版では、メンテナンスが必要となる具体的な理由（変更作業、移行作業、廃棄作業）に焦点を当て、それぞれのカテゴリーについて詳細に説明しています。
2023年版では、メンテナンスのカテゴリーをより広範に捉え、計画的なリリースや非計画的なリリース（ホットフィックス）を含むメンテナンスの全体像について説明しています。また、メンテナンスのきっかけをより具体的な例で説明しています。

また2018年版は、「メンテナンスの影響度分析」についてセクションを設けて詳細に解説していますが、2023年版では、「システムの他の領域への潜在的な影響に基づき変更をするべきかどうかを判断するために、変更をする前に影響度分析を行うことがある」という言及にとどめています。

2023年版シラバスはこちら
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf

2018年版シラバスはこちら
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf