ISTQBのFoundation Level資格試験は、テストに関する目的考え方からテスト活動の設計・実施に実際に利用されるテクニックに対して体系化された知識がまとまっているので、テストに携わることの多いDeveloperやPMに幅広くおすすめしたい資格の一つです。
2023年4月、ISTQBのCTFLシラバスに2018年以来のメジャーアップデート(v3.1→4.0）がありました。
この記事では、アップデートされたシラバスにどのような内容な変化があったか、各章の違いやそこから見えるテスト活動・品質保証の考え方の変遷について、簡潔にまとめようと思います。
更新内容に関しては全てをカバーできているわけではないため、この記事で全容を掴みつつ、実際のシラバスや試験内容について確認して知識を深めていってください！
記事のおおまかな構成
- ISTQB CTFL v4.0で変わった点の概要
- 大きく追加・変更となった章/文章
想定する読者
- すでにISTQB-CTFLを持っているQA/Tester
- これから資格にチャレンジしようと思っている方
1. 変更内容の全体像
これは体感ですが、2~3割程度が大きく更新されている、という印象です。今回の変更で特に顕著だった点としては2点あります。
「テストの目的やテスターのマインドセットの変化」
テストの目的の表現方法が、どの章でも変わっている印象でした。欠陥によるリスクを低減する("Reducing Risk of Defect")という目的から、欠陥を発見すること("Detecting Defects")という記載に変わっており、開発プロジェクトのどのフェーズでもテスト対象(Test Object)の高品質化に貢献する、と記載されています。(1.2.1 Testing's Contributions to Success)
「アジャイル開発を強く意識した記載の変更」
特にここは色濃く、2018年のv3.1ではWaterfallと対比して軽く紹介されていたイテレーティブ開発(≒アジャイル開発)が、2023年ではメインストリームの知識として各章に内容が散りばめられています。特に4.5「コラボレーションベースのテストアプローチ」ではテスターが積極的にバックログ・受入条件の作成に参加することが求められるという記載があります。
章構造の変更について
- 1.4 「テスト活動、テストウェア、テストロール(役割)」 1.5「テストに欠かせないスキルと良いプラクティス」 の追加（構造変更）
- 4.5 「コラボレーションベースのテストアプローチ」新規追加
- 5章 全体的に構成変更、いくつかの章が追加
すでに取得した人が読んでおくべき章
「ええ、折角取ったのに、更新されちゃったの...」
そう思った皆様向けのまとめです。最近2〜3年間でISTQB(JSTQB含め)のCTFL試験に合格している方であれば、最低限、下記の章を読めばトレンドや記載の変化がわかります。この記事の後方でそれぞれの章について詳しく内容を説明します。
- 2.1.3 開発を牽引する役割(Driver)としてのテスト
- 2.1.4 DevOpsとテスト
- 2.1.5 シフトレフトアプローチ
- 2.1.6 レトロスペクティブとプロセスの改善
- 4.5 コラボレーション・ベース（協業的）テストアプローチ
- 4.5.1 コラボレーティブ・ユーザストーリー・ライティング
- 4.5.2 受入条件(Acceptance Criteria)
- 4.5.3 受入テスト駆動開発(ATDD)
- 5.1.2 Iteration&Release計画へのテスターの貢献
2.変更・更新された章とその内容
1.1 テストとは何か
テストの目的について、下記のような記載の差分があります。
- To prevent defects by evaluate work products such as requirements, user stories, design, and code
+ Triggering failures and finding defects
"Prevent"という動詞が"Trigger", "Find"という動詞に置き換わっていることで、従来の「欠陥を防止する」という受動的な視点から、現代のアジャイルやDevOpsの考え方を取り入れた「失敗を引き起こし、欠陥を見つける」という積極的な視点へとシフトしています。
マーケットの需要や仕様の高速な変化に対応することが求められる昨今のソフトウェア開発の現場において、事前に全ての欠陥を防ぐのは非現実的であるという記載 (1.3 Testing Principles) と関連性が見られます。テストは単に品質のゲートキーパーとしての役割だけではなく、品質を積極的に向上させるためのアクティブな活動として位置づけられています。
2.1.3 開発を牽引する役割（Driver）としてのテスト
この章では、テストに「開発を牽引していく役割」を持たせるための3つのアプローチについて紹介されています。
TDD(Test Driven Development, テスト駆動開発)
最初にテストケースやテストコードを記載し、それを通すように開発します。Red(テスト失敗) → Green(テスト成功) → Refactor(リファクタリング)という流れで開発していきます。筆者はコーディングを覚えてからかなりの期間競プロなどで勉強してきたので、割と肌に馴染む開発方法でした。
ATDD(Acceptance Test Driven Development, 受入テスト駆動開発)
要件定義・設計の段階で作成されるシステムの受入条件が作成される段階でテストを作成します。受入条件をテストケースに変換することで、テストが通っている＝定義した受入条件を満たしている という状態を作り出します。詳細は4.5.3で紹介されているので割愛します。
BDD(Behavior Driven Development, ビヘイビア駆動開発)
テストケースを自然言語で記載する手法で、通常はGiven, When, Thenというフォーマットでコードやシステムの動作について記載され、コードに直接触る関係者以外でもわかりやすい表現方法として取り入れられます。記述されたテストケースは、テストコードに変換され実行可能な資源となることが想定されます。
2.1.5 シフトレフトアプローチ
シフトレフトとは、基本的には「問題を先延ばしにせず、先手を打って対処する」という考え方に根ざしています。洗濯物や食器の洗い物を溜めずに少しずつ片付けるように、早期から課題をアクティブに発見・対処することで品質の高いソフトウェア・システムを目指すという考え方です。
引用：https://devopedia.org/shift-left
旧v3.1シラバスでも１節 (1.3 Seven Testing Principles） で言及はありましたが、新シラバスでは1つの章として追加され、下記の5つのプラクティスが紹介されています。
- ドキュメント・仕様書をテスト観点で早期からレビューを実施すること
- テストケースをコードより先に書くこと
- CI/CDを活用してテスト自動化を導入していくこと
- 静的解析を動的テストより前に実施すること
- 性能テストを早期（単体テストレベル）から導入すること
個人的な所感ですが、特に5つ目（性能テストの早期化）は確かに重要性が高いと感じます。理由は下記の3つが挙げられます。
- 性能テストで発見されるバグは、アーキテクチャなどの見直しなどかなり大きな改修につながるリスク
- 性能テストを大詰めでやろうとする場合、システムによっては適したツール等がない（粒度が単体とか、APIの一つのエンドポイント等であればそれに適応するツールがあることが多い）
- 性能指標がNGだった場合、そのボトルネック探しが大変だから
2.1.6 レトロスペクティブとプロセスの改善
レトロスペクティブ（振り返り）によって開発・テストのプロセスを改善し、生産性を向上する手法について記載しています。Scrumのプラクティスを転記したような形なので、詳しい実践方法はシラバスとScrum Guideを参照することをお勧めします。
4.5.1 コラボレーティブ・ユーザストーリー・ライティング
「ユーザストーリー」とは、要件定義の一つの形式で、ユーザに価値を提供する機能を文章で表現したものです。「〇〇(役割)として、〇〇(ビジネス価値)のために〇〇(仕様により達成するゴール)したい」という形式で表現されます。
ユーザストーリーはINVESTの原則（Independent, Negotiable, Valuable, Estimable, Small and Testable）を満たす必要があります。そのためにテスタビリティの観点からユーザーストーリーの作成・レビューに関与することが重要とされています。
4.5.2 受入条件(Acceptance Criteria)
受入条件とは、そのユーザーストーリーがステークホルダーに受け入れられるための明確な条件を示すものです。これはテストの際に行うべき検証の条件として捉えることができ、ユーザーストーリーの範囲やステークホルダー間の合意形成の道具として使われます。
受入条件の作成には様々な方法が存在します。主に使われるのは「シナリオ指向」(BDDでも利用されるGiven/When/Thenフォーマット)、「ルール指向」(例：箇条書きの検証リストや、Input-Outputのマッピングを表形式で表現)という2つの形式です。それぞれのプロジェクトやチームの特性に応じて、これらの形式を適用するか、または独自の形式を使って受入条件を明確かつ曖昧さのないように記述することが重要です。
4.5.3 受入テスト駆動開発(ATDD)
受入テスト駆動開発（ATDD）は、ユーザーストーリーを実装する前にテストケースを作成します。このテストケースは、異なる視点を持つチームメンバー（顧客、開発者、テスターなど）が集まって作成します。最初にユーザーストーリーとその受入条件をチームメンバーで議論し作成する仕様ワークショップが行われます。ユーザーストーリーの不完全さや曖昧さ、欠陥をこの議論の中で消し込みます。
テストケースは、すべてのステークホルダーが理解できる形式で表現します。テストケースがテスト自動化フレームワークでサポートされる形式で記述されていれば、開発者はユーザーストーリーで説明される機能を実装する際に、そのサポートコードを書くことでテストケースを自動化することができます。
5.1.2 Iteration&Release計画へのテスターの貢献
リリース計画は、製品のリリースに先んじて行われる計画です。この段階では、製品の大局的なビジョンを持つための製品バックログの定義や再定義、大きなユーザーストーリーをより具体的な小さなユーザーストーリーへと分割する作業が行われます。そして、シラバスでは、この段階でテスターがテスト可能なユーザーストーリーや受け入れ基準の作成に関与することの重要性が強調されています (参照: 4.5)。
一方で、イテレーション計画は1つのイテレーションを完結させるための短期的な計画として位置づけられています。具体的には、次のイテレーションで実施するユーザーストーリーやタスクの詳細なリスク分析、テスタビリティの確認などが行われます。ここでも、テスターがユーザーストーリーの詳細なリスク分析やテスタビリティの判断など、品質を確保するための重要な役割を担うことが示されています (参照: 5.1.4)。
このように、テスターがソフトウェア開発の初期段階から深く関与することで、品質の向上を積極的に推進するという現代のアジャイルやDevOpsの考え方を反映しているといえます。
まとめ
新規追加となった章を中心に内容を解説しました。2018年版のシラバスと付き合わせて比較してみても、「アジャイル開発」や「シフトレフト」を中心に、テスト活動にあたるマインドセットの移り変わりが色濃く出ていたと思います。ぜひシラバスに目を通してみて、資格取得もチャレンジしてみてください！
それではみなさま、Happy Testing!
Accenture Japan QE&A (Quality Engineering & Assurance) の SDETの有志メンバーによる記事ページ
Discussion