Outline

ISQTBのテスト自動化のシラバス「Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) 」が 2024年5月に v2.0 にバージョンアップしました。

自己学習のために、改めてシラバスを読みなおしました。
ここでは、英語翻訳、自己解釈したものをつらつらと記載しました（誤解釈があったらごめんなさい）
長いので、分割して記事にした。

なお、本記事に使用した図はISTQBシラバスのものである。

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

1.1 テスト自動化の目的

1.1.1 テスト自動化のメリットとデメリット

テスト自動化、テストの実行やレポーティングを自動化するもの、は次の活動を含んでいます。

専用ソフトウェアを用いてテスト実行のスイートの制御、設定を行う
自動でテスト実行する
実際値と期待値を比較する

テスト自動化の重要な機能提供により、テスト対象(SUT)と相互作用することができる。
テスト自動化は広範囲、いろいろな種類のソフトウェア(UI、UIのないもの、モバイルアプリケーション、ネットワークプロトコル、ネットワーク接続など)をカバーする。

テスト自動化のメリットは以下の通りです

手動テストに比べて多くのテストをビルド毎に実施できる
手動では実行できないテストを作成、実行できる（リアルタイム応答、リモートテスト、並行テストなど）
手動テストより複雑なテストを実行できる
手動テストより速く実施できる
ヒューマンエラーが起きにくい
より効果的、効率的にテストリソースを使うことができる
SUT品質に対して早いフィードバックができる
システム信頼性を改善できる（可用性、復元性）
テスト一貫性を改善できる

ただし、デメリットもあります

追加コストが増え、テスト自動化エンジニア(TAE)を雇い、新しいハード購入、育成が発生するかもしれない
初期投資でテスト自動化ソリューション(TAS)構築が求められる
TASの開発や保守に時間を要する
成功要因としてテスト自動化の明確な目的設定がある
SUTの仕様変更への変化の柔軟性が低い
テスト自動化によって、あらたな欠陥を導く

また、制約もあります

すべての手動テストを自動化できない
検証できるのは、テスト自動化がプログラムされたところだけである
テスト自動化は機械が理解できるテスト結果のみを検証するため、いくつかの品質特性をテスト自動化でテストできない可能性がある
テスト自動化は事前に用意したテストオラクルでテスト結果をチェックすることできる（裏を返せば、事前にテストオラクルがないと検証作業ができない）

1.2 テスト自動化のソフトウェア開発サイクル

1.2.1 テスト自動化を異なるソフトウェア開発サイクルモデルでどのように導入するか？

ウォーターフォール

直線的で順次的に工程が進む
フェーズが明確になっている（要求、設計、実装、検証、保守など）
各フェーズにおいて、ドキュメンテーションで承認が必要になる
テスト自動化の実装は実装フェーズと並行もしくは後に行われるのが一般的
テストは検証フェーズに行われる。それは、たいていソフトウェアがそのフェーズにならないと準備されないからである

V字モデル

順次的に工程が進む
高レベルの要件から低レベルの要件へ定義されると、それに対応するテストと統合活動が定義され、要件を検証する
コンポーネント、コンポーネント統合、システム、システム統合、受入テストといったテストレベルが各テストレイヤーで引き出される
各レイヤーに合わせたテスト自動化フレームワーク(TAF)を提供することができる

アジャイル開発

テスト自動化には無限の可能性がある
TAEやビジネス担当者がロードマップ、タイムライン、テスト計画を決める
コードレビュー、ペアプログラミング、頻繁なテスト自動化実行といったベストプラクティスがあります
関係者が協働し、サイロ化を排除することで、適切な量と深さのテスト自動化でテストをカバーすることができる（in sprint automation）

図の reference

1.2.2 SUTへ適切なテスト自動化ツールを選定

