JSTQB Advanced Level テスト自動化エンジニア (TAE) シラバス 要約

JSTQB Advanced Level テスト自動化エンジニア (Test Automation Engineer: TAE) のシラバス要約です。

自動テストを単なるスクリプトではなく、「ソフトウェアシステム (TAS)」 として設計・運用するための知識体系です。

目次

第1章：テスト自動化の導入と目的

• 目的: 効率化だけでなく、信頼性の向上、カバレッジの拡大、手動テストでは不可能なテスト（並列実行など）の実現。
• 成功要因:
  • 自動化は「銀の弾丸」ではないとステークホルダーに理解させる。
  • 保守コストを考慮する（作った後のコスト）
  • 手動テストと自動テストの役割分担を明確にする。

第2章：テスト自動化の準備

• SUTの試験性（Testability）:
  • 自動化しやすいように、アプリ側にIDを振ってもらったり、ログを出力させたりする「試験性を考慮した設計（DFT）」が重要。
• ツール選定:
  • 単に「人気があるから」ではなく、組織の技術スタック、予算、将来性を考慮して選ぶ。プロトタイピング（PoC）をしてから導入する。

第3章：汎用テスト自動化アーキテクチャ (gTAA)

• TAAの設計: 上記の4層構造を意識し、プロジェクトに合わせてカスタマイズする。
• TASの開発: TAA（設計図）に基づいて、実際のツールやライブラリを組み合わせてTAS（実体）を作る。

※ 例「Playwright + GitHub Actions + Reporting」の組み合わせ構築など。

第4章：デプロイメントのリスクとコンチンジェンシー

• リスク:
  • 「メンテナンスの悪夢」: 自動化コードがスパゲッティ状態になり、修正コストが手動テストの時間を上回ってしまう現象。
  • ベンダーロックイン: 特定のツールに依存しすぎて移行できなくなる。
  • パイロットプロジェクト: いきなり全展開せず、小規模な範囲で試して問題を洗い出す。

第5章：テスト自動化のレポーティングとメトリクス

• 計測:
  • 自動化の メリット（ROI） を測定する（浮いた時間 vs メンテナンス時間）
  • テスト実行時間、パス/フェイル率、コードカバレッジ。
  • TAS自体の品質: 自動テストコード自体のバグ密度なども管理する。

第6章：手動テストからの移行

• 自動化すべきテスト:
  • 実行回数が多い（リグレッション）
  • 手動だとミスしやすい。
  • クリティカルな機能。
• 自動化に向かないテスト:
  • 一度しか実行しないテスト。
  • 仕様が頻繁に変わる不安定な機能。
  • UXや見た目の感覚的なチェック。

第7章：TAS（テスト自動化ソリューション）の検証

• 「テストのテスト」: 自動テストコード自体もバグを含む可能性があるため、検証が必要。
• 偽陽性と偽陰性:
  • 偽陽性: バグじゃないのにテストが落ちる（スクリプトの問題）
  • 偽陰性: バグがあるのにテストが通ってしまう（検証ロジックの不備）

第8章：継続的改善

• リファクタリング: アプリのコードと同様、自動テストコードも定期的にきれいにする。
• ライブラリの更新: サードパーティライブラリ（Playwrightのバージョンアップなど）への追従。