ベテランQAエンジニアがJSTQB Advanced Level Test Analyst（AL TA）を受験して思ったこと

May 10, 2026

はじめに

2026年5月9日、JSTQB Advanced Level Test Analyst（AL TA）の試験を受験しました。

QAエンジニアとしてのキャリアは、自分でもびっくりするくらい長くなりました。

そんな私は、JSTQBの存在は以前から知りつつも、学習時間の確保や受験料を考えると、なんとなくスルーしてきました。
しかし、2026年3月に、JSTQB Foundation Levelを受験して合格したことをきっかけに、その勢いで、次はその上位資格のAdvanced Level Test Analyst（AL TA）に挑戦してみようと思いました。
今回、腰を据えてJSTQB資格取得に向き合ったところ、長年「なんとなく」やっていたことに、次々と言語化される感覚を得ました。

JSTQB ALTAとは

JSTQB（日本ソフトウェアテスト資格認定委員会）は、ソフトウェアテストの国際資格です。その中でもAdvanced Level Test Analyst（ALTA）は、テスト分析・設計に特化した上級資格で、以下のような内容をカバーしています。

テスト技法（同値分割法、境界値分析、デシジョンテーブルテストなど）の体系的な理解
テストプロセスにおけるテストアナリストのタスク
ソフトウェア品質特性のテスト
要件レビュー、ユーザーストーリーレビューのポイント
リスクベースのテストアプローチ

Foundation Levelと異なり、設計の「なぜ」と「どうやって」が問われる試験です。

「現場経験」だけで来てしまった長年

長いキャリアの中で、テスト技法の知識は「実戦で身についたもの」がほとんどでした。
同値分割や境界値分析は日常的に使っていましたが、それがどの技法に分類されるのか、なぜその技法が有効なのか、を言葉で説明できているかというと……正直、あいまいなことも多いかなと思います。

シラバスを読んで「腑に落ちた」瞬間

学習を進める中で何度も感じたのが、「あ、あのときやっていたのはこれか」 という感覚です。
体系的な学習は、新しい知識を得るだけでなく、既存の経験に名前と根拠を与えてくれるもの だと実感しました。

以下、いくつかの具体的なエピソードを紹介します。

1.テストにかける労力のバランス

テストにどの程度の労力をかけるべきか、という判断は常に悩ましいものです。
FLの学習と現場の経験則で「全数テストは不可能」と実感しつつ、では、どこまでテストすればいいのか、という次なる課題に対して、 AL TAの学習の中で、対象のリスクレベルとビジネス価値に見合うようにバランスをとるという考え方が示されていて、なるほどと思いました。

2.トレーサビリティの確立の重要性

現場では、テストベース（要件やリスク）とテストケースのトレーサビリティが確立されていないことが多く、テストケースがどの要件をカバーしているのか、どのリスクに対応しているのかが不明瞭なことが多いです
しかし、やはりテストケースと要件・リスクのトレーサビリティを明確にして、テストの網羅性や効果を評価することがベターであることを再認識しました。特に、金融業界や医療業界など、品質が特に重要な分野では、トレーサビリティを確立して、厳格な品質管理を行うことが求められるだろうと感じました。

3.ハイレベル/ローレベルのテスト設計

現場では「テストの粒度」という言葉をよく使っていましたが、シラバスでは、「ハイレベル/ローレベル」という言葉で定義されていました。
熟練されたチームではハイレベル（抽象的）、経験が浅いチームではローレベル（具体的）なテスト設計というように、使い分けることでテスト設計の効率と効果を高めることができるという考え方が示されていて、なるほどと思いました。
一方で、メンテナンスコストについても言及されていて、これは、まさに現場で感じていたことで、この粒度のバランスが難しいところだと感じていました。

4.リスクレベルを決める2つの要素

リスクレベルを決める要素として、「発生確率」と「影響度」の2つがあることが示されていました。
ともすると、複雑な機能のテストにばかり注力してしまいがちですが、実際には、単純な機能であっても、発生確率が高く、影響度も大きい場合は、リスクレベルが高くなり、重点的にテストする必要があることを再認識しました。

5.テスト技法のおさらい

AL TAの学習を通じて、テスト技法を体系的におさらいすることができました。特に、状態遷移図テストの1スイッチカバレッジとユースケーステストは、現場でも積極的に活用したい技法だと感じました。

6.経験ベースのテスト技法

探索的テストは、ある意味、邪道なテスト技法だと思っていましたが、シラバスでは、経験ベースのテスト技法として、正式に定義されていて、アプローチの1つとして認められていることに驚きました。
確かに現場では、仕様が不明確な部分や、テストケースを作成する時間がない場合がままあるので、このような状況では、経験と直感を頼りにテストを進める探索的テストが有効なアプローチになることが多いと感じていました。
しかし、経験ベースのテスト技法は、ブラックボックステストなどの仕様ベースの技法を補完するための位置づけであることも理解しておく必要があると感じました。