プロジェクトに最適なテストツールを選定するには、最初にSUTを分析することです。
TAEはプロジェクト要求を特定し、ツール選定の基準を定める。
UIソフトウェアやWEBサービスなど、対象に合った異なるテスト自動化ツールがあるため、プロジェクトで何を達成したいのかを理解することが重要です。
多くのテスト自動化ツールや機能を選ぶことができますが、コストを考慮する必要があります。
商用ツールやOSSをカスタマイズ実装することは、複雑なプロセスになる可能性があります。

次に評価するトピックは、テスト自動化チームの構成と経験です。
テスターが未経験プログラマーであると、ローコードやノーコードのツールが有効になるであろう。
プログラム経験者のテスターの場合、SUTに適合したツール選定がしやすい。
これは、開発者と協働し、テスト自動化の欠陥を効率よくデバッグでき、クロストレーニングできるなどのメリットがある。

2 テスト自動化の準備

2.1 テスト自動化のインフラ構成の理解

2.1.1 テスト自動化実装を可能とするインフラ要件

SUTのテスタビリティ（テスト容易性）は他の機能の設計、実装と並行して設計、実装すべきである。
テスタビリティとは、例えばテストをサポートするインターフェースを可能にしたり、SUTを制御、観測できるようにするものである。
これは、ソフトウェアアーキテクトによって行われる。テスタビリティは非機能要件であり、TAEとともに改善できる部分を特定する。

SUTの良いテスタビリティのため、インフラ要件に合わせた異なるソリューションがある

アクセサビリティ識別子

さまざまな開発フレームワークが自動的に識別子を生成、もしくはエンジニアが手動で設定する

システム環境変数

特定のアプリケーションパラメータを設定するとこで、管理者モードで簡単にテストすることができる

デプロイ変数

システム変数と類似していて、デプロイ前に設定できる

SUTのテスタビリティで設計する視点として以下のようなものがある

観測性 (Observability)

SUTがインターフェースを提供し、内部を見えるようにする。テストケースがこのインターフェースを用いて実際の値を取得して、期待値と比較できるようにする

制御性 (Controllability)

SUTがインターフェースを提供し、操作できるようにする。UI要素、関数コール、通信要素（TCP/IP,USB protocolなど）、電気通信、物理スイッチ、などである。

アーキテクチャの透明性 (Architecture transparency)

アーキテクチャのドキュメントをクリアにし、コンポーネントや上記のすべてのテストレベルの観測性、制御性のインターフェースを理解できるようにする

2.1.2 さまざまな環境でテスト自動化がどのように活用されるか

さまざまなタイプのテスト自動化がさまざまな環境で実行される。
プロジェクトや開発手法によって環境は異なり、一つのプロジェクトで複数のテスト環境をもつことがある。技術的視点で、コンテナや仮想化などを持ちいて作成される。

ローカル開発環境

ソフトウェアを最初に開発して、コンポーネントを自動化を用いてテストを行い機能適合性を検証する。
いくつかのテストタイプが行われる。コンポーネントテスト、GUIテスト、APIテストなどである。
重要なこととして、IDEを使用し、ホワイトボックステストを実行してコード品質問題を早期に発見することである。

ビルド環境

主目的はソフトウェアをビルドし、テストを実行してDevOpsエコシステムでビルド結果の正確性を確認します。
また、ローカル開発環境かCI/CDエージェント、つまりコンポーネントテストや統合テストといった低レベルのテストを行う環境、になりうる。そして静的解析が実際のデプロイなしで実行される。

統合環境

低レベルテストや静的解析実行後、次のステージはシステム統合環境である。
SUTのリリース候補がテスト済みの他のシステムと統合されている。
この環境で、テスト自動化スイート、UIテスト、APIテストが実行される。
ここではホワイトボックステストは行わず、ブラックボックステストを行う。
SUT利用中になにが起きているかをモニタリングする最初の環境であり、効率的な欠陥・障害調査を可能にする

プリプロ環境

非機能品質のテストに使われる。
非機能テストはどの環境でもできますが、本番に近いプリプロで行われる。
また、受け入れテストが事業関係者で行われ、最終プロダクトを検証する。
必要に応じてテスト自動化も実行できる。

本番環境

ユーザーがさわり、機能品質、非機能品質をリアルタイムで評価する。
この環境で、モニタリングや特定のベストプラクティスを用いて本番でのテストを可能にしている。
例えば、カナリアリリース、ブルーグリーンデプロイメント、ABテスト

2.2 正しいツールや戦略を選ぶ評価プロセス

2.2.1 SUTを分析し、ふさわしいTAS (テスト自動化ソリューション)を決める

SUTはそれぞれ異なるものである。さまざまな要素、特徴があり、それらを分析できればTASの成功に導く。
SUT調査で、TAE達は範囲と機能を考慮して、要件を収集する必要がある。
さまざまなアプリケーション、WEBサービス、モバイル、WEBは、技術視点から異なるテスト自動化を必要とする。
調査は、利害関係者、手動テスターやビジネス関係者、ビジネスアナリストたちと協力することが推奨されていて、できる限り多くのリスクや緩和策を認識し、将来には有益なテスト自動化を持つことができる。

テスト自動化アプローチとアーキテクチャの要求として以下のようなものがある

どのテストプロセスを自動化するか（テスト管理、設計、生成、実行など）
どのテストレベルをサポートするか（単体、結合、システムテストなど）
どのテストタイプをサポートするか（機能テスト、非機能テストなど）
どのテストロール、スキルセットをサポートするか（TAE,マネージャ、手動テスターなど）
どのソフトウェアプロダクト、プロダクトライン、プロダクトファミリーをサポートするか（TASの期間やライフタイム）
TASと互換のある、どの種類のSUTか
テストデータの可用性と品質
到達不可能なケースのエミュレートする可能な方法（3rd partyアプリケーション）

2.2.2 ツール評価の技術的な発掘

SUTを分析し、関係者の要求が収集され、この要件を満たすテスト自動化を考慮する。
この要件を満たすのは単一ツールではないかもしれない。関係者はこの可能性を認識すべきである。
これは、可能なツール調査結果を集め、比較表にまとめること役立つ。
比較表は関係者がツールの違いを見ることができる。
比較表はツールを列にリストし、要求を行にリストする。
セルは特性と要件に関する情報、優先度を記載する

一般に、テスト自動化ツールは、評価され、要件を満たすかどうかを決める。
評価、比較するときの要件に含まれるものは以下のとおりです

ツールの言語や技術、IDE
ツール設定の能力、異なるテスト環境をサポートするか、実行設定、動的・静的設定値がサポートするか
ツール内でテストデータ管理できる機能。テストデータ管理はバージョン管理のセントラルレポジトリで統合されている時もある
異なるテストタイプのため、さまざまなテスト自動化ツールが選択される必要がある
レポート機能の提供。プロジェクトのレポート要件と一致することが重要
他のツールと連携できる機能。例えばCI/CDやタスクトラッキング、テスト管理、レポートなどである。
テストアーキテクチャの拡張可能性と拡張性、保守性、変更可能性、互換性、信頼性の評価

このような比較表は、ツール選定に良い情報源になる。
どのツールにするかの判断プロセスは異なるが、提案は関係者にデモをするべきです

3 テスト自動化アーキテクチャ (TAE)

3.1 テスト自動化で活用される設計概念

3.1.1 テスト自動化アーキテクチャの主要な機能

Generic Test Automation Architecture (gTAA)

gTAAはハイレベルな設計コンセプトで、テスト自動化と連携するシステムとの通信を抽象的に示したものである。例えば、SUT、プロジェクト管理、テスト管理、構成管理である。
また、TAA設計にカバーする機能ももつ。

gTAAのインターフェースには以下のようなものがある

SUTとTAFとの接続に関するSUTのインターフェース
テスト自動化の開発進捗に関するするプロジェクト管理インターフェース
テストケースとテスト自動化ケースとのマッピングに関するするテスト管理インターフェース
CI/CDパイプラインや環境、テストウェアに関する構成管理インターフェース