7.ソフトウェア品質特性の理解

ISO/IEC 25010 などの品質モデルに基づいて、ソフトウェア品質特性を理解することが重要であることが示されていました。
機能適合性（Functional Suitability）、互換性（Compatibility）、使用性（Usability）、移植性（Portability）などの品質特性があり、それぞれの特性に着目したテスト項目も考慮することで、より包括的なテスト設計が可能になることを再認識しました。

8.レビューにおけるチェックリストの活用

要件レビュー、ユーザーストーリーレビューを行う際に、チェックリストを活用することで、レビューの品質を向上させることができるという考え方が示されていました。
要件レビューでは、特に、要件が「テスト可能か？（Testability）」という観点で評価されることが重要で、テスト不可能な要件は、要件の欠陥であり、曖昧性をいかにクリアするかが重要であることを再認識しました。
また、個人的には、チェックリストを活用することで、属人性を減らすことができるという点が特にささりました。
現場で人対人でネガティブなフィードバックをする場合の、心理的な摩擦を減らす手段に有効だと感じました。

試験を受けてみての感想

試験を通じて強く感じたのは、タイムマネジメントが必須だということです。

40問を120分で解く必要があるため、単純計算で1問あたり3分程度のペースで解く必要がありますが、テスト技法を使用して解く問題は時間がかかります。

テスト技法を使用して解く問題以外の問題は1問あたり1分～1.5分程度
テスト技法を使用して解く問題は1問あたり数分程度

のようなペースで解いていかないと、全問解くことができません。
なので、丁寧に問題の最初から最後まで読み、選択肢を吟味していると、時間が足りなくなってしまう可能性が高いと感じました。試験では、設問からまず見て、下から上に遡って文章を読解したり、選択肢を先に見て、消去法であきらかに違うものを除外するなど、時間を節約するなど工夫が必要だと感じました。

難易度と出題の特徴

シラバスの各章をまんべんなく網羅した出題傾向でした。
特に、テスト技法を使用して解く問題もシラバスに記載のブラックボックステスト技法（同値分割法、境界値分析、デシジョンテーブルテストなど）もまんべんなく出題されていました。
過去問と同じような問題が出題される傾向がありました。

手応え

合格ラインは65％程度の正解率とされていますが、正直、合格できているかどうかは微妙な感触でした。

過去問を解き、タイムマネジメント対策をして試験に臨んだため、一通り時間内に全問解くことができましたが、テスト技法を使用して解く問題の1問あたりにかける時間が短くなって、正解が選べていないかもしれないと思いました。
また、実務だとペアワイズの組み合わせなど、ツールを使ってテストケースを生成したり、エクセルなどで、じっくり試行錯誤しながら、テストケースを作成しますが、試験では、ホワイトボードのメモに手作業で組み合わせを考えて解く必要があるため、時間がかかりました。

また、実際の試験では、ホワイトボードのメモはA4サイズの1枚ですが、案の定、1枚では書ききれず、試験途中に呼び出しボタンを押して、試験官にメモの交換を依頼しました。
このメモは新しいものと古いものを交換するしくみでした。 AL TA試験は、メモの量が多くなるので、ここは試験制度を改善してほしいなと思いました。（最後のアンケートに記載しました）

学習方法・教材・期間など

公式のAL TAシラバスと、ISTQBの過去問（英語版）を使用して学習しました。
学習期間は約1.5ヶ月で、平日は1日1時間程度、休日は2～3時間程度学習するペースで進めました。
NotebookLMを活用して、以下を行いました。
- シラバスの内容を自分の言葉でまとめる。こちらにまとめました
- 過去問の日本語訳および解説を自分の言葉でまとめるこちらにまとめました
- シラバスの内容を音声解説にして、通勤時間などに聞いて耳学習する

ベテランエンジニアこそ、体系的学習に価値がある

今回最も伝えたいことは、
「経験があるから資格は必要ない」という考えは半分正しく、半分間違いです。
経験は財産ですが、その経験を他者とシェアするには「言語化」が必要です。

JSTQBのシラバスは、その「言語化のフレームワーク」を提供してくれました。長年の経験がシラバスの言葉と結びついたとき、自分の知識の輪郭がはっきり見えた気がしました。

おわりに

試験結果はまだ先になりますが、合否にかかわらず、この学習自体が大きな収穫でした。

経験豊富なエンジニアの方でも、一度JSTQBのシラバスを手に取ってみることをおすすめします。

私は、「あれは、そういうことだったのか」という発見がたくさんありましたし、現場での経験がより意味のあるものになったと感じました。