テスト自動化ツールやライブラリで定常される能力

コアなテスト自動化の能力はプロジェクトに合わせた利用可能なツールから選定させるべきである

テスト生成 (Test Generation)

テストモデルに基づいたテストケース　のテスト自動化設計をサポートする。
モデルベースドテストツールは生成プロセスで活用される。
この機能はオプションである

テスト定義 (Test Definition)

テストケースやスイートの定義、実装をサポートする。
テストモデルから派生することもできる。
テスト定義は、s UTやテストツールから分離され、ハイレベルテストとローレベルテストを定義することを含み、テストデータ、テストケース、テストライブラリ、そしてこれらの組み合わせで処理される。

テスト実行 (Test Execution)

テスト実行やロギングをサポートする。
選んだテストを自動実行させるテスト自動化ツールや、テストロギング、レポートを提供する。

テスト適合 (Test Adaption)

SUTの色々なコンポーネント、インターフェースに対して自動化されたテストを適合させる機能を提供する。
API、プロトコル、サービスを通してSUTに接続する色々なアダプタを提供する。

3.1.2 テスト自動化ソリューション(TAS)の設計

SUTの機能、非機能、技術的要件を理解や、解決に必要なツールによって、TASは定義される。
TASは商用、もしくはOSSにより実装され、必要に応じてSUT固有のアダプタを追加することになる。

TAAはTAS全般の技術設計を定義する。
TAAは以下のことに対応する

テスト自動化ツールやツール固有のライブラリの選択
プラグインやコンポーネントの開発
接続性とインターフェース要件を特定する（ファイアウォール、データベース、統一リソースロケータ（URL）/接続、モック/スタブ、メッセージキュー、プロトコルなど）
テスト管理、不具合管理ツールへの接続
バージョン管理システムとリポジトリの活用

3.1.3 TAF(テスト自動化フレームワーク)のレイヤー化

TAF

TAFはTASの基礎である。しばしば、テストハーネスを含み、テストランナーやテストライブラリ、テストスクリプト、テストスイートとして知られる。

TAF Layer

TAF Layerは、テストケース、テストレポート、テストログ、暗号化、およびテストハーネスなど、類似の目的を持つクラスの明確な境界を定義します。
各目的ごとにレイヤーを導入すると、設計が複雑になる可能性がある。
したがって、TAFレイヤーの数を少なくすることが推奨される。

テストスクリプト

目的は、テストケースのリポジトリとテストスイートの注釈を提供する。
これは、ビジネスロジック層のサービスを呼び出し、テストステップ、ユーザーフロー、またはAPI呼び出しを含むことがある。
ただし、テストスクリプトからコアライブラリへの直接呼び出されない。

ビジネスロジック

すべてのSUT依存ライブラリはこのレイヤーに保存される。
これらのライブラリは、コアライブラリのクラスファイルを継承するか、それらが提供するファサードを使用する。
ビジネスロジックレイヤーは、TAFをSUTに対して実行し、追加の設定を行うために使用される。

コアライブラリ

SUTに依存しないすべてのライブラリは、このレイヤーに保存される。
これらコアライブラリは同じ開発スタックを共有する任意のプロジェクトに再利用される。

テスト自動化のスケーリング

下図は、どのようにコアライブラリが複数のTAFの再利用するかを示す。
Project#1は２つのTAFがコアライブラリで構築され、別のプロジェクトはすでにあるコアライブラリを活用し、App #3のTAFを構築する。
一人のTAEはProject#1のTAFを構築してる一方、もう一人のTAEはProject#2のTAFを構築する。

3.1.4 テスト自動化のさまざまなアプローチ

テスト自動化を生成するために、チームはいくつかの開発アプローチから選べる。
これには対話型スクリプト言語やコンパイルされたプログラミング言語が含まれる。
異なるアプローチは自動化のさまざまな利点を提供し、異なる状況で活用できる。
テスト駆動開発（TDD）やビヘイビア駆動開発（BDD）は開発方法論ですが、正しく実践すればテスト自動化の開発につながる。

キャプチャー＆プレイバック

手動で一連操作を行なっているさい、SUTの操作を記録するアプローチである。
これらのツールは記録中にテストスクリプトを生成し、ツールによってはテスト自動化コードを修正することもできる。
コードを出力しないツールはノーコードテスト自動化と呼ばれ、一方コードを出力するものはローコードテスト自動化と呼ばれる。

メリット

初期設定、利用が簡単

デメリット

保守、スケール、進化が難しい
テストケースを記録するとき、」SUTが利用可能である必要
小さい規模でSUTが滅多に変わらない時に適用できる
記録されたテスト実行は、記録したときのSUTのバージョンに蜜に依存する
既存のビルドブロックを再利用せず、個々に記録するため、非常に時間を浪費する

線形スクリプティング

TAEがカスタムテストライブラリを作成しないプログラミングで、テストスクリプトの作成と実行に用いられる。
TAEはキャプチャー＆プレイバックで記録されたテストスクリプトを活用し、修正する。

メリット

設定、テストスクリプを開始が簡単
キャプチャ＆プレイバックに比較して、テストスクリプトの修正が簡単

デメリット

保守、スケール、進化が難しい
テストケースを記録するとき、」SUTが利用可能である必要
小さい規模でSUTが滅多に変わらない時に適用できる
キャプチャ＆プレイバックに比較して、プログラミング知識が必要

構造化スクリプティング

テストライブラリを用いて、要素、テストステップ、ユーザージャーニーを再利用する
プログラミング知識が必要でテストケースの作成、保守を行うアプローチ。

メリット

保守、スケール、移植、適応、進化が簡単
ビジネスロジックとテストケースを分離できる

デメリット

プログラミング知識が必要
TAF開発への初期投資がかかり、テストウェアの定義に時間がかかる

テスト駆動開発 (TDD)

SUTの新しい機能を実装する前に、テストケースは開発プロセスの一部として定義される。
TDDアプローチはテスト、コード、リファクタリングもしくは、レッド、グリーン、リファクタリングのサイクルである。
開発者は失敗するテストケースをまず作成する。（レッド）
開発者は機能を開発し、テストケースを満たす（グリーン）
コードをリファクタリングし、最適化し、クリーンコード原理に従う。
次のテスト、次の機能追加でこのプロセスを続ける

メリット

コンポーネントレベルのテストケースの簡略化
コード品質と構造の改善
テスタビリティの向上
目標のコードカバレッジの達成を容易にする
上位のテストレベルへの不具合伝搬を減らす
開発者、ビジネス担当、テスター缶のコミュニケーションの改善
GUIテストやAPIテストで検証されないユーザーストーリーがTDDに従うことでクライテリアにすぐに達成することができる

デメリット

TDDに慣れるのに時間がかかる
正しく実践しないと、コード品質に対して間違った自信を持ってしまう

データ駆動テスト (DDT)

DDTは構造スクリプティングをもとに構築される。
テストスクリプトはテストデータと共に提供される。
同じテストスクリプトを異なるテストデータを用いて何回も実行ができる。

メリット

迅速、簡単にテストケースの拡張ができる
新しいテスト自動化を追加するコストを大幅に減らす
テストアナリストはテストで定義された一つもしくは多くのテストデータを集めることでテスト自動化を記述することができる。これは、テクニカルテストアナリストに依存しないで作成することができる。

デメリット

適切なテストデータ管理が必要になる

キーワード駆動テスト (KDT)

テストケースは、キーワードとテストデータから派生したテストステップのリスト、テーブルで構成される。
キーワードはユーザー視点から定義される。
この技術はDDTをもとになる

メリット

テストアナリストやビジネスアナリストはテスト自動化のケース作成に関わることができる
テスト自動化から独立した手動テストにも使われる

デメリット

キーワードの実装、保守は複雑で、TAEがカバーしないといけない。スコープが広くなると、難易度が増す
小さなシステムでも多くの作業が発生する

振る舞い駆動開発 (BDD)

BDDは自然言語を活用し、受け入れ基準を形式化し、テスト自動化のケースに使われ、機能ファイルに保存される。
BDDツールはこの言語を理解して、テストケースを実行することができる

メリット

開発者とビジネス担当者、テスターとのコミュニケーションが改善する
自動化されたBDDシナリオはテストケースとして働き、仕様のカバレッジを確保する
BDDはテストピラミッドの異なるレベルの複数のテストタイプを生成するのに使われる

デメリット

追加のテストケース、特にネガティブ、エッジケースが必要になる。テストアナリストやTAEが特にこれらを担当する
多くのチームがBDDがテストケースを書く唯一の方法と誤解し、ビジネス担当者や開発者が協力できないことがある
自然言語のテストステップの改善、保守がTAEにとって複雑になる
過度に複雑なテストステップはデバッグが難しく、コストフルなものになる

3.1.5 テスト自動化の設計原則と設計パターン

テスト自動化はソフトウェア開発である。
そのため、設計原則やパターンはTAEにとってソフトウェア開発者と同様に重要です。

オブジェクト指向プログラミング

４つの原則がある。

カプセル化　：　クラス内のデータとコードを隠蔽し、外部からアクセスできないようにする

抽象化　：　詳細を隠蔽し、必要な情報だけを公開する

継承　：　既存のクラスから新しいクラスを作成する原則で、コードの再利用性を高める

多様性　：　同じインターフェースを持つ異なるクラスのオブジェクトを同じ方法で操作できる

SOLID

５つの原則から成り立つ。コードの可読性や保守性、拡張性に役立つ。

単一責任の原則 (Single Responsibility Principle)　：　クラスは1つのことを行い、変更の理由も1つだけであるべき。この原則に従うことで、コードの互換性やバージョン管理が向上する。

オープン・クローズドの原則 (Open-Closed Principle)　：　既存のクラスを変更せずに新しい機能を追加できるようにする原則。拡張しやすく、修正は中に留める。

リスコフの置換原則 (Liskov Substitution Principle)　：　派生クラスは基底クラスと同じように振る舞い、置換可能である。

インターフェース分離の原則 (Interface Segregation Principle)　：　クライアントは必要なインターフェースのみを実装できるようにする原則。不要なメソッドを持たないインターフェースを設計する。

依存性逆転の原則 (Dependency Inversion Principle)　：　高レベルのモジュールは低レベルのモジュールに依存すべきではなく、両者は抽象に依存すべき。

設計パターン

色々な設計パターンがある。

Facade パターン　：　Facadeパターンは、実装の詳細を隠蔽し、テスターがテストケースを作成するために必要な部分だけを公開する。テストケース内で必要な操作だけをシンプルに公開することで、テストの可読性と保守性を向上させます。

Singleton パターン　：　Singletonパターンは、SUT（System Under Test）と通信する唯一のドライバーが存在することを保証するためによく使用される。シングルトンは、アプリケーション内で唯一のインスタンスを提供するために使用される

Page Object Model (POM) パターン　：　POMは、テスト自動化において非常に重要なパターンです。POMでは、クラスファイルを作成し、それを「ページモデル」と呼びます。SUTの構造が変更されても、テスト自動化エンジニアはページモデル内のロケーターを更新するだけで済みます。各テストケースのロケーターを更新する必要はなくなる。

Flow Model パターン　：　Flow Modelパターンは、Page Object Modelの拡張です。ページオブジェクトモデルの上に追加のファサードを導入し、ページオブジェクトと対話するすべてのユーザーアクションを格納する。ダブルファサードデザインを導入することで、Flow Modelパターンは抽象化と保守性を向上させ、テストステップを複数のテストスクリプトで再利用できるようにします。

続く