JSTQB テスト自動化エンジニア v2016 要約・意訳

Last updated at 2024-10-10Posted at 2024-10-10

はじめに

「JSTQB Advanced Level シラバステスト自動化エンジニア Version 2016.J01」

上記を箇条書きに整理した結果です。文章体が苦手なので。

注意

意訳や省略、誤訳(?)の修正など、原本と異なる箇所が多いので、ご注意下さい
学習内容以外の部分は割愛しています
このシラバスには新しいバージョンがあります

0. イントロダクション

0.7 用語、定義、頭字語

一般

SUT: System Under Test / テスト対象システム
- テスト対象も参照のこと
GUI: Graphical User Interface / グラフィカルユーザーインターフェース
UI: User Interface / ユーザーインターフェース

固有

gTAA: generic Test Automation Architecture / 汎用テスト自動化アーキテクチャ
- テスト自動化ソリューションの全体概要を提供する
TAA: Test Automation Architecture / テスト自動化アーキテクチャ
- gTAAを具体化したもの
- TASのアーキテクチャを定義する
TAS: Test Automation Solution / テスト自動化ソリューション
- TAAを具体化/実装したもの
- テストハーネスやテストライブラリなどの成果物を含む
TAF: Test Automation Framework / テスト自動化フレームワーク
- テスト自動化に必要な環境
- テストハーネスやテストライブラリなどの成果物を含む

役割

TAM: Test Automation Manager / テスト自動化マネージャー
- TASの開発と進化の計画および監督についての責任者
TAE: Test Automation Engineer / テスト自動化エンジニア
- 成果物であるTASの実装、保守、技術改善を含むTAAの設計についての責任者

1. テスト自動化の概要と目的

1.1 テスト自動化の目的

テスト自動化（自動テスト実行を含む）とは

専用ソフトウェアツールを使用してテストの事前条件を制御および設定する
テストを実行する
実行結果と期待結果を比較する
異なるSUTバージョンや環境で多くのテストケースを一貫性をもって繰り返し実行することに役立つ
人手を介さずにテストスイートを実行するメカニズムだけにとどまらない

テスト対象システム（SUT）との分離

TASとSUTを分離し、依存関係を最低限にとどめる
- 組込みシステムなどの場合、テストに用いるソフトウェアをSUTに導入しなければならない

テスト自動化が包含する設計プロセス

ソフトウェア
文書
テストケース
テスト環境
テストデータ

テストウェアが必要とするテスト活動

自動テストケースの実装
自動テスト実行の監視、制御
自動テスト結果の解釈、報告、記録

SUTへのアプローチ

SUTのクラス、モジュール、ライブラリの公開インターフェースを使用したテスト
- ex. APIテスト
SUTのユーザーインターフェースを使用したテスト
- ex. GUIテスト、CLIテストなど
サービスやプロトコルを使用したテスト

テスト自動化の目的

テストの効率性の向上
機能カバレッジの拡大
総テストコストの削減
手動テスト担当者が行えないテストの実施
テスト実行期間の短縮
テスト実行頻度の向上、テストサイクルに要する時間の短縮

テスト自動化の利点

より多くのテストのビルド毎の実行
手動では行えないテストの作成・実行
- リアルタイム、リモート、並列テスト
手動より複雑なテストの実行
テスト実行の高速化
オペレーターのミスによるテスト結果への影響を低減
より効果的・効率的にテストリソースを使用する
ソフトウェア品質に関するフィードバックの迅速化
システムの信頼性向上（再現性、一貫性など）
テストの一貫性の向上

テスト自動化の欠点

コスト
- 追加コストが必要
- TASのセットアップのための初期投資
- 継続的なTASの保守が必要
スキル
- 追加技術が必要
- チームに開発と自動化のスキルが必要
テスト
- 目的から逸脱するリスク
  - 例えば、テストの実行を犠牲にしてでも、テストケースの自動化に集中する
- 複雑になる
- 新たなエラーが引き起こされるリスク

テスト自動化の制限

すべての手動テストを自動化できない
チェックできるのは
- ツールが解釈できる結果のみ
- あらかじめ定義された期待結果によって検証可能な実行結果だけである
探索的テストは自動化できない

1.2 テスト自動化の成功要因

（重要）プロジェクトを開始する前に、成功する可能性を分析する。

成功要因の数が多いほど、テスト自動化プロジェクトが成功する可能性も高くなる
要因をすべて満たさなくてよい
長期的なプロジェクトの成功への影響に主眼を置く
- パイロット段階の成功に影響を与える要因は考慮していない

テスト自動化アーキテクチャ（TAA）

対象ソフトウェア製品のアーキテクチャと非常に密接に関連している。

サポートする機能要件と非機能要件を明確にする（最重要）
TAAは保守性、性能、習得性を考慮して設計される
SUTのアーキテクチャを理解しているソフトウェア技術者を関与させる

SUTの試験性

自動テストがしやすい設計

GUIテストの場合
- できる限り多くのGUI操作やデータをGUI画面構成から切り離す
APIテストの場合
- 公開されたクラス、モジュール、コマンドラインインターフェース数を増やす

自動テストの実装のしやすさ

テスト可能なパーツを最初のターゲットにする
簡単に自動テストできるモジュールまたはコンポーネントを特定する

テスト自動化戦略

現実的で一貫性のあるテスト自動化戦略では、SUTの保守性と一貫性に対応する。

SUTの新規・既存部分の両方に、同じ自動化戦略を適用できない場合がある
コードのさまざまな部分にそれを適用することのコスト、利点、リスクを考慮する
UIとAPIテストの両方を自動化する場合、その結果の一貫性について考慮する

テスト自動化フレームワーク（TAF）

使いやすく、ドキュメントが充実しており保守性の高いテスト自動化フレームワーク（TAF）を維持することにより、自動テストに対して一貫性のあるアプローチをとることができる。

レポート機能を実装する:

品質情報を提供する
- 成功/失敗/エラー/未実行/異常終了、統計情報など
品質概要を把握する
- ステークホルダー向け
  - テスト担当者、テストマネージャー、開発担当者、プロジェクトマネージャーなど

簡単なトラブルシューティングを可能にする:

失敗したテストのトラブルシューティングを行う簡単な方法を提供する

テストが失敗する理由
- SUTで見つかった故障
- TASで見つかった故障
- テスト自身またはテスト環境の問題

テスト環境に適切に対応する:

テストツールはテスト環境の一貫性に依存する
自動テストには専用のテスト環境が必要である
テスト環境やテストデータをまったく制御できない場合、テスト実行の要件を満たさず、誤った実行結果の生成につながる可能性がある

自動テストケースを明文化する:

テスト自動化の目的
どの部分をどの程度テストするか、どの属性（機能および非機能）をテストするか文書化する

自動テストをトレースする:

テスト自動化エンジニアがテストケースの個々のステップをトレースできる

簡単な保守を実現する:

保守がテスト自動化作業の大部分とならないようにする
保守作業はSUTに対して行う変更の規模に比例させる
ケースを簡単に分析、変更、拡張できる
自動化テストウェアを頻繁に再利用し、変更が必要になる項目数を最小限に抑える

自動テストを最新の状態に保つ:

新しい要件や変更された要件によってテストやテストスイート全体が失敗した場合は、失敗したテストを無効にするのではなく、修正する

導入の計画を立てる:

テストスクリプトを簡単に導入、変更、再導入できる

必要に応じてテストを削除する:

自動テストスクリプトが不要になった場合、簡単に削除できる

SUTの監視と復旧を行う:

継続的に実行するためには、SUTを継続的に監視する
SUTで致命的なエラー（クラッシュなど）が発生した場合
- エラーから回復し、問題のあるテストケースをスキップして、次のケースからテストを再開できる

（最重要）テスト自動化コードの保守性

煩雑になる可能性があり、テスト用のコードの量がSUTのコードと同程度の量になることも珍しくない
使用されるテストツール、検証の種類、保守しなければならないテストウェア成果物の違いにより変わる
- テスト入力データ、テストオラクル、テストレポートなど

行うべきでない事項

インターフェースの影響を受けやすいスクリプトを作成しない

グラフィカルインターフェースやAPIの重要でない部分の変更による影響を受けるスクリプト

データの変更による影響を受けやすい、または特定のデータ値に大きく依存するテスト自動化を行わない

他のテスト出力に依存するテスト入力など

コンテキストの影響を受けやすい自動化環境を作成しない

オペレーティングシステムの日付や時刻、言語
別のアプリケーションのコンテンツなど
環境を制御できるように、必要に応じてテスト用のスタブを使う

2. テスト自動化の準備

2.1 テスト自動化に影響するSUT要因

SUTの状況や環境を評価する
要因を特定して適切な対応をとる

SUTインターフェース

自動化したテストケースは、SUTでのアクションを呼び出す

SUTを制御できるインターフェースをSUTが提供する
UIコントロールで実現できる
より低レベルなソフトウェアインターフェースでも実現できる
通信レベルでのインターフェースを通したコミュニケーションも可能である
- TCP/IP、USB、独自のメッセージングプロトコルなど

SUTの分割により、異なるテストレベルに対して実現可能になる

SUTのサポートにより、特定のレベルに対して実現可能になる
- コンポーネントレベル、システムレベルなど
ユーザーインターフェースが存在しない場合
- 別のソフトウェアインターフェースが利用できる必要がある
  - テストフックとも呼ばれる
    -独自のカスタマイズが必要になることもある

サードパーティ製ソフトウェア

サードパーティが提供するソフトウェアを含み、自動テストが必要になる場合
- APIの使用など、別の自動化ソリューションが必要になる可能性がある

干渉のレベル

アプローチが異なる場合、干渉のレベルも異なる
SUTに対する変更の数が多い場合、干渉のレベルも高くなる
既存のUI要素を使う場合、干渉のレベルは低くなる
専用のソフトウェアインターフェースを使う場合、干渉のレベルが高くなる
SUTのハードウェア要素を使う場合、干渉のレベルがさらに高くなる
- キーボード、スイッチ、タッチスクリーン、通信インターフェースなど

干渉のレベルが高いことによる問題は、誤警告のリスクである

テストの干渉のレベルが高い場合、失敗を示したとしても、稼働環境で同様の事象が発生する可能性は低い
高い干渉のレベルで行うテストほど、テスト自動化のアプローチとして簡単な解決策となる

異なるSUTアーキテクチャ

異なるテスト自動化ソリューションが必要になる場合がある
- 例
  - COMテクノロジーを使うC++で書かれたSUT
  - Pythonで書かれたSUT
異なるアーキテクチャを同じテスト自動化戦略で扱う場合
- 両方をサポートしたハイブリッド戦略が必要になる

SUTのサイズと複雑度

現在のSUTのサイズと複雑度を考慮して、今後の開発計画を立てる。\
小さく単純なSUT
- 複雑で非常に柔軟度の高いテスト自動化アプローチは適さない
- 単純なアプローチの方が適している
大規模で複雑なSUT
- 小さく単純なアプローチを用いるのは賢明でない
- ただし、小さく単純なものから始めるのが適切な場合もある
  - しかし、これは一時的なアプローチとすべきである
いくつかの要因は、SUTが利用できるようになってから明らかになる
- サイズと複雑度、利用できるソフトウェアインターフェースなど

テスト自動化の開発はSUTが利用可能になる前に開始すべきである

SUTがまだ存在しない場合でも、テスト自動化計画を開始することができる。

必要なソフトウェアインターフェースを指定することもできる
要件（機能または非機能）がわかっている場合
- その要件とそれをテストする手段から自動化の候補を選定できる
- 自動化の計画はその候補から始まる
- 自動化要件の特定やテスト自動化戦略の決定も含まれる
アーキテクチャと設計が作成されている間
- テストをサポートするソフトウェアインターフェースの設計に着手できる

2.2 ツールの評価と選定

テスト自動化マネージャー（TAM）
- ツールの選定・評価プロセスの責任者
テスト自動化エンジニア（TAE）
- TAMへの情報提供、評価・選定作業の実施

TAEが中心に行う作業

目的やプロジェクトの制約に対するツール情報の分析
適切なツールの推薦
組織の成熟度評価・テストツールのサポート体制の評価
期待するテストツールのサポートに関する適切な評価
候補ツールの情報収集・選定
ツールとSUTコンポーネントとの互換性の判断
具体的なビジネスケースに基づく費用対効果の見積り

ツールの問題事例

ツールが想定や状況のすべてを満たせるわけではない。

テスト自動化ツールのインターフェースが、既に導入されている他のツールと連携しない

例
- テストマネジメントツールがアップデートされ、接続インターフェースが変更された
- プリセールスサポートの情報が誤っており、レポートツールに転送できない情報がある
解決策
- アップデートの前に注意してリリースノートを確認し、大規模な移行の場合は本番環境に移行する前にテストを行う
- 実際のSUTを使ったツールのデモをオンサイトで行わせる
- ベンダーやユーザーコミュニティフォーラムによるサポートを検討する

一部のSUTの依存性が変更され、テストツールがサポートしないものが含まれるようになった

例
- 開発部門が最新バージョンの Java にアップデートした
解決策
- 開発環境/テスト環境とテスト自動化ツールでアップグレードを同期する

GUIのオブジェクトがキャプチャできない

例
- オブジェクトは表示されているが、テスト自動化ツールから操作できない
解決策
- 開発の際には、よく知られている技術やオブジェクトのみを使用するよう心がける
- テスト自動化ツールを購入する前にパイロットプロジェクトを行う
- 開発担当者にオブジェクトの標準を定義させる

ツールが非常に複雑に見える

例
- ツールには大量のフィーチャーセットがあるが、その一部しか使う予定がない
解決策
- ツールバーから不要な機能を削除してフィーチャーセットを制限する方法を探す
- ニーズを満たすライセンスを選択する
- 必要なフィーチャーに特化した別のツールを探す

他のシステムと競合する

例
- 他のソフトウェアをインストールすると、テスト自動化ツールが動作しなくなる
  - またはその逆
解決策
- インストール前にリリースノートや技術要件を読む
- サプライヤーから他のツールに影響がないことを確認する
- ユーザーコミュニティフォーラムに質問する

SUTへの影響

例
- テスト自動化ツールの使用中または使用後に、SUTの反応が変わる
  - 応答時間が長くなるなど
解決策
- SUTを変更する必要がないツールを使用する
  - ライブラリのインストールなど

コードへのアクセス

例
- テスト自動化ツールがソースコードの一部を変更する
解決策
- ソースコードを変更する必要がないツールを使用する
  - ライブラリのインストールなど

リソースの制限（主に組込み環境）

例
- テスト環境の空きリソースが限られているか、リソースが枯渇している
  - メモリなど
解決策
- リリースノートを読み、ツール開発元と話し合い、環境が問題につながらないことを確認する
- ユーザーコミュニティフォーラムに質問する

アップデート

例
- アップデートですべてのデータが移行されない
- 既存の自動テストスクリプトやデータ、構成が破損する
- アップグレードに別の（よりよい）環境が必要
解決策
- テスト環境でアップグレードのテストを行い、開発元から移行が問題なく行えることを確認する
- アップデートの前提条件を読み、アップデートする価値があるかを判断する
- ユーザーコミュニティフォーラムによるサポートを求める

セキュリティ

例
- テスト自動化ツールを使うにあたり、テスト自動化エンジニアに提供されていない情報や権限を必要とする
解決策
- テスト自動化エンジニアにアクセス権を与える必要がある

異なる環境やプラットフォームでの互換性がない

例
- テスト自動化がすべての環境やプラットフォームで動作するとは限らない
解決策
- ツールの独立性を最大限にするように自動テストを実装し、複数のツールを使うことによるコストを最小限に抑える

2.3 試験性と自動化を考慮した設計

SUTの試験性は他のフィーチャーの設計や実装と並行して設計、実装すべきである。

SUTの制御や観測を可能にするなど、テストをサポートするソフトウェアインターフェースの可用性
試験性はシステムの非機能要件の 1 つにすぎない
- 試験性の設計、実装はソフトウェアアーキテクトが行える
TAE自身が行うか、TAEが関与して行う

試験性を考慮した設計

優れたテスト自動化アプローチにとって最重要であり、手動テスト実行の場合にもメリットになる場合がある。

観測性:

SUTは、システムの内部を把握できるインターフェースを提供する
テストケースはそのインターフェースを使い、意図した振る舞いと実際の振る舞いが等しいかどうかなどをチェックする

制御性:

SUTは、SUTを操作するインターフェースを提供する
- UI要素、関数呼び出し、通信要素（TCP/IP、USBプロトコルなど）、電気信号（物理スイッチ）など

明確に定義されたアーキテクチャ

すべてのテストレベルにおいて制御と可視性を実現し、明確でわかりやすいインターフェースを提供するアーキテクチャである

TAEの役割

自動テストを含めたSUTのテスト方法を検討する

効果的：適切な領域をテストして重大なバグを見つける
効率的：大量の作業を発生させない

特定のソフトウェアインターフェースの必要を明示する

常にそれを明示し、開発担当者が実装しなければならない
- これは試験性を定義するために重要である
必要に応じて開発作業の予定を立てて予算を確保できるようにする
- プロジェクトの早い段階で追加のソフトウェアインターフェースを定義する際に重要になる

テストをサポートするソフトウェアインターフェースの例

最新のスプレッドシートによる強力なスクリプト機能
スタブまたはモックを適用してシミュレートすることにより、実際のインターフェースが存在しないソフトウェアのテストが可能になる
- まだ入手していないソフトウェアやハードウェア、高価すぎて購入できないソフトウェアやハードウェア
- 電子金融取引、ソフトウェアサービス、専用サーバー、電子基板、機械部品など
ソフトウェアインターフェース（スタブおよびドライバ）を使ってエラー条件をテストすることが可能である
- 例
  - 内部ハードディスクドライブ（HDD）を搭載したデバイスがある
    - HDDを制御するソフトウェア（ドライバと呼ばれる）には、HDDの故障や摩耗に対するテストを行える必要がある
    - これを行うために HDDが故障するのを待つのは、効率のよい（あるいは信頼性が高い）方法ではない
  - HDDの欠陥や遅延をシミュレートするソフトウェアインターフェースを実装すれば
    - ドライバソフトウェアが正常に動作すること（エラーメッセージ、リトライなど）を検証できる
利用できる UIがまだ存在しない場合
- 別のソフトウェアインターフェースを使ってSUTをテストできる
- UIを使うよりも優れたアプローチだと見なされることが多い
- 例
  - 組込みソフトウェアは、デバイスの温度を監視し、温度が一定レベルを超えたときに冷却機能を起動する必要がある
  - 温度を指定するソフトウェアインターフェースを使えば、ハードウェアがなくてもテストできる
SUTの状態の振る舞いを評価する場合
- 状態遷移テストが使われる
- SUTが正しい状態にあるかどうかをチェックする場合
  - この目的を実現するためにカスタマイズされたソフトウェアインターフェースを経由して問い合わせる

自動化の設計で考慮すべき事項

テストツールとの互換性
- 早い段階で確立すべきである
- 重大な問題である
- 重要な機能のテストの自動化可否に影響する可能性がある
- 例
  - グリッドコントロールと互換性がない場合、そのコントロールを使うすべてのテストができなくなる
プログラムコードの開発やAPIの呼び出しが必要な解決策もある

3. 汎用テスト自動化アーキテクチャ

3.1 gTAAの概要

テスト自動化エンジニア（TAE）の役割

テスト自動化ソリューション（TAS）の設計、開発、実装、保守である

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

各ソリューションの開発にあたっては、繰り返し発生する以下のような概念、手順、アプローチが基本となる
- 同じようなタスクを行う
- 同じような質問に答える
- 同じような問題に優先順位をつけて対処する
gTAAのレイヤー、コンポーネント、インターフェースを表す
特定のTAS向けのTAAとして具体化される

これにより、構造化されたモジュール形式のアプローチを利用して、以下ので

テスト自動化ソリューションを構築方法

内部および外部で開発したコンポーネントによってTASを具体化できるように以下を定義する
- コンセプト
- レイヤー
- サービス
- インターフェース
シンプルなコンポーネントを利用して効果的かつ効率的なテスト自動化を行えるようにする
各種ソフトウェアの製品ラインや製品ファミリー、およびソフトウェア技術やツールが異なるものを含め、別のTASの開発やTASの改良の際にテスト自動化コンポーネントを再利用する
TASの保守や改良を容易にする
TASユーザー用の基本的なフィーチャーを定義する

テスト自動化ソリューション（TAS）の構成

テスト環境（およびその成果物）
テストスイート（テストデータを含む一連のテストケース）

テスト自動化フレームワーク（TAF）

TASを実現するために使用でき、テスト環境の具体化の方法を提供する
- サポート
- ツール
- テストハーネス
- サポートライブラリ

TAAが従うことが推奨される原理

TASを簡単に開発、改良、保守できる。

単一責任:

あらゆるTASコンポーネントは、単一の責任を持たなければならない
また、その責任はコンポーネント内に完全にカプセル化されなければならない
TASのすべてのコンポーネントは厳密に以下の1つのことを担当すべきである
- キーワードやデータの生成
- テストシナリオの作成
- テストケースの実行
- 結果記録
- 実行レポートの生成

拡張性:

ref. B. Myerによるオープン/クローズドの原則など

あらゆるTASコンポーネントは、拡張に対してオープンでなければならないが、変更に対してクローズドでなければならない
この原則は、下位互換性機能に影響を与えずにコンポーネントの振る舞いを変更または強化できる必要があることを意味している

置換:

ref. B. Liskovによる置換原則など

あらゆるTASコンポーネントは、TASの全般的な振る舞いに影響を与えずに置換可能でなければならない
コンポーネントは 1 つまたは複数のコンポーネントで置き換えることができるが、外から見える振る舞いは同じでなければならない

コンポーネントの分離:

ref. R.C. Martin によるインターフェース分離の原則など

汎用的で多目的なコンポーネントよりも、具体的なコンポーネントの方が望ましい
不要な依存性がなくなるので、置換や保守が容易になる

依存性の逆転:

TASのコンポーネントは、低レベルの詳細な部分に対してではなく、抽象的な部分に依存しなければならない
コンポーネントは特定の自動テストシナリオに依存すべきではない

gTAAをベースとしたTAS

一連のツールとそのプラグイン、およびコンポーネントにより実装される
特定のベンダーに依存しないことが重要である
TASを実現するいかなる具体的な手法、技術、ツールも規定しない
任意のソフトウェアエンジニアリングアプローチを使って実装できる
- 構造化、オブジェクト指向、サービス指向、モデル駆動など
任意のソフトウェア技術やツールを使うこともできる
TASは既製のツールを使って実装されるのが一般的である
- 通常はSUTに固有な機能や対応を追加する必要がある

他のガイドラインや参照モデル

指定された SDLC（Software Development LifeCycle）のソフトウェアエンジニアリング標準
プログラミング技術
フォーマット標準

TASの保守性、信頼性、セキュリティの向上

TAE
- ソフトウェアエンジニアリングにおけるスキル、経験、専門性を有していることが求められる
- 業界のコーディング標準やドキュメント標準、ベストプラクティスを認識する
- TASの開発に活用する必要がある

ドメイン特化した標準の例

C または C++ 用の MISRA
- C++ 用の JSF コーディング標準
- MathWorks Matlab/Simulink® 用の AUTOSAR ルール

3.1.1 gTAAの概要

水平レイヤー構造となっている
各レイヤーが存在することもあれば存在しないこともある

テスト生成レイヤー

テストケースの手動または自動での設計をサポートし、テストケースを設計する手段を提供する。

手動設計
テストモデル

テスト定義レイヤー

テストスイートおよびテストケースの定義と実装をサポートする。

ハイレベルおよびローレベルのテストを定義する手段が含まれている
- テスト条件
- テストケース
- テスト手順
- テストデータ
- テストライブラリ
- これらの組み合わせ
SUTやテストシステムの技術およびツールからテスト定義を分離する

テスト実行レイヤー

テストケースとテスト結果記録作業の実行をサポートする。

テスト実行ツール
- 選択されたテストを自動的に実行する
記録およびレポート用のコンポーネント

テスト適合レイヤー

SUTのさまざまなコンポーネントやインターフェースを自動テストに適合させるために必要なコードを提供する。

SUTに接続するための各種アダプターを提供する
- GUI
- API
- プロトコル
- サービス
- データべース
- シュミレータ
- エミュレータ
  など

テスト実行を自動化する場合

テスト実行レイヤーとテスト適合レイヤーを利用する必要がある
この2つを分離する必要はなく、ユニットテストフレームワークなどで同時に実現することも可能である

TASの実装

ほとんどの場合、下から上へ向かって行われる
手動テスト用のテストケースを自動で生成する場合など、他のアプローチも役立つ可能性がある
TASを段階的（スプリントなど）に実装することが推奨される
- できるだけ早くTASを使用してTASの付加価値を証明できる
コンセプトの証明（PoC）を行うことも推奨される

プロジェクト

ソフトウェア開発プロジェクトとして認識、編成、管理する必要がある
専任のプロジェクトマネジメントも必要になる
プロジェクトとして以下は分離できる
- TAF開発
  - 企業全体または製品ファミリーや製品ラインのテスト自動化サポート
- TAS
  - 具体的なプロダクトのテスト自動化

3.1.2 テスト生成レイヤー

構成する支援ツール

テストケースの手動設計
テストデータの作成、キャプチャ、導出
SUTやその環境を定義するモデルからのテストケースの自動生成
- 自動モデルベースドテスト

一般的なコンポーネント

テストスイート構造を編集またはナビゲーションする
テストケースとテスト目的またはSUT要件を関連付ける
テスト設計を文書化する

自動テスト生成に含まれる機能

SUT、SUTの環境、テストシステムをモデル化する機能
テスト方針の定義およびテスト生成アルゴリズムの構成やパラメーター化を行う機能
生成されたテストからモデル（要素）にさかのぼる機能

3.1.3 テスト定義レイヤー

構成する支援ツール

ハイレベル、ローレベルのテストケース定義
ローレベルテストケースのテストデータ定義
単一、一連のテストケースのテスト手順の定義
テストケースを実行するためのテストスクリプトの定義
テストライブラリへのアクセスの提供
- キーワード駆動アプローチの場合など

一般的なコンポーネント

テストデータを分類/制限、パラメーター化、具体化する
テストシーケンスや一連のテストの振る舞い（制御文や式を含む）を明示する
- それらをパラメーター化およびグループ化する
テストデータ、テストケース、テスト手順を文書化する

3.1.4 テスト実行レイヤー

構成する支援ツール

テストケースの自動実行
テストケースの実行結果の記録
テスト結果の報告

一般的なコンポーネント

テスト実行のためにSUTの前処理および後処理をする
テストスイートの前処理および後処理をする
テスト準備の構成および設定を行う
テストデータとテストケースを処理して実行可能スクリプトに変換する
テストシステムやSUTを測定し、テスト実行やフォールトインジェクション（の一部）を記録する
テスト実行中のSUTの結果を分析し、後続のテストの進行を調整する
自動テストケース実行結果についてSUTのテスト結果の妥当性を確認する
- 期待結果と実行結果を比較する
自動テスト実行が時間内に終わるよう制御する

3.1.5 テスト適合レイヤー

構成する支援ツール

テストハーネスの制御
SUTの操作
SUTの監視
SUT環境のシミュレートまたはエミュレート

提供する機能

以下の間を仲介する
- 特定の技術によらないテスト定義
- SUTやテストデバイスに固有の技術要件
SUTと連携するために、さまざまな技術固有のアダプターを適用する
テスト実行を分散する
- 複数のテストデバイスやテストインターフェースに
- またはローカルでテストを実行する

3.1.6 TASの構成管理

さまざまなイテレーションやバージョンで開発され、SUTのイテレーションやバージョンとの互換性が必要となる。

要件

テストモデル
テストデータ、テストケース、ライブラリを含むテストの定義や仕様
テストスクリプト
テスト実行エンジンと補助ツール、補助コンポーネント
SUT用のテストアダプター
SUT環境のシミュレーターやエミュレーター
テスト結果やテストレポート

バージョン管理

SUTのバージョンと一致した正しいバージョンでなければならない
状況によっては以前のTASのバージョンに戻さなければならない場合がある
- 古いバージョンのSUTで現場の問題を再現しなければならない場合など

3.1.7 TASのプロジェクトマネジメント

テスト自動化プロジェクトはすべてソフトウェアプロジェクトである
他のソフトウェアプロジェクトと同じプロジェクトマネジメントが必要になる

TASの開発におけるTAE

確立されたSDLC手法のすべてのフェーズのタスクを行う必要がある
- Software Development LifeCycle
以下のようにTASの開発環境を設計しなければならない
- ステータス情報（メトリック）を容易に抽出できる
- TASのプロジェクトマネジメントに自動的に報告される

3.1.8 TASのテストマネジメントサポート

SUTのテストマネジメントをサポートしなければならない
テスト結果記録やテスト結果を含むテストレポートはいずれかが必要となる
- 抽出が容易である
- SUTのテストマネジメント（人またはシステム）に自動的に提供される

3.2 TAAの設計

3.2.1 TAAの設計の概要

設計には多くの重要な作業が必要になる
テスト自動化プロジェクトや組織のニーズに応じて順位付けする
複雑度により、必要な作業は増減する場合がある

テスト自動化アプローチの要件

テストプロセスのどの作業やフェーズを自動化すべきか
- テストマネジメント
- テスト設計
- テスト生成
- テスト実行
  など
テスト設計とテスト実装の間にテスト生成を挿入することによって基本的なテストプロセスを洗練する
どのテストレベルをサポートすべきか
- コンポーネントレベル
- 統合レベル
- システムレベル
  など
どのタイプのテストをサポートすべきか
- 機能テスト
- 適合テスト
- 相互運用性テスト
  など
テストに関するどの役割をサポートすべきか
- テスト実行者
- テストアナリスト
- テストアーキテクト
- テストマネージャー
  など
どれをサポートすべきか
- 実装されるTASの寿命や存続期間などを定義する
- ソフトウェアプロダクト
- ソフトウェア製品ライン
- ソフトウェア製品ファミリー
どの技術をサポートすべきか
- SUTに使われる技術との互換性を考慮してTASを定義する

アプローチの利点と欠点

異なる設計やアーキテクチャを用いたアプローチと比較、対比を行う。

テスト生成レイヤーの考慮事項:

すべての組み合わせのテストを生成するのは不可能である。
現実的なカバレッジ基準、重み付け、リスクアセスメントなどを参考にする

テスト生成を手動にするか自動にするかの選択
テスト生成の選択
- 要件ベースド
- データベースド
- シナリオベースド
- 振る舞いベースド
  など
テスト生成戦略の選択
- データベースのアプローチのためのクラシフィケーションツリーなどのモデルカバレッジ
- シナリオベースのアプローチのためのユースケース/例外ケースカバレッジ
- 振る舞いベースのアプローチのための遷移/状態/パスカバレッジ
  など
テストの選定戦略の選択

テスト定義レイヤーの考慮事項:

どのテスト定義を利用するかの選択
- データ駆動、キーワード駆動、パターンベースド、モデル駆動
テスト定義の表記法の選択
- スプレッドシート
- ドメインに特化したテスト用の言語
- Testing and Test Control Notation（TTCN-3）
- UML Testing Profile（UTP）などを使用した表
- 状態ベースの表記法
- 確率的表記法
- データフロー表記法
- ビジネスプロセス表記法
- シナリオベースの表記法
  など
スタイルガイドやガイドラインの選択
- 高品質なテストを定義する
テストケースリポジトリの選択
- スプレッドシート
- データベース
- ファイル
  など

テスト実行レイヤーの考慮事項:

テスト実行ツールの選択
どのアプローチを採用するかの選択
- テスト手順を実現する（仮想マシンの使用による）
- 選択されたテスト実行ツールに依存する
- アプローチ
  - インタプリタ型
  - コンパイル型
テスト手順を実装する技術の選択
- 選択したテスト実行ツールに依存する
- 技術
  - C などの命令型
  - Haskell や Erlang などの関数型
  - C++、C#、Java などのオブジェクト指向型
  - Python や Ruby などのスクリプト
  - ツール固有の技術
ヘルパーライブラリの選択
- テスト実行を容易にする
- ライブラリ
  - テストデバイスのライブラリ
  - エンコーディング/デコーディングライブラリ
    など

テスト適合レイヤーの考慮事項:

SUTとのテストインターフェースの選択
テストインターフェースを操作・観測するツールの選択
テスト実行の際にSUTを監視するツールの選択
テスト実行をトレースするツールの選択
- テスト実行のタイミングを含む

TAAの抽象化

メリット

異なるテスト環境や対象技術で同じテストスイートを使えるようになる
テスト成果物の移植性が向上する
- 技術への依存度を軽減できる
TASのロックイン効果を回避できる
- ベンダーへの非依存性が保証される
保守性や新しいSUTに使われる技術およびその変化への環境適応性も向上する
技術者以外がTAA（およびそれをTASとして具体化したもの）を使いやすくすることにもつながる
可読性や理解性が向上する
- テストスイートを文書化（視覚的手段を含む）して高レベルで説明できる

TAEが議論すべき事項

TASのどの領域でどのレベルの抽象化を使用するか
- 対象
  - ソフトウェア開発
  - 品質保証
  - テスト
- インターフェース
  - テスト適合レイヤー
  - テスト実行レイヤー
- どれを外部化するか
- どれを形式的に定義するか
- TAAの存続期間にわたってどの安定性を確保するか
いずれを使うか
- 抽象化したテスト定義
- テスト実行レイヤーでテストスクリプト

TAEが認識すべき事項

どのアプローチを使用してテスト生成を抽象化するか
- テストモデル
- モデルベースドテスト
高度な実装と単純な実装との間にトレードオフがある
- 機能性
- 保守性
- 拡張性

抽象化の結果

進化の余地や新しいアプローチや技術への移行に関する柔軟性が向上する
- 初期投資が増加する
  - テスト自動化のアーキテクチャやツールの複雑度が増す
  - スキルセット要件が高くなる
  - 学習コストが大きくなる
    など
- 最初の損益分岐点に到達するまでの時間が長くなる
- 長期的に見ればそれに見合うだけの成果をあげられる可能性がある
TASのパフォーマンスが下がる場合もある

ROI（投資収益率）

TAM の責任範囲である
TAE は技術的評価や比較を行い、ROI分析に必要な情報を提供する
- アーキテクチャ
- アプローチ
- タイミング
- コスト
- 工数
- 利益

SUTに使われる技術やTASとの関係

SUTのテストインターフェースへのアクセス

ソフトウェアレベル:
- SUTとテストソフトウェアが相互にリンクされる場合など
APIレベル:
- （リモートの）アプリケーションプログラミングインターフェースが提供する関数/操作/メソッドをTASが呼び出す場合など
プロトコルレベル:
- HTTP、TCPなどでTASがSUTと通信する場合など
サービスレベル:
- Web サービスや RESTful サービスなどでTASがSUTのサービスと通信する場合など

TAAの相互作用のパラダイム

TASとSUTが API、プロトコル、サービスで分離され、連携する場合に決定する。
SUTアーキテクチャに依存し、SUTアーキテクチャに影響する。

イベント駆動パラダイム
- 交換されるイベントやイベントバスを通した相互作用を実現する
クライアント/サーバーパラダイム
- サービス要求者がサービス提供者のサービスを呼び出すという相互作用を実現する
ピアツーピアパラダイム
- ピア間での任意の方向のサービス呼び出しによる相互作用を実現する

SUT環境

スタンドアロンソフトウェア
他のソフトウェアとの関係でのみ動作するソフトウェア
- システムオブシステムズなど
ハードウェア
- 組込みシステムなど
環境コンポーネント
- サイバーフィジカルシステムなど

テスト環境の例とサンプル使用の例

TASは、自動テストのセットアップの一環として、SUT環境のシミュレートまたはエミュレートを行う。

SUTとTASの両方の機能を備えたコンピューター
- ソフトウェアアプリケーションのテスト
SUTやTASのそれぞれとネットワークで接続された個々のコンピューター
- サーバーソフトウェアのテスト
SUTの技術的インターフェースを操作および観測する追加のテストデバイス
- セットトップボックスなどのソフトウェアのテスト
SUTの操作環境をエミュレートするネットワーク接続テストデバイス
- ネットワークルーターのソフトウェアのテスト
SUTの物理環境をシミュレートするシミュレーター
- 組込み制御ユニットのソフトウェアのテスト

TASプロジェクトにかかる作業の見積り

TAM の責任範囲である
TAE はTAM を支援する
- TAA設計・実装の時間と複雑度を適切に見積る

見積りの方法

類推による見積り
- ファンクションポイント
- 3点見積り
- ワイドバンドデルファイ
- 専門家による見積り
  など
ワークブレークダウンストラクチャの使用による見積り
- マネジメントソフトウェア
- プロジェクトテンプレート
  など
係数見積り
- Constructive Cost Model（COCOMO）
  など
サイズベースの見積り
- ファンクションポイント法
- ストーリーポイント法
- ユースケース分析
  など
グループ見積り
- プランニングポーカー
  など

TASの使用性

TAEには指定されたテストウェアアーキテクチャ実装の使いやすさの問題に対処する明確な責任がある。

テスト担当者指向の設計
使いやすさ
他の役割への支援
- ソフトウェア開発
- 品質保証
- プロジェクトマネジメント
効果的な編成、ナビゲーション、検索
有用な文書化、マニュアル、ヘルプテキスト
実用的なレポート
フィードバックや経験的洞察に対応するためのイテレーティブ設計
など

3.2.2 テストケース自動化へのアプローチ

テストケース
- SUTに対して実行される一連のアクションに変換するが必要である
アクション
- テスト手順での文書化および/またはテストスクリプトで実装する
自動テストケース
- SUTを操作するためのテストデータの定義を含む
- SUTが期待結果を実現したことを検証する

アプローチの種類

容易な選択肢はより短時間で付加価値を提供できるが、保守性の低いソリューションが生まれる。

直接テストケースを実装する
- 抽象化が不足している
- 保守の負荷が増加する
- 最も推奨されない
テスト手順を設計し、それを変換する
- 抽象化されている
- テストスクリプトを生成する自動化が不足している
ツールを使用してテスト手順を変換する
- 抽象化されている
- 自動テストスクリプト生成も自動化されている
自動テスト手順を生成するツールを使用する、モデルから変換する、またはその両方を行う
- 自動化の成熟度が最も高い

アプローチ方法

種類 1
- キャプチャ/プレイバックアプローチ
種類 2、3
- 構造化スクリプティングアプローチ
- データ駆動アプローチ
- キーワード駆動アプローチ
種類 4
- モデルベースドテスト
  - プロセス駆動アプローチ含む

キャプチャ/プレイバックアプローチ

主な概念
- ツールを使用してSUTとのやりとりをキャプチャしつつ、テスト手順で定義された一連の手順を実行する
- 入力がキャプチャされ、後ほどチェックするために出力も記録される
- 操作を再生する際には出力チェックを行う
  - 手動:
    - テスト担当者がSUTの出力を監視して不正がないかを検出する必要がある
  - 完全:
    - SUTはキャプチャの際に記録されたすべてのシステム出力を再現する必要がある
  - 厳密:
    - 完全 + 詳細のレベルまで記録
  - チェックポイント:
    - ある時点で選択されたシステム出力の指定された値のみがチェックされる
利点
- GUIレベル、APIレベルでSUTに使用する
- 導入初期の段階では、セットアップや使用が容易である
欠点
- キャプチャしたSUT操作はキャプチャ時のSUTのバージョンに強く依存する
  - 保守や進化は難しい
  - GUIレベルの記録は、要素の位置が変更されただけでも、テストスクリプトに影響する可能性がある
- 変更に弱い
- テストケース（スクリプト）の実装を開始できるのは、SUTが利用できるようになってからである

線形スクリプティング

主な概念
- いくつかの手動テスト手順から始まる
- これらは文書化されてない場合もある
- どのテストをどのように実行するかは「暗黙知」である場合がある
  - 1 人または複数人のテストアナリスト
- テストツールが一連の手順を記録する間、各テストは手動で実行される
  - 場合によってはSUTの画面出力を視覚的に記録する
- 1 つのテスト手順につき 1 つの（通常は大きな）スクリプトになる
- 記録されたスクリプトを編集して可読性を向上させられる
  - 重要な場所に何が起きているかのコメントを追加するなど
- ツールのスクリプト言語を使用してさらにチェックを追加できる
- ツールで再生することができる
- 記録時にテスト担当者が行ったのと同じ手順を繰り返す
- GUIテストの自動化に使用できるが、適切な技法ではない
  - ソフトウェアの多くのリリースのために大量のテストを自動化する必要があるような場合
  - SUTの変更に伴う保守コストが高くなる
    - 変更が行われるたびに、記録したスクリプトで多くの部分を変更しなければならない
利点
- 自動化を始めるにあたって必要になる準備作業がまったくあるいはほとんどない
- ツールの使用方法を習得すれば、手動テストを記録して再生するだけで済む
  - テストツールの追加操作を行い、実行結果と期待結果を比較してソフトウェアが正常動作することを検証する
- プログラミングのスキルは必須ではないが、役立つことが多い
欠点
- 多くの欠点がある
- 新しい自動テストを構築するコストを削減できる余地は多くない。
  - テスト手順を自動化するために必要な作業の量は、それを実行するために必要なサイズ（手順の数）に依存する
  - 1000 個目のテスト手順を自動化する際にも、100 個目のテスト手順を自動化するのと同じ作業量が必要になる。
- スクリプトに影響するソフトウェアの変更があった場合、それらすべてを保守する必要がある
  - 入力値が異なる同じようなテストのスクリプトがあった場合、2 つのスクリプトに同じ一連の命令が含まれる
  - 命令に含まれる情報（命令の引数またはパラメーターと呼ばれる）のみが異なる
  - 複数のテスト（すなわち複数のスクリプト）があった場合、すべてに同じ一連の命令が含まれる
- 自然言語ではなくプログラミング言語で書かれているため、プログラマー以外が理解するのは難しい
- 独自の言語を使用するものもあり、言語の学習や習得には時間がかかる
- 記録されたスクリプトは、コメントがもしあれば、その中には通常の文章のみを含む
  - 長いスクリプトでは、テストの各手順で何が起こっているのかを説明するコメントが付いていることが望ましい
  - これにより、保守が容易になる
- テストに多くの手順が含まれる場合、スクリプトはすぐに肥大化する
  - スクリプトに多くの命令が含まれる
- モジュール形式ではないので、保守が難しい
- 一般的なソフトウェアの再利用性やモジュール型パラダイムに準じておらず、使用するツールと密結合である

構造化スクリプティング

主な概念
- 線形スクリプティング技法にスクリプトライブラリを導入している
- 複数のテストで共通して用いられる、一連の命令を実行する再利用可能スクリプトが含まれる
  - SUTインターフェースの操作など
利点
- 保守の際に必要な変更が大幅に削減される
- 新しいテストを自動化する際のコストを削減できる
  - 最初からスクリプトを作成するのではなく、既存のスクリプトを使用できる
- 少ない量のスクリプトで、多くのテストを自動化することができる
  - スクリプト作成と保守のコストに直接的に影響する
- 2つ目以降のテストの自動化には 1 つ目ほど手間はかからない
欠点
- 共有スクリプトを作成する最初の作業は欠点に思われがち
  - この初期投資を適切に行うことができれば、大きな利益となって返ってくる
- プログラミングのスキルが必要になる
- スクリプトを文書化し、必要なスクリプトを容易に見つけられるように適切に管理される必要がある
  - そのため、適切な命名規約が役に立つ

データ駆動テスト

主な概念
- 構造化スクリプティング技法がベースとなっている
- 違いは、テスト入力方法にある
- 入力はスクリプトから切り離され、ファイルに格納される
  - 通常はデータファイルと呼ばれる
- テストスクリプトを再利用して多くのテストを実装できる
- 「再利用可能な」テストスクリプトを「制御」スクリプトと呼ぶ
  - テストを実行するために必要な一連の命令が含まれる
  - 入力データはデータファイルから読み取られる
- 1つの制御スクリプトを多くのテストで使用することも可能である
  - 幅広いテストを自動化するには不十分であることが多い
    ‐ 多数の制御スクリプトが必要になる
  - 自動化するテストの数全体に比べればわずかな数にすぎない
利点
- 新しい自動テストを追加するコストを大幅に削減できる
- テストカバレッジの増加につながる
  - 有用なテストを数多く自動化できる
  - 特定の領域を深くテストすることができる
- テストがデータファイルで「記述」される
  - データファイルを投入するだけで「自動」テストを指定できる
- テストアナリストが自動テストを指定する自由度が増す
- テクニカルテストアナリストへの依存度を低くできる
  - 希少なリソースである可能性がある
短所
- データファイルを管理し、TASが読み取れるようにしなければならない
  - これには適切なアプローチをとることができる
- 否定テストケースが見逃される
  - テスト手順とテストデータの組み合わせである
- テストデータを対象としたアプローチでは、「否定テスト手順」が見逃される

キーワード駆動テスト

主な概念
- データ駆動スクリプティング技法がベースとなっている
  - データファイルは「テスト定義」ファイルと呼ばれる
    - アクションワードファイルなど
  - 制御スクリプトは 1 つしかない
- テスト定義ファイルには同じ内容のデータファイルより簡単に理解できる方法で表現されたテストが含まれる
- データファイルと同じようなデータが含まれるが、キーワードファイルには高レベルな命令も含まれる
  - キーワードまたは「アクションワード」
- キーワードは意味があるものを選択する
  - テストアナリスト、記述されるテスト、テストされるアプリケーションにとって
- キーワード
  - テスト対象システムとのさまざまな相互作用を表す
  - ビジネスとシステムの高位レベルの相互作用を表すために使用する
    - たとえば、注文の実行
  - 配列は、テストケースを指定する
  - 関連するテストデータを含む
  - 検証ステップに特殊なキーワードを使うこともできる
  - 操作ステップと検証ステップの両方を含めることもできる
- テストアナリストの責任範囲には、キーワードファイルの作成と保守が含まれる
- 補助スクリプトが一度実装されれば、キーワードファイルに記述するだけで「自動」テストを追加できる
利点
- 制御スクリプトとキーワード用の補助スクリプトを記述できれば、新しい自動テストを追加するコストを大きく削減できる
- テストがキーワードファイルで「記述」される
  - テストアナリストはキーワードと関連するデータを使用してテストを記述するだけで「自動」テストを作成できる
- テストアナリストが自動テストを作成する自由度が増す
  - （希少なリソースである可能性がある）テクニカルテストアナリストへの依存度を低くできる
- キーワードは、意味のある結果を生成する詳細な一連のアクションを表すものにする
  - 複数の詳細な手順が含まれている
  - 例：オンラインショッピングアプリケーションでのアクション
    - 「アカウントの作成」、「注文の実行」、「注文ステータスのチェック」
- 高レベルのアクションだけでテストを定義できるようにする
  - 高レベルのアクションを実現し、詳細な手順について言及しない
  - テストアナリストがシステムテストについて説明する場合、高レベルのアクションについて述べることが多い
- 複雑さがキーワードで隠蔽される
  - 保守性が高く、読み取り/書き込みも容易になる
- SUT のインターフェースの複雑度を抽象化することができる
短所
実装はテスト自動化エンジニアにとって大きな負担である
サポートしないツールを使用する場合は、特にそれが当てはまる
小規模なシステムには実装のオーバーヘッドが大きすぎる
- コストが利点を上回る可能性がある
正しいキーワードが実装されるように十分注意を払う必要がある
優れたキーワードは数多くのテストで使用される
- 適切でないキーワードは 1 度または数回しか使われない

プロセス駆動スクリプティング

主な概念
- キーワード駆動スクリプティング技法がベースとなっている
  - シナリオがスクリプトで構成される点にある
- パラメーターとしてテストデータを受け取るか、ハイレベルのテスト定義と組み合わされている
- アクション間の論理関係として扱いやすい
  - フィーチャーテストで「注文の実行」の後に「注文ステータスのチェック」を行う
  - ロバストネステストで「注文の実行」を行わずに「注文ステータスのチェック」を行う
利点
- プロセス的でシナリオベースのテストケース定義を使用する
  - ワークフローからテスト手順を定義することができる
- 詳細なテスト手順を表すテストライブラリを使用して高レベルワークフローを実現する
短所
- テクニカルテストアナリストがSUTのプロセスを理解するのは容易ではない
  - プロセス指向スクリプトの実装も同様である
  - ツールがビジネスプロセスのロジックをサポートしていない場合、特にそれが当てはまる
- 正しいキーワードを使って正しいプロセスが実装されるように十分注意を払う
- 優れたプロセスは他のプロセスから参照され、多くの関連テストで活用される
  - 適切でないプロセスは妥当性やエラー検知能力などの点で労力に見合わない

モデルベースドテスト

主な概念
- テストケースを自動生成することを指し、テストケースを自動実行することとは異なる
- TAAのスクリプティング技法を抽象化した（準）形式モデルを使用する
- 任意のスクリプティングフレームワーク用のテストを導出するために、異なるテスト生成手法を使用できる
利点
- 抽象化によりテストの本質に集中できる
  - テスト対象のビジネスロジック、データ、シナリオ、構成などに関すること
- 異なる対象システムや対象技術のテストを生成できる
  - テスト生成に使用するモデルが将来を見据えたテストウェアを表現できる
  - 技術の進化に合わせて再利用したり保守できる
- 要件が変更された場合でも、テストモデルを対応させるだけで済む
- すべてのテストケースは自動的に生成される
- テストケース設計技法は、テストケースジェネレータに組み込まれる
短所
- 効果的に実行するには、モデルに関する専門知識が必要になる
- 抽象化してモデリングを行うタスクは困難な場合もある
- モデリングやモデルベースドテストのツールはまだ主流ではなく、成長途中にある
- テストプロセスの調整が必要になる
  - テスト設計者の役割を確立する
  - モデルがSUTの品質保証の主な成果物となるため、品質保証や保守を行う

3.2.3 SUTの技術的考慮事項

TAAの設計にあたっては、SUTの技術的側面を考慮すべきである

SUTのインターフェース

内部インターフェース
- システムの内部
外部インターフェース
- システム環境やユーザーに対するもの
- コンポーネントによって外部に公開されているもの
テスト手順による影響を受ける
- インターフェースの制御・観測を行える必要がある
- インターフェースはテスト可能でなければならない
詳細レベルで記録しなければならない場合がある
- TASとの相互作用
- タイムスタンプが含まれる
個々のテストにスコープを当てる
- プロジェクト開始時のアーキテクチャ定義の際
- アジャイル環境の場合は継続的
- SUTがテスト可能であるために必要なテストインターフェースやテスト設備の可用性を検証する
  - 試験性を考慮した設計

SUTのデータ

構成データを使って具現化、構成、管理などを制御する
ユーザーデータの処理も行う
他のシステムからの外部データを使用してタスクを完了させることもある
定義可能かつ構成可能であり、TAAから具現化する
具体的な方法は、TAAの設計で決定する
扱い方
- パラメーター
- テストデータシート
- テストデータベース
- 実データ

SUTの構成

さまざまな構成で導入される
- 異なるオペレーティングシステム
- 異なる対象デバイス
- 異なる言語設定
  など
TAAが複数のSUT構成に対処しなければならない
異なるTAAのテスト設定（ラボ内）や仮想テスト設定（クラウド内）が必要になる
コンポーネントのシミュレーター・エミュレーターの追加が求められる

SUTの標準と法的設定

互換性のある方法でTAAを設計する
法律や標準に関する要件を考慮する
- テストデータのプライバシー要件
- TAAの記録およびレポート機能に影響する機密性要件

SUTの開発に使用されるツールおよびツール環境

さまざまな目的の為、さまざまなツールが使われる
- SUTの要件エンジニアリング
- 設計
- モデリング
- コーディング
- 統合
- 導入
独自のツールは以下を考慮する
- ツールの互換性
- トレーサビリティ
- 成果物の再利用

ソフトウェアプロダクトのテストインターフェース

プロダクトリリースの前にすべてのテストインターフェースの削除を行わない
最終的なプロダクトに影響を与えることなく、これらのインターフェースをSUTに残しておく
問題の診断や保守リリースのテストにこれらのインターフェースを使用することができる
インターフェースがセキュリティリスクとならないことを検証する
テストインターフェースを使うことができないように無効化できる

3.2.4 開発/QA プロセスの考慮事項

TAAの設計には、SUTの開発および品質保証のプロセスについて考慮する

テスト実行制御要件

TAAで必要とされる自動化のレベルによっては、以下をサポートする

対話的テスト実行
バッチモードテスト実行
完全自動テスト実行

レポート要件

形式やレイアウトが異なる固定のテストレポート
パラメーター化されたテストレポート
定義済みのテストレポート

役割とアクセス権

セキュリティ要件によっては、TAAが役割やアクセス権のシステムを提供する

確立されたツール群

SUTプロジェクトマネジメント
テストマネジメント
コードおよびテストのリポジトリ
欠陥追跡
インシデントマネジメント
リスク分析
バージョン管理
- テストスクリプトは、SUTのコードと同じプロセスに従って改訂されるようにする
他のツールとシームレスに統合されているツール・ツールセット
など

3.3 TASの開発

3.3.1 TASの開発の概要

他のソフトウェア開発プロジェクトに類似する
同じ手順やプロセスに従うことができる
- 開発担当者とテスト担当者によるピアレビューなど
TASに固有な点は、SUTとの互換性と同期である
- TAAの設計およびTASの開発で検討する
- SUTはテスト戦略の影響を受ける
  - TASがテストインターフェースを利用できるようにしなければならない
TASのための基本的なSDLC
- 分析
  - TASの一連の要件を分析および収集する
- 設計
  - TAAで定義されているように、この要件はTASの設計の指針となる
- 開発
  - ソフトウェアエンジニアリングのアプローチにより、この設計がソフトウェアになる
  - TASは専用のテストデバイスハードウェアも使用する場合がある
- テスト
  - 他のソフトウェアと同じように、TASはテストする必要がある
  - これはTASの基本的な機能をテストすることによって行われる
- 導入
  - TASとSUTは相互に影響する
- 改善
  - TASを改修する必要が生じる
    - テスト機能の拡張をする
    - テストを変更する
    - SUTの変更に合わせてTASを更新する
  - SDLC に基づく新たな TA 開発が必要になる
- TASのバックアップ、アーカイブ、廃棄は示されていない
- 組織で確立された手法に従うべきである

3.3.2 TASとSUTの親和性

プロセスの親和性

SUTのテストはSUTの開発と同期すべきである
テスト自動化を行う場合は、TASの開発とも同期させる
以下の整合性をとる
- SUTの開発プロセス
- TASの開発プロセス
- テストプロセス
以下の面でSUTとTASの開発に親和性があると良い
- プロセス構造
- プロセスマネジメント
- 支援ツール

チームの親和性

開発間の親和性のもう1つの側面である
アプローチやマネジメントに親和性を取り入れると、両方のチームにメリットがある
- 要件
- 設計
- 開発の成果物のレビュー
- 問題についての議論
- 互換性のあるソリューションの発見
お互いのコミュニケーションや対話の際にも役立つ

技術の親和性

技術の親和性も考慮すべきである
シームレスな相互作用を設計および実装する
アダプターやラッパーなど何らかの仲介するものを使用することで実現できる
- 技術的ソリューションが利用できないなどの理由で不可能な場合でも

ツールの親和性

ツールの親和性を考慮する
- マネジメント
- 開発
- 品質保証
同じツールを使用している場合、情報交換や調整が容易になる
- 要件マネジメント
- 課題マネジメント

3.3.3 TASとSUTの同期

要件の同期

要件を明確にすることが、SUTとTASの両方の要件の開発につながる
TASの要件
1. ソフトウェアベースのシステムとしてTASの開発に対処する要件
  - TASのフィーチャー要件が含まれる
    - テスト設計
    - テスト仕様
    - テスト結果分析
      など
2. TASを用いてSUTのテストに対処する要件
- テスト要件と呼ばれる
- SUTの要件に対応する
TASがテストするすべてのSUTのフィーチャーや特性を反映する
SUTやTASの要件が更新されるときは、必ず両者の一貫性を検証する
- TASによってテストされるすべてのSUT要件がテスト要件で定義されていることを確認する

開発フェーズの同期

SUTのテストが必要になるときにTASの準備が完了しているよう、開発フェーズを調整する
最も効率がよいのは、SUTとTASの要件、設計、仕様、実装が同期していることである

欠陥追跡の同期

欠陥は以下の可能性がある
- SUTに関連するもの
- TASに関連するもの
- 要件/設計/仕様に関連するもの
片方で欠陥を修正するともう片方に影響が及ぶ可能性がある
- 2つのプロジェクトには関連性がある
欠陥追跡と確認テストは、TASとSUTの両方に対処しなければならない

SUTとTASの改善の同期

SUTとTASはどちらも改善できる
- 新規フィーチャーの組込み
- フィーチャーの無効化
- 欠陥の修正
- 環境の変更
  - 片方がもう片方のコンポーネントとなっているので、それぞれの変更も含まれる
SUTとTASのどちらかに変更が適用されると、もう一方が影響を受ける
- 変更のマネジメントはSUTとTASの両方に対処すべきである

SUTとTASの開発プロセス間を同期させる

2つのフェーズで同期されるアプローチ

SUTの設計
- TASの分析に使用される
SUTのテスト
- 導入済みのTASを使用する

手動および自動の両方のテストを使用したハイブリッドアプローチ

SUTの設計
- 手動テストの分析に使用される
- TASの分析に使用される
SUTのテスト
- 手動テストを使用する
- 導入済みのTASを使用する

3.3.4 TASの再利用性の構築

TASを再利用するレベル

製品ライン
製品フレームワーク
製品ドメイン
プロジェクトファミリー

再利用の要件

TAS成果物に関連性がある対象
- 他のプロダクトバリエーション
- プロダクト
- プロジェクト

再利用可能なTAS成果物

モデル化されたテストの目標
テストシナリオ
テストコンポーネント
テストケース
テストデータ
テスト手順
テストライブラリ自身（の一部）
テストエンジン
テストレポートフレームワーク
SUTのコンポーネント
インターフェースのアダプター

再利用性を高める

TAAに従う
- 必要に応じて改訂・更新する
TAS成果物を文書化する
- わかりやすくする
- 新しい状況に組み込めるようにする
すべてのTAS成果物の正確性を保証しする
- 品質の高さによって新しい状況での使用が促進されるようにする

3.3.5 さまざまな対象システムのサポート

TASがさまざまな構成のソフトウェアプロダクトをテストできる。

TASの変動性の設計は主にTAAに関することである
ライフサイクル全般にわたって考慮すべきである
変動性の選択肢や形態を改訂、追加、削除する
継続的な検討と作業が必要である

SUTコンポーネントの構成

TASは技術的な相違に対応する機能を実装する

TAAの定義の際に決定される
全てのテスト
- 数や相互連携
- 実行される環境
  - ソフトウェア
  - ハードウェア
- 実装するために使われる技術
  - プログラミング言語
  - オペレーティングシステム
- 使用するライブラリやパッケージ
コンポーネント、統合レベル・テスト
- 実装するために使用するツール

TASの多様性への対処方法

TASやSUTのバージョン管理/構成管理を使用する
- お互いに適合するTASとSUTのバージョンや構成を提供する
TASのパラメーター化を使用する
- TASがSUT構成に一致するように調整する

4 導入のリスクとリスクヘッジ計画

4.1 テスト自動化アプローチの選択と導入/展開の計画

パイロット
- 適切なプロジェクトの選定
- パイロットの計画
- パイロットの実行
- パイロットの評価
導入
- 最初の対象プロジェクトの選定
- 選択したプロジェクトへのTASの導入
- 計画した期間の後のプロジェクトのTASを監視および評価
- 他の組織/プロジェクトに展開

4.1.1 パイロットプロジェクト

ツールの実装はパイロットプロジェクトから始まる

目的

TASを使用して意図したメリットを実現できることを確認する

TASに関する理解を深める
TASが既存のプロセス、手順、ツールにどのように適合するかを確認する
- 変更が必要になる点を特定する
- 既存のプロセス/手順に適合するようにTASを変更することが優先される
- 既存のプロセス/手順をTASをサポートするように変更する
  - プロセス自体を改善するべきである
自動化のためのインターフェースを設計する
- テスト担当者のニーズに一致させる
構成管理や変更管理との統合を含むTASやテストのアセットの使用、管理、格納、保守の標準的な方法を決める
- ファイルやテスト成果物の命名規約の決定
- テストスイートのライブラリの作成と部品の定義
  など
テスト自動化を監視するためのメトリクスや測定手法を選定する
- 使用性、保守性、拡張性など
期待するメリットが妥当なコストで実現可能かどうか
- TASを使ってみた後で期待を見直すこともある
どのスキルが必要か、充足・不足しているのか

プロジェクトの選定

重要なプロジェクトを選ばない
- TASの導入遅延が大きな影響を与える
- TASの初期導入には時間がかかる
単純なプロジェクトを選ばない
- 単純でないプロジェクトで成功するとは限らない
- 導入に必要な情報もあまり得られない
選定プロセスに必要なステークホルダーを関与させる
- 組織の他のプロジェクトの適切な基準となるべきである
  - SUTには自動化の必要がある代表的なGUIコンポーネントを含むべきである

計画

通常の開発プロジェクトとして扱う
- 計画の作成
- 予算・リソースの確保
- 進捗の報告
- マイルストーンの定義
  など
導入に携わる人員が導入作業を十分に行えるようにする
- 他のプロジェクトで作業のリソースが求められる
- 共有リソースに関するマネジメント層の関与は重要である
- すべての時間を導入に充てられないことが多い
社内開発のTASの場合
- その開発担当者を導入作業に関与させる必要がある

実行

TASが期待どおりの機能を提供したか
- ベンダーが述べたとおりであったか
- 異なる場合
  - できる限り早く対処する必要がある
社内開発のTASの場合
- その開発担当者が不足している機能を提供し、導入を支援する
TASと既存のプロセスはうまく連携できているか
- 異なる場合
  - 連携させる必要がある

評価

評価にはすべてのステークホルダーを関与させる

4.1.2 導入

パイロットが成功した場合、他の部署/組織に導入する。

段階的に展開する

新規ユーザーのサポートは一斉にではなく波状的に発生する
- TASの使用を段階的に増やすことができる
ボトルネックの可能性を特定し、実際の問題が生じる前に対処できる
ライセンスは必要に応じて追加できる

TASの使用に適したプロセスの適合と改善を行う

異なるユーザーがTASを使用する場合、異なるプロセスがTASに関与する
プロセスをTASに合わせて調整したり、TASをプロセスに合わせて変更したりする

新規ユーザーに対し、トレーニングやコーチング/メンタリングを行う

新しいTASを使用するためのトレーニングやコーチングが必要になる
これらは確実に行われるようにする
トレーニング/ワークショップは、ユーザーが実際にTASを使用する前に提供する

利用ガイドラインを定義する

TASの使用に関する、ガイドライン/チェックリスト/FAQ を作成する
サポートにあたっての質問を大幅に減らすことができる

実際の使用状況に関する情報収集の方法を実装する

TASの使用状況について自動的に収集する方法を確立する
- TASのどの部分（特定の機能）が使用されているか
TASの使用状況が監視しやすくなる

TASの使用、メリット、コストを監視する

一定期間TASの使用状況を監視することで、TASが実際に使用されているかどうかがわかる
ビジネスケースの再計算にも使用できる
- どのくらいの時間を節約できたか
- どのくらいの問題を防げたか
  など
TASのテストチームと開発チームを支援する

すべてのチームから、得られた教訓を集める

TASを使用した各チームと評価/振り返りミーティングを行う
- 得られた教訓を特定できる
TASの使用法を改善するために、情報提供が重要であり、その必要性を理解できる

改善点を特定し、実装する

フィードバックとTASの監視に基づき、改善のステップを特定して実装する
- ステークホルダーに明確に伝達する

4.1.3 ソフトウェアライフサイクル内でのTASの導入

SUTの開発フェーズに大きく依存する
- プロジェクトの開始時
- コードフリーズやスプリント終了時などのマイルストーン到達時
テストや修正を伴う導入作業には時間と労力がかかるためである
TASが動作しないために事によるリスクを軽減する
以下の場合、SUTの開発フェーズとは別に導入を行うことになる
- TASに修正が必要な重要な問題がある
- TASが実行されている環境のコンポーネントを置き換える必要がある

4.2 リスクアセスメントと軽減戦略

一般的に見られる技術的な問題

過度な抽象化
- 実際に何が起きているのかがわかりにくくなる
- キーワード駆動など
データ駆動
- データテーブルが大きすぎる
- 複雑すぎる
- 扱いにくい
TASが依存しているコンポーネントがSUTのすべての対象環境で利用できるとは限らない
- オペレーティングシステムライブラリなどの

一般的に見られる導入プロジェクトのリスク

要員の問題
- コードベースを保守する適切な人員を確保するのが難しい
新たな SU 機能によってTASが正常に動作しなくなる
自動化の実現に遅れが生じる
SUTの変更によってTASのアップデートに遅れが生じる
TASで追跡が必要なオブジェクトをキャプチャできない

TASプロジェクトで考えられる失敗する場面

異なる環境への移行
対象環境への導入
開発からの新しいデリバリー

リスク軽減戦略

前提
- TASにはソフトウェアライフサイクルがある
留意すべき点
- バージョンコントロールを行う
- フィーチャーを文書化する
- 文書化された明確で使いやすい導入手順が必要である
  - バージョンに依存する

初期導入

確認すべき点
- 環境でTASが動作する
- 予期せぬ変更の影響を受けない
- テストケースを更新・管理できる
TASとそのインフラストラクチャの両方を保守する

基本ステップ

TAS用のインフラストラクチャの定義
TAS用のインフラストラクチャの構築
TASおよびインフラストラクチャの保守手順の作成
TASが実行するテストスイートの保守手順の作成

リスク

テストスイートの合計実行時間がテストサイクルで計画した実行時間よりも長い
- テストスイートを実行する十分な時間を確保する
テスト環境のインストールや構成に関する問題が存在する
- 必要な事前条件を設定する効率的な方法が必要である
  - データベースのセットアップ
  - 初回ロード
  - サービスの起動/停止
    など

保守

変更点を評価する
- 新しいバージョン
- 古いバージョン
TASをテストする
- 新機能
- 回帰
  - 更新したTASでテストスイートが実行できる
  - レポートが送信できる
テストスイートを適合させる必要性を確認する
- 新しいバージョンのTAS
更新を環境に適用する

リスクと対応する軽減活動

テストスイートの変更が必要
- テストスイートに必要な変更を行う
- TASに導入する前にテストする
テストで使われているスタブ、ドライバ、インターフェースに変更が必要:
- テストハーネスに必要な変更を行い、TASに導入する前にテストする
インフラストラクチャに変更が必要
- 変更が必要なインフラストラクチャコンポーネントを評価し、変更を行い、更新したTASを使用してテストする
欠陥や性能の問題がある
- リスクとメリットの分析を行う
- TASの更新が不可能になる場合は、更新を行わない
- 次のバージョンのTASまで待機する
- 無視できる程度なら、TASを更新してもよい
- 既知の問題を記載したリリースノートを作成する
  - テスト自動化エンジニアおよびステークホルダーに通知する
  - いつ問題が修正されるか見積るようにする

4.3 テスト自動化の保守

保守は重要である
単純なことではない
要件
- 部品化が可能である
- 拡張性がある
- わかりやすい
- 信頼性が高い
- テスト可能である
- 改善し続ける
動作の信頼性と安全性を高める
- テスト対象となる新しいタイプのシステムに適応させる
- 新しいソフトウェア環境をサポートする
- 新しい法律や規制に準拠させる
寿命や性能も最適化する

4.3.1 保守の種類

運用中に、システムの変更、移行、廃止によって発生する。

4.3.2 スコープとアプローチ

TASのすべてのレイヤーおよびコンポーネントに影響を及ぼす可能性のあるプロセスである

範囲の決定要因
- TASの規模と複雑度
- 変更の規模
- 変更のリスク
影響度分析が必須である
- 変更によってシステムにどのような影響が及ぶか
機能を確実に継続させる
- 段階的に変更を導入する
- 各段階でテストする
  - 仕様や文書が古いと、TASの保守が困難になる

保守の手法

成功要因は時間効率である。

文書化する
- 導入手順
- 使用方法
- サードパーティへの依存性、欠点、既知の問題
部品化する
- コンポーネントを簡単に交換できる
移行可能な環境で実行する
- TAS、コンポーネント
TAF自体からテストスクリプトを分離する
開発環境から分離した状態でTASを実行する
- 変更によってテスト環境が悪影響を受けないようにする
構成管理の対象とする
- 環境、テストスイート、テストウェア

サードパーティコンポーネントやその他のライブラリの保守

コンポーネントを使用することは非常に多い
- ライブラリ（UI自動化ライブラリなど）に依存している場合もある
- コンポーネントは、すべて文書化し、構成管理の対象とする
外部コンポーネントの変更や修正が必要になった場合の計画が必要である
- TASの保守責任者は、連絡先や問題の報告先を知っておく
コンポーネントを使用するライセンスについては文書化する
- 変更可能か、どの程度変更できるか
コンポーネントの更新や新バージョンについての情報を取得する
- 最新の状態に保つことは、長期的な投資に見合った予防措置である

命名規約やその他の規約

命名規約やその他の規約を導入するメリットは単純である
- 読みやすく、わかりやすく、変更や保守を簡単にする
- 保守プロセスにかかる時間を短縮できる
- 回帰や誤った修正が発生するリスクも最低限にとどめられる
- 発生した場合は容易に取り除くことができる
新しい人員がテスト自動化プロジェクトに参画しやすくなる
- 命名規約は名前を定義する
  - 変数
  - ファイル
  - テストシナリオ
  - キーワード
  - キーワードパラメーター
- その他の規約
  - テスト実行の前提条件や事後処理
  - テストデータの内容
  - テスト環境
  - テスト実行のステータス
  - 実行結果記録
  - レポート
開始時にすべて同意され、文書化する

文書化

十分な最新の文書が必要となる
- 2つの問題がある
  - 文書を作成する
  - 文書を保守する
自動または半自動で文書化することができる
- テストツールのコード設計書
誰かが文書化する必要がある
- 設計、コンポーネント、サードパーティ製のコンポーネント
  - 統合、依存性、導入手順
開発プロセスの一部に文書化を含める
- 文書化されるまでは、タスクが完了しない

トレーニング教材

文書が十分記述されている場合、ベースとして使用できる
内容
- 機能仕様
- 設計
- アーキテクチャ
- 導入および保守
- TASの使用方法（ユーザーマニュアル）
- 実例や練習問題
- 使い方に関するヒント
見直し
- TASの講師となるチームメンバーが担当する
- SUTのイテレーションの終盤（スプリントの終了時など）で行われる

5 テスト自動化のレポートとメトリクス

5.1 TASメトリクスの選択

テストマネージャーが選択する

TASメトリクスの分類

外部メトリクス
- 他の作業に対するTASの影響を測定する
  - とりわけテスト活動
内部メトリクス
- 目的達成におけるTASの有効性および効率性を測定する
  - 変更の影響を監視する

測定後のTASメトリクス

外部メトリクス
- 自動化のメリット
- 工数
  - 自動テストを構築する工数
  - 自動テストで検出された故障を分析する工数
  - 自動テストを保守する工数
- テスト
  - 故障と欠陥の比
  - 自動テストの実行時間
  - 自動テストケースの数
  - 成功結果および失敗結果の数
  - 誤った失敗結果および誤った成功結果の数
  - コードカバレッジ
内部メトリクス
- ツールスクリプトのメトリクス
- 自動テストコードの欠陥密度
- TASコンポーネントのスピードと効率性

自動化のメリット

メリットを測定し記録することはとりわけ重要である
- コストは目に見えやすいからである
  - 一定期間に関与した人員の数
- 達成できたメリットはイメージできない
メリットの測定
- TASの目的によって異なる
メリットの例
- 時間や工数の節約
- 実行するテストの数の増加
  - カバレッジの広さや深さ
  - 実行の頻度
- 再実行性の増加
- リソースの効率的な活用
- ヒューマンエラーの削減

メリットの測定項目

手動テスト工数を節約できた時間
回帰テストの実行時間の削減
実現できたテスト実行の追加サイクル数
実行された追加テストの数や割合
テストケース全体に対する自動テストケースの比率
- 自動テストケースと手動テストケースの比較は容易ではない
カバレッジの増加
- 要件
- 機能
- 構造
TASによって早期に発見できた欠陥の数
- 欠陥の早期発見による平均的な利益がわかる場合
  - これを「計算」して予防されたコストの合計を導き出すことができる
TASによって発見できた欠陥のうち、手動テストでは見つからなかったと思われるものの数
- 信頼性の欠陥など

間接的なメリット

手動テストの工数が節約できる
その他の種類のテストに充てることができる
- 探索的テストなど
追加テストで欠陥が見つかる
TASのメリットと見なす

自動テストを構築する工数

主なコストの1つである
手動で実行するコストよりも高くなる
利用を拡大する上で障害となる
実装コストはテストの内容に依存する
その他の要素にも左右される
- スクリプティングアプローチ
- テストツールの習熟度
- 環境
- テスト自動化エンジニアのスキルレベル
構築コストの計算
- 平均構築時間が使われる
  - 特定のテストセットの平均コストを考慮することにより、さらに精度を上げられる
    - 同じ機能を対象としたテスト
    - あるテストレベルのテスト
      など
- 手動実行に必要な工数の係数
  - 同等の手動テスト工数
  - EMTE(Equivalent Manual Test Effort)

SUTの故障を分析する工数

手動実行時より自動テスト実行で検出された故障の分析は大幅に複雑になる
- 手動実行時は故障に至るまでの事象を分析者が認識しているためである
- レポートレベルによって緩和できる
失敗したテストケースあたりの平均、EMTEの係数として表現できる
- EMTEの係数は、自動テストの複雑度や実行時間が大きく異なる場合に特に適している
記録
- 故障の分析において重要な役割を果たす
- 十分な情報を提供すべきである

重要な記録機能

SUTの記録とTASの記録は同期しているべきである
TASは期待される振る舞いと実際の振る舞いを記録すべきである
TASは実行されるアクションを記録すべきである
SUTは実行されるすべてのアクションを記録すべきである
- アクションが手動テスト結果でも、自動テスト結果でも構わない
- 内部エラーはすべて記録する
  - クラッシュダンプやスタックトレースも利用できるようにする

自動テストを保守する工数

非常に大きくなる可能性がある
- TASによって実現できるメリットを上回ってしまうことがある
多くの自動化作業が失敗する原因となる
- 保守工数を削減する必要がある
- 保守工数の監視が重要になる
保守工数の測定値
- 新しいリリースごとに保守が必要になる自動テストの合計
- 更新された自動テストごとの平均または EMTE の係数
関連メトリクス
- 保守作業が必要なテストの数や比率
保守工数がわかる場合
- 機能の実装や欠陥の修正の是非を判断する際に重要なメトリクスとなる
- SUTの変更と合わせて考慮する

故障と欠陥の比

多くの自動テストがソフトウェアの1つの欠陥のために失敗する
同じ欠陥を複数のテストで検出しても無駄になる
失敗した各テストを分析する工数が多くなる
ある欠陥が原因で失敗した自動テストの数を測定することで、問題の発生箇所を明らかにできる
自動テストの設計と実行する自動テストの選択によって解決できる

自動テストの実行時間

判断しやすいメトリクスの1つである
最初の段階では重要でないこともある
数が増えるにつれて重要なメトリクスになる

自動テストケースの数

進捗を示すために使用できる
数だけでは多くの情報を明らかにできない
- テストのカバレッジが増加したことを示さない

成功結果および失敗結果の数

一般的なメトリクスである
失敗を分析する
- SUTの欠陥
- 環境やTAS自体の問題などの外部の問題

誤った失敗結果および誤った成功結果の数

失敗の分析にはかなりの時間がかかる
時間がかかるのは、問題がSUTではなく TASまたはテストケースにある場合である。\

誤った失敗

誤警告の数を低く抑える
- TASの信頼性が低下する
発生要因
- テストコードの欠陥
- SUTが不安定で予想できない振る舞い
  - タイムアウトなど
- テストフックの干渉

誤った成功

さらに危険になる
故障を特定できず、成功という結果になる
欠陥候補を検知できなかった
発生要因
- 結果の検証が適切に行われなかった場合
- 無効なテストオラクルが使用された場合
- テストケースが誤った結果を期待していた場合

コードカバレッジ

有用な情報を得ることができる
ハイレベルでも測定できる
- 回帰テストスイートのコードカバレッジなど
十分であることを示す絶対的な比率は存在しない
100% になることはほぼない
十分であるほどリスクを軽減できる
- 大きいほどよいというのは一般的な共通認識である
SUTの活動を示す可能性もある
- 低下した場合、SUTへの機能時に対応するテストケースが追加されていない

ツールスクリプトのメトリクス

使用できるメトリクスは多数ある
SUTのメトリクスと同様である
- コードの行数（LOC）やサイクロマティック複雑度
  - 肥大したスクリプトや複雑なスクリプトを検知する
    - 再設計が必要な可能性を示す
- コメントと実行ステートメントの比
  - スクリプトの文書化や注釈の程度を示す
- スクリプト標準への準拠違反の数
  - どの程度標準に準拠しているかを示す

自動テストコードの欠陥密度

ソフトウェアであり欠陥を含む
SUTのコードより重要度が低いとは限らない
優れたコーディング慣習やコーディング標準を適用する
コードの欠陥密度などのメトリクスで監視する
- 構成管理システムのサポートにより収集は容易になる

TASコンポーネントのスピードと効率性

SUT が同じ経過時間で同じ機能を実行できない場合、調査が必要である
許容範囲外のシステムの性能のばらつきを示している
- 負荷が増加するとさらに悪化する可能性がある
性能が重要な場合は、性能を妨げないようTASを設計する

傾向メトリクス

傾向（測定値の経時変化）が重要である
- 特定の時間の測定値よりも重要になりえる
例
- 平均保守コストが増加している場合、原因を判断し、改善できる
測定コストはできる限り低く抑える
- 収集とレポートを自動化する

5.2 測定の実施

使用状況に関する情報を記録する
抽象化と構造化されたテストウェアを組み合せている場合
- 基になるテストウェアに対して行われた拡張をすべてのテストスクリプトで活用できる
例
- テスト実行の開始時間と終了時間を記録する拡張を、すべてのテストに適切に適用できる

測定とレポート生成をサポートする自動化の機能

多くのテストツールのスクリプト言語は、個々のテストや一連のテスト、テストスイート全体の実行前、実行中、実行後に情報を記録する機能によって、測定とレポートをサポートしている。

傾向（テスト成功率の変化など）を明らかにできるように、一連のテスト実行のそれぞれに対するレポートは、前のテスト実行結果を考慮した分析機能を備える必要がある。

テストを自動化するには、テスト実行とテスト検証の両方を自動化する
テスト検証は、テスト結果の特定の要素と事前に定義された期待結果を比べる
- 比較はテストツールで行う
- 比較の結果としてレポートされる情報のレベルを考慮する
- テストのステータスを正確に判断する
  - 成功、失敗など
  - ステータスが失敗の場合
    - 原因についての詳しい情報が必要になる
      - スクリーンショットなど
テストの実行結果と期待結果で予測される違いが簡単に判別されるとは限らない
- 予測される違い（日付や時間など）を無視しする
- 予測されない違いを定義するには、ツールのサポートが大いに役立つ

サードパーティツールとの統合

例
- スプレッドシート
- XML
- 文書
- データベース
- レポートツール
  など
サードパーティツールに適切な形式で情報を提供する
- トレーサビリティマトリクス更新などの追跡やレポート
既存のテストツールの機能によって実現できる
- レポート用にフォーマットをエクスポート
他のプログラムと互換性のある形式で出力できるようにレポートをカスタマイズする
- Excel の「.xls」
- Word の「.doc」
- Web の「.html」
  など

結果の視覚化

図を使って視覚化する
- ダッシュボード、図、グラフなど
色を使って問題を示す
- 信号機の色で進捗を示す
マネジメントには、テスト結果を一目で確認できることが求められる
- 情報が必要な場合は、詳細を確認できる

5.3 TASおよびSUTの結果記録

問題候補を分析する際に使われる

TASの結果記録作業

現在実行中のテストケース
開始時間および終了時間
テストケース実行のステータス
- 失敗はログファイルで容易に特定できる
- フレームワーク自体にもこの情報がある
- ダッシュボードを通して報告される
- 成功、失敗、TAS エラーのいずれか
- TASエラーは、問題がSUTではない場合に使用される
テスト結果記録のハイレベルな詳細
- タイミング情報
- 重要な手順の結果記録
  など
SUTについての動的な情報
メモリリークなど
実行結果や動的測定の失敗は、インシデントが検知された際に実行されていたテストケースとともに記録する。
テストケースの実行回数
- 信頼性テスト/ストレステストで、多数のサイクルが実施される場合
乱数/選択値
- テストケースにランダムな部分がある場合
  - ランダムパラメーター
  - ステートマシンテストのランダムステップ
    など
すべてのアクション
- テストの同じステップを同じタイミングで正確に再現する
  - 追加情報を得る際に便利である
- SUT自体に記録することもできる
  - 顧客がシナリオを実行する
  - 開発チームがトラブルシューティングを行う際に再生する
視覚情報のキャプチャ
- 故障の解析の際に使用できる
- テスト実行の際のスクリーンショットなど
問題の分析に必要なすべての情報
テストの継続に関連する情報
安全な場所に保存する
- クラッシュダンプ
- スタックトレース
- ログファイル
記録された情報の種類を区別する
- 色分けする
  - エラーは赤
  - 進捗情報は緑
    など

SUTの結果記録作業

問題の分析に必要なすべての情報
- 日付とタイムスタンプ
- 問題の発生元の位置
- エラーメッセージ
  など
すべてのユーザー操作を記録する
- ユーザーインターフェース
- ネットワークインターフェース
  など
- 顧客が特定した問題を適切に分析できる
- 開発側で問題の再現ができる
構成情報を記録する
- 各ソフトウェア/ファームウェアのバージョン
- SUTの構成
- オペレーティングシステムの構成
  など
すべて簡単に検索できる
TAS・SUTのログファイルで特定した問題を他方のログファイルで簡単に特定できる
タイムスタンプで記録を同期させる
- エラー報告時に関連付けやすい

5.4 テスト自動化のレポート

結果記録だけで全体像を適切に把握することはできない
実行されるたびに、簡潔なレポートを作成して公開する
- 再利用可能なレポートジェネレータコンポーネントを使用できる

レポートの内容

サマリー
- 実行結果の概要
- テスト対象のシステム
- テストを実行した環境
- 各ステークホルダーに提供する
各テストの失敗理由
テストの実行履歴
- 責任者
  - テストの作成者または最終更新者
責任者
- 失敗の原因を調査する
- 関連する問題を報告する
- 問題の修正をフォローアップする
- 正しく修正されたことを確認する
  -TAFコンポーネントの故障を診断する

レポートの公開

実行結果に興味を持つ者全員に公開される
別のツールへのアップロード
- Webサイト
- メーリングリストへの送信
- テストマネジメントツール
  など
レポートの履歴を保管する
- 統計を集計する
- 頻繁に起こる回帰
  - SUTの問題がある部分を特定する

6 手動テストから自動化環境への移行

6.1 自動化の移行条件

手動テストを実施してきた
移行の決断
- 手動テストの状況を評価する
- 効果的なアプローチを判断する
既存の手動テストの構造の適合性
- 適している場合
  - 自動化への移行が容易である
- 適さない場合
  - すべてのテストの再作成が必要になることもある
  - 関連する内容を抽出し、再利用してもよい
    - 入力値、期待結果、ナビゲーションパス
自動化の対象
- すべてを自動化できるとは限らない
- すべてを自動化するべきでもない
最初のテストのイテレーションは手動となりえる
- 既存の手動テストを自動化する初回の変換
- 新しい手動テストを自動化するために行う移行
効果的に実行できるテスト
- 信頼性テスト
- ストレステスト
- 性能テスト
ユーザーインターフェースのないアプリケーションやシステムのテスト
- ソフトウェアのインターフェースを通して統合レベルでテストを行える
  - 例：システムのメッセージキューにメッセージを直接挿入できる
  - 手動でコマンドを実行できるが、現実的ではない
- 早い段階でテストを開始できる
  - 欠陥を早期に検出できる

合目的性（適応性と実現性）の条件

自動テストと手動テストのどちらを作成するか。

使用頻度
自動化の複雑度
ツールの適合性とサポート
テストプロセスの成熟性
ソフトウェアプロダクトライフサイクルの段階における自動化の合目的性
自動化環境の持続可能性
SUTの操作特性

使用頻度

どの程度の頻度で実行するか
アプリケーションのリリースが頻繁である
- 対応するテストサイクルが多い
  - メジャー・マイナーリリースサイクルの一部として定期的に実行されるテスト
機能テスト
- 以降のリリースで回帰テストの一部として使用できる
回帰テスト
- 投資収益率（ROI）は高い
- 既存のコードベースのリスク軽減になる
1年に1度実行され、1年以内にSUTが変更される場合
- 効果的ではない
- 手動でテストを行う方が望ましい

自動化の複雑度

‐ 複雑なシステム

メリットが非常に大きくなりやすい
複雑な手順を繰り返すタスクを行わずに済む
- 手間や時間がかかり、エラーも起きやすい
自動化が困難だったり、自動化のコスト効率がよくない
既存の自動テストと互換性のないSUT
大量のプログラムコードとAPI呼び出しを開発する
外部インターフェース・独自システムとの連携
使用性テスト

ツールの適合性とサポート

さまざまな開発プラットフォーム
- どのテストツールが利用できるか
- どの程度サポートされているか
テストツールの提供種類
- 商用ベンダー
  - 有償サポートを提供する
  - 実装を支援できる専門家のサポート環境が存在する
- オープンソースツール
  - オンラインフォーラムなどのサポートを提供している
  - そこから情報を得たり、そこに質問を投稿したりする
- 社内で開発されたテストツール
  - 既存のスタッフがサポートを提供する
適合性の問題を過小評価すべきではない
- 壊滅的な結果となることがある
- 大半が自動化できても、重要なテストが自動化できない場合も

テストプロセスの成熟性

自動化の効果的な実装プロセス
- 構造化する
- 統制する
- 繰り返し可能にする
既存のテストプロセス
- 自動化コードや関連するコンポーネントの管理が必要となる
- 開発プロセス全体へと影響を及ぼす

ソフトウェアプロダクトライフサイクルの段階における自動化の合目的性

SUTにはソフトウェア開発ライフサイクルが存在する
- 数年から数十年に及ぶ可能性がある
システム開発が始まると、エンドユーザーのニーズを満たすために欠陥への対処や機能の追加が行われ、システムは変化し拡張される
初期段階
- 変更が早すぎて実装が追いつかない
- 作業のやり直しが継続的に必要になる
  - 効率的、効果的ではない
シーケンシャル開発
- コア機能を組み込んだタイミングで自動テストの実装を始める
最終段階
- システムは廃棄される
- 新しく効率的な技術を使用して再設計される
- 終了が近いシステムの自動化は推奨しない
再設計
- データ要素を定義した自動テスト環境は、新しいシステムでも有用である
- テストデータの再利用が可能である
- 自動化環境の記録に新しいアーキテクチャとの互換性を持たせる

環境の持続可能性

時間の経過とともにSUTに起こる変化へ柔軟に対応する
- 自動化の問題をすばやく診断して修正できる
- 自動化コンポーネントを容易に保守できる
- 自動化環境に簡単に新規のフィーチャーやサポートを追加できる
gTAAの全般的な設計や実装として不可欠な部分である

SUTの操作特性（事前条件、セットアップ、安定性）

SUTの操作特性や視覚特性を識別する
- 効果的な自動テストを作成する際に役立つ
識別できない場合
- UI操作にのみ依存する
- 保守性が低下する

ROI分析を支援する技術計画

テストチームが得られるメリットの程度はさまざまである
効果的な自動テストの実装は多大な作業とコストを伴う
目的やメリット、成果について評価をする
計画を実現するため必要な作業を定義しする
コストを判断する
ROIを計算する

移行準備

テスト自動化のテスト環境で利用できるツール
テストデータとテストケースの正確性
テスト自動化作業の範囲
パラダイムシフトを起こすためのテストチームの教育
役割と責任
開発担当者とテスト自動化エンジニアの連携
並行作業
テスト自動化のレポート

テスト自動化のテスト環境で利用できるツール

先行検証環境にインストールする
機能することを確認する
- サービスパックやリリースアップデートのダウンロード
- SUTをサポートするために必要かつ適切なインストール構成の選択（アドインを含む）
- 検証環境と自動化の開発環境でTASが正しく機能することの確認

テストデータとテストケースの正確性

確実に予測できる結果を出す
- 手動テストデータとテストケースが正確かつ完全である
自動テスト実行には以下が必要である
- 明示的な入力データ
- ナビゲーション
- 同期化
- 検証

テスト自動化作業の範囲

自動化を早期に成功させる
限定された範囲から始める
- 技術的問題のフィードバックを得る
- その後の自動化タスクを容易にする
パイロットロジェクト
- システム全体の相互運用性を代表するシステムの機能の 1 つの領域を対象とする
- 今後の時間の見積り
- スケジュールの調整
- 特殊な技術を持つリソースが求められる領域の特定
成功によりマネジメントからの支持も集まる
自動化するテストケースを適切に選択する
- 手間がかからず、高い付加価値を提供する
- 回帰テストやスモークテスト
  - 頻度が高い
  - 毎日実行されたりする
- 信頼性テスト
  - 複数のステップで構成される
  - 何度も繰り返し実行される
  - 手動では明らかにしにくい
  - 実装に手間がかかりづらい
自動化に注目を集める
- 手動テストの工数を節約する
- 重大な問題を特定する
- 今後の拡張への道を開く
  - 工数や予算など
重要なテスト
- 最初から最大の価値が明らかである
- 優先度を高くする
技術的に難易度が高すぎるテスト
- 避けることが重要である
- 多大な工数がかかる割に、示すべき結果がほとんどない
アプリケーションの大部分に見られる特徴を共有するテストを特定する
- 自動化の作業存続に必要となる

パラダイムシフトを起こすためのテストチームの教育

さまざまな背景を持つ人員を混在させる
- 特定のドメインの専門家である
  - エンドユーザーコミュニティに所属している
- ビジネスアナリストとして関与している
- システムアーキテクチャを深く理解できる
  - 優れたな技術スキルを持つ
テストチームの構成を変える
- シフトするにつれ、役割は特化される
- 自動化の成功にとって不可欠である
早くからチームを教育する
- 不安や不必要な考えが生じる可能性を軽減する
- 自動化へのシフトに期待する
- 組織や技術の変化に参画する準備が整う

役割と責任

全員が参画できる
全員が同じ役割ではない
ドメインの専門家
- ドメインの専門性とテストスキルを持つ人員
  - 自動化環境を推進する
  - 目標のテストカバレッジを実現する
- 適切なテストスクリプト
  - 対応するテストデータを含む
  - テストケースの実装
- アプリケーションの機能を確認する
- レポートをレビューする
- テスト担当者
技術的な専門家
- プログラミングのスキルに強く、技術的背景を持つ人員
- 設計や実装
  - 技術的な作業
  - 保守性の高いソフトウェアの設計
  - テスト自動化フレームワークやテストライブラリ
- 自動テスト環境の保守
  - 技術者・非技術者でも同様に使用できる環境とする
  - 正常かつ効率的に運用されることを保証する
- 開発担当者の場合もある

開発担当者とテスト自動化エンジニアの連携

成功にはソフトウェア開発チームの関与も必要である
開発担当者とテスト担当者がより密接に連携して作業する
- 支援要員や技術情報を提供する
  - 開発の手法やツールについて
システム設計や開発コードの試験性
- テスト自動化エンジニアが懸念を示す場合がある
  - 設計やコードが標準に従っていない
  - 見慣れないライブラリやオブジェクト、内製のものや極端に新しいものを使用している
- 例：開発担当者が選定された自動化ツールと適合性のないサードパーティ製 GUIコントロールを選ぶ
プロジェクトマネジメントチームが必要な役割の種類と責任を明確に理解する

移行作業

移行前
- 手動スクリプトの評価を行う
- 効率的、効果的なアプローチのため、再構築するか
移行時
- 移行チームを編成する
- 既存の手動テストスクリプトを自動化する
- 手動スクリプトと同じことを検証する
- 自動化されたスクリプトが組み込まれる
- 手動スクリプトに代わる

テスト自動化のレポート

TASの正しい運用を可視化する
- 報告されるアプリケーション固有の結果が正確かつ完全であると見なされるように
レポート内容
- 個々のスクリプトやスクリプト内の手順の合格/失敗のステータス
- テスト実行全体の統計
- TASの全般的な性能
  など

6.2 回帰を自動化する際に必要な手順の特定

自動化を使用する絶好の機会である
今日の機能テストが翌日の回帰テストになる
回帰テストのテストベッドは増加し続ける
従来の手動テストチームが利用できる時間とリソースを超えるのは時間の問題である

準備する段階

どのくらいの頻度でテストを実行するのか
個々のテストの実行時間、回帰テストスイートの実行時間はどのくらいか
テスト間で機能の重複はないか
テストでデータが共有されているか
テストはお互いに依存しているか
テスト実行の前にどのような事前条件が必要になるか
テストのSUTのカバレッジは何 % か
現在のテストは失敗なく実行されるか
回帰テストに時間がかかりすぎた場合、何が起きるか

テスト実行の頻度

頻繁に実行されるテストは、候補として最も適している
既に開発されており、SUTの既知の機能性をテストする
自動化によって実行時間を大幅に減らせる

テスト実行の時間

実装する価値を評価する上で重要である
時間のかかるテストから自動化の実装を始める場合
- 毎回のテストの実行が速く効率的になる
  - 実行サイクルを増やせる
- SUTの品質に関するフィードバックの数と頻度が増加する
  - 展開時のリスクが減る

機能の重複

テストケース間に存在する機能の重複を見つけ、減らす
- 実行時間の効率が上がる
- 増えるにつれ、重要性が増す
自動化テストは新しい構造になる
- 再利用可能なコンポーネントと共有データリポジトリに依存する
- 既存の手動テストを分解して複数の小さな自動テストにする
- 手動テストを統合して大きな自動テストにする
手動テストには個々の評価とグループとしての評価が必要になる
- 効果的な変換の戦略を実現する

データ共有

頻繁にデータが共有される
- テストが同じレコードのデータを使用して別のSUT機能を実行する
- 例：
  - 社員が利用できる休暇時間を検証するテストケース「A」
  - 社員がキャリアアップのために受講できるコースを検証するテストケース「B」
  - 同じ社員を使用する
手動テスト
- 社員データは手動テストケースごとに複数回コピーされる
  - その社員を使用して社員データを検証する
自動テスト
- 共有するデータを1 つのソースに格納し、そこからアクセスする
  - 重複やエラーを防ぐ

テストの相互依存性

1つのテストが他のテストに依存する場合がある
発生頻度が高い
例
- 「注文ID」が作成される
- 以下を検証する
  - 新しい注文がシステムに正しく表示される
  - 注文の変更が可能である
  - 注文の削除が成功する
「注文ID」の値をキャプチャし、以降のテストで再利用する
設計により対処する

テストの事前条件

条件
- テストを行う正しいデータベースやテストデータセットの選択
- パラメーターの初期値の設定
設定せずに実行できない
設定は自動化できる
ステップの漏れを防ぐ
信頼性があがる

SUTのカバレッジ

SUTの機能が実行される
カバレッジを広く、深く、テストを設計する
コードカバレッジツールを使用して自動テストの実行を監視する
- テストの有効性の定量化を進める
時間経過によりテストが追加され、カバレッジが高まる
テスト自体の価値を定量化する有効な手段である

実行可能なテスト

変換前に、手動テストが正しく動作することを検証する
- テストの記述が適切でない
- 無効なデータを使用している
- 期限切れ・現在のSUTと同期していない
- SUTに欠陥がある
機能しない自動テストが作成された場合
- 非生産的である

大規模な回帰テストセット

巨大になりがち
夜間・週末で実行できないほどになる
同時実行
- PCアプリケーションなど
部分実行
- SUTが高価で入手しにくい
  - 航空機や宇宙ロケットのシステム
- 並列化できない
- リスク分析によって決める
  - 最近変更した部分
長期実行
たとえば数週間
最終的にセット全体が実行される

6.3 新規のフィーチャーのテストを自動化する際に考慮する要素

新しい機能のテストケースが自動化しやすい
実装が完了・開始していない
- テスト実装に何が必要か説明できる
新規のフィーチャー導入
- 対応するテストを開発する
- ドメインの専門知識を持つテスト設計者によるフィードバックを求める
- TASがフィーチャーのニーズを満たすかどうかを判断する
TASの変更や追加
- 既存部分を評価し、完全に文書化する
- 振る舞い（または性能）や既存のTASの機能に影響させない
別のクラスやオブジェクトなどで実装される
- テストウェアコンポーネントの更新や追加が必要になる
互換性を評価する
- 必要な場合、代替ソリューションを特定する
- 例：キーワード駆動アプローチを使用している場合
  - 追加キーワードの開発や既存のキーワードの変更・拡張が必要になる
新しい環境をサポートする
- 追加テストツールを評価する
- 例：既存のテストツールが HTML しかサポートしない
新しいテストの要件
- 既存に影響を与える可能性がある
- 変更する前に自動テストを実行する
- 動作が変更されないか記録する
他のテストとの相互依存性のマッピングも含まれる
技術面での新しい変更点
- 現在のテストウェアコンポーネントと既存のTASとの互換性を評価する
  - テストツール、機能ライブラリ、APIなど
既存の要件が変更された
- 検証するテストケースの更新作業をスケジュールに含める
- テストケースまでのトレーサビリティがある場合
  - どのテストケースを更新する必要があるかがわかる
- 全体計画の一部に含める
TASがSUTのニーズを満たし続けるか
- 実装技術はまだ有効か
- 新しいアーキテクチャが必要か
- 現在の機能を拡張して行えるか
新機能が導入されるタイミング
- 新しく定義された機能がテスト可能であることを確認する機会
- 設計フェーズの間にテストについても考慮する
  - スクリプト言語やテスト自動化ツールで新機能を検証できる
  - テストインターフェースの提供を計画する

6.4 確認テストを自動化する際に考慮する要素

コードを修正した後に実行される
再現するステップを実行し、欠陥がなくなっていることを検証する
以降のリリースで再発する可能性がある
- 構成管理に問題がある可能性を示す
- 自動化の候補となる
実行時間を削減できる
自動回帰テストベッドに追加、補完できる
機能スコープは狭い
実装はいつでも行える
自動欠陥確認テストの価値を保持される
- 標準の自動回帰スイートに組み込む
- 既存の自動テストに取り入れる
自動確認テストの追跡
- 欠陥の解決に費やされたサイクルの時間や回数を追加報告できる
欠陥の修正の副作用として新しい欠陥が増えていないことを確認する
- 確認テストに加えて回帰テストも必要になる
回帰テストの適切なスコープを決定する
- 影響度分析が必要になる

7 TASの検証

7.1 自動テスト環境のコンポーネントの検証

期待通りに動作していることを検証する
- 自動化を始める前などに行う
検証ステップは複数存在する

テストツールのインストール、セットアップ、設定およびカスタマイズ

多数のコンポーネントで構成される
それぞれが信頼性と再現性のある性能を確保する
中核
- 実行可能なコンポーネント
- 対応する機能ライブラリ
- サポートデータ
- 設定ファイル
構成プロセス
- 自動インストールスクリプトを使用する
- 対応するフォルダに手動でファイルを配置する
  など
サービスパックやオプションのアドイン
- SUT環境との互換性を確保する
セントラルリポジトリ
- 自動インストール・コピー
- 異なるSUTのテストを同じバージョンのTASや同じ構成のTASで実行できる
- TASのアップグレードを行える
アップグレードするプロセス
- 標準開発ツールと同じにすべき

合格と失敗が既知であるテストスクリプト

合格するテストケースが失敗した場合
- 早急に修正する必要がある
失敗するテストケースが合格した場合
- 正しく機能していないコンポーネントを特定する
検証する
- ログファイル
- 性能メトリクス
- 検証するとともに、
- 自動セットアップ
- 終了処理
タイプやレベルが異なるテストを実行する
- 機能テスト
- 性能テスト
- コンポーネントテスト
  など
フレームワークのレベルでも実行すべき

テスト環境のセットアップ / 終了処理における再実行性

さまざまなシステムおよびサーバーで実装される
任意の環境からTASをロードおよびアンロードする
目に見える差異が発生しない場合、これがうまく実現できている
コンポーネントの構成管理
- 信頼できる形で構成を作成できるようになる

テスト環境およびコンポーネントの構成

文書化する
SUT環境が変更された場合
- 影響を受けたり、変更が必要になるか、知識を得られる

内部および外部のシステム / インターフェースに対する接続性

SUT環境にTASをインストールした場合
- 一連のチェックや事前条件を管理する
- 内部・外部のシステムやインターフェースに接続する
自動化のための事前条件を確立する
- TASを正しくインストールおよび構成できる

自動テストツールの干渉関係

TASはSUTと密接に結合している
- 設計的に高いレベルの互換性を実現する
  - GUIレベルの操作が関係する
マイナスの効果がある
- 例
  - TASがSUT環境の中にある場合とない場合でSUTの動作が異なる
  - 手動で使用する場合、SUTが異なる振る舞いを見せる
  - 環境内のTASによって、またはSUTに対してTASを実行するときに、SUTの性能が影響を受ける
    など

干渉のレベル・関係

外部インターフェースからSUTに接続する場合
- 干渉のレベルは非常に低くなる
- 外部インターフェース
  - 電気信号（物理スイッチの場合）
  - USB信号（キーボードなど）
- 最も適切な形でエンドユーザーをシミュレートできる
- SUTのソフトウェアをテストの目的によって変更しない
- SUTの振る舞いやタイミングが影響を受けない
- 非常に複雑になりえる
- 例
  - 専用ハードウェアが必要になる
  - ハードウェア記述言語が必要になる
- ソフトウェアのみ
  - 典型的なアプローチではない
- 組込みソフトウェア製品
  - よく使われる
GUIレベルでSUTと接続する場合
- UIコマンドをインジェクションしてテストケースが必要とする情報を抽出できるように、SUT環境を変更する
- SUTの振る舞いは直接的に変更されない
- タイミングには影響がありる
- 結果的に振る舞いに影響しえる
- 干渉のレベルは前項目より高い
- 複雑さは低くなる
- 市販ソフトウェアツールを使える
インターフェース（API）でSUTと接続する場合
- ソフトウェアのテストインターフェース
- 既にソフトウェアが提供している既存のインターフェース
- 可用性が重要な部分である
- 干渉のレベルは非常に高くなる
- エンドユーザーに使用されないインターフェースを使用する場合がある
- 実際とは異なる状況でインターフェースが使われる場合がある
- 非常に簡単で安価である
- 潜在的なリスクを理解している限りにおいては、確実である
干渉のレベルが高い場合
- 実世界では起こりえない故障がテストで起こる
- 信頼性が大幅に低下する
- 特定された故障を手動で再現させる

フレームワークコンポーネントテスト

個々にテストし、検証する
- 機能テスト
- 非機能テスト
  - 性能：フレームワークの性能低下の把握
  - 資源効率性：メモリリークなどの問題を示す可能性があるシステムリソースの使用状況
  - 使用性：フレームワークの内外のコンポーネントの相互運用性
    など
例
- GUIシステムでオブジェクト検証を行うコンポーネント
  - 幅広いオブジェクトのクラスに対してテストを行う必要がある。\
エラーログおよびレポート
- 自動化の状況とSUTの振る舞いについて正確な情報を提供する

7.2 自動テストスイートの検証

完全性、一貫性、正しい振る舞いを確認する
常に自動テストスイートが動作していることを確認する

検証手順

既知の合格と失敗があるテストスクリプトの実行
テストスイートの確認
フレームワークの新フィーチャーに着目した新しいテストの検証
テストの再実行性の考慮
自動テストスイートに十分な検証ポイントが存在あることの確認

既知の合格と失敗があるテストスクリプトの実行

合格するテストケースが失敗した場合
- できる限り早急に修正する
失敗するテストスイートが合格した場合
- テストケースを特定する
- ログファイルと性能データを正しく生成する
- セットアップ・終了処理を検証する
タイプやレベルが異なるテストを実行する
- 機能テスト
- 性能テスト
- コンポーネントテスト
  など

テストスイートの確認

完全性
- すべてのテストケースに期待結果、テストデータが存在する
- 正しいバージョンのフレームワークとSUTがある

フレームワークの新フィーチャーに着目した新しいテストの検証

TASの新フィーチャーを使用する場合
- 細かく検証および監視を行う
- フィーチャーが正しく動作することを確認する

テストの再実行性の考慮

テストを繰り返して実行する場合
- テストの結果/判定は常に同じになる
信頼性がない場合
- アクティブな自動テストスイートから移動させる
- 個別に分析する
- 根本原因を調査する
何度も分析することになる
断続的な失敗
- 問題を分析する
  - テストケースの中にある場合
  - フレームワークにある場合
  - SUTの問題である場合
- ログファイルを分析する
  - テストケース、フレームワーク、SUTのもの
  - 問題の根本原因を特定する
- デバッグをする
根本原因を見つけるため、支援が必要になる
- テストアナリスト
- ソフトウェア開発担当者
- ドメインの専門家

自動テストスイートやテストケースに十分な検証ポイントが存在することの確認

期待結果を実現していることを検証する
証拠を提供する
- 各テストケースの開始時・終了時の記録
- 完了したテストケースのテスト実行ステータスの記録
- 事後条件が実現されているかの検証
  など

8 継続的な改善

8.1 テスト自動化の改善オプション

TASを改善する
継続的な保守作業以外にも多く存在する
効率性の向上
- 手動による介入を削減する
- 使いやすさの向上
- 機能の追加
- テスト活動のサポートの向上
  など
最大の価値をどのようにもたらすか

改善領域

スクリプティング
検証
アーキテクチャ
事前および事後処理
文書化
支援ツール

スクリプティング

スクリプティングアプローチ
- 単純な構造化アプローチ
- データ駆動アプローチ
- キーワード駆動アプローチ
新しい自動テストのために、現在のTASのスクリプティングアプローチを変更・向上させる
既存の自動テストがすべて更新される場合もある
- かなりの量の保守作業が発生する
スクリプトの実装に着目する

自動テストを統合する作業の中で、自動テストケース/ステップ/手順の重複を評価する

保守性を向上する
- 同じ操作手順を複数回実装しない
- 再利用できるように関数化し、ライブラリに追加する
- ライブラリ関数は、異なるテストケースで使用できるようにする
- 同一でなく似ている場合
  - パラメーター化が必要になる

TASとSUTのエラー回復プロセスを確立する

TASでエラーが発生した場合
- エラーから回復し、テストケースを継続する
SUTでエラーが発生した場合
- 必要な回復操作をする
  - 再起動など

スクリプト実行の待機（Wait）のメカニズムを評価し、最適なタイプが使用されるようにする

ハードコードによる待機
- 一定のミリ秒だけ待機する
- さまざまなテスト自動化の根本な問題となる
ポーリングによる動的な待機
- 所定の状態変化や行われる操作を確認する
- より柔軟で効率的である
- 必要な時間だけ待機する
  - テスト時間が無駄にならない
- プロセスに長い時間がかかる場合
  - ポーリング条件が true になるまで待機を続ける
  - タイムアウトのメカニズムを含める
    - 永久に待機を続ける
SUTのイベントメカニズムを監視する
- 他の2つよりも信頼性が高い
- テストスクリプトの言語でイベントの監視がサポートされている
- SUTからテストアプリケーションに対してイベントが発行される
- タイムアウトのメカニズムを含める
  - 永久に待機を続ける

テストウェアをソフトウェアとして扱う

テストウェアの開発と保守
- ソフトウェア開発の1形態である
- 優れたコーディング慣習を適用する
  - コーディングガイドラインの使用
  - 静的解析
  - コードレビュー
    など
テストウェアの特定部分の開発を、ソフトウェア開発担当者が行う

既存のスクリプトの改訂/削除について評価する

よく失敗する、保守コストが高いなど、問題を起こす
- 再設計する
付加価値がなくなった
- 削除する

テスト実行

夜間に終わらないことは例外的ではない
時間がかかる場合
- 並行
  - 常に可能とは限らない
    - 高価なシステムが使われている
- 分割
  - 定義した時間に実行する
カバレッジを分析する
- 重複が明らかにする
- 重複を削除する
- 実行時間を削減できる
- 効率性が上昇する

検証

新しい検証機能を作成する前に、すべての自動テストで使用でき一連の検証ができる標準的な手法を採用する
複数のテストをまたいだ検証アクションの再実装を避けることができる
検証手法が同一でなく似ている場合は、パラメーター化することで複数の種類のオブジェクトで機能を使用できる

アーキテクチャ

SUTの試験性を向上させる
アーキテクチャを変更する
- SUTのアーキテクチャ
- 自動化のアーキテクチャ
大きな改善となる
- 大幅な投資が必要になる
例
- テスト用のAPIを提供するためにSUTを変更する場合、TASも適切にリファクタリングされる
初期段階で考慮する
- 後工程で追加すると高価になる

事前および事後処理

標準のセットアップおよび削除タスクを提供する
事前処理（セットアップ）および事後処理（削除）と呼ばれる
自動テストごとにタスクを繰り返し実装する手間を省く
工数を削減できる
- 保守
- 実装

文書化

スクリプトが何をするか
どのように使うべきかなど
あらゆる形態の文書が対象
- TASのユーザー文書
- TASが生成するレポートやログ
  など

TASのフィーチャー

フィーチャー
- 詳細レポート
- ログ
- 他のシステムとの統合
  など
使用される場合
- 追加する
使用しない場合
- 複雑さを増す
- 信頼性と保守性が低下する

TASの更新とアップグレード

テストケースで使用できる新機能が提供される
故障が修正される
リスク
- 既存のテストケースに悪影響が生じる
展開する前
- 新しいバージョンのテストツールをテストする
  - 代表的なサンプルのテストを実行する
    - 異なるアプリケーション
    - 異なるテストタイプ
    - 異なる環境

8.2 テスト自動化改善の実装計画

変更には慎重な計画と調査が要求される
堅牢なTASの作成には多大な作業が必要となる
変更は信頼性や性能に幅広く影響する

テスト環境のコンポーネントの変更点を特定する

どのような変更や改善を行う必要があるか
- テストソフトウェア
- カスタマイズした機能ライブラリ
- OS
TASの動作方法に影響する
確実・効率的に動作し続けることを目標とする
変更は段階的に行う
- 限定的に実行する
  - TASへの影響を計測する
- 悪影響がないことを確認する
  - 変更を完全に実装する
完全な回帰実行
- 最終段階となる
- エラーが発見される
  - 根本原因を特定する

TASのコア機能ライブラリの効率性と有効性を改善する

新しい技法が発見される
- 機能のコードの最適化
- 新しいオペレーティングシステムライブラリの使用
  など
コア機能ライブラリに組み込む

同じ制御タイプで動作する複数の機能を統合の対象にする

GUIコントロールに関する情報
- 表示/非表示
- 有効/無効
- サイズ
- データ
  など
情報を利用する
- ドロップダウンリストから項目を選択する
- フィールドにデータを入力する
- フィールドから値を読み取る
コントロールに対して操作を行い、この情報を取り出す
極端に細分化されたものも、本質的に汎用的なものもある
例
- ドロップダウンリストに対してのみ動作する
  - 細分化された機能である
- パラメーターの1つとして関数を指定する
  - いくつかの機能と連動して動作する
  - 統合によって削減できる
  - 同じ結果を実現しつつ、保守要件を最小化する

TAAをリファクタリングしてSUTの変更に対応する

SUTの変更に対応するための変更が必要になる
SUTを支える機能を提供する
フィーチャーを拡張する場合
- アーキテクチャレベルで分析および変更を行う
追加スクリプトが必要になる場合
- 互換コンポーネントによって新しい自動テストに対応する

命名規約と標準化

変更が行われる場合
- 以前に定義された標準と一貫性を持たせる

SUTの改訂 / 削除のための既存のスクリプトの評価

変更や改善のプロセス
- 既存のスクリプトの使用方法、継続的な価値の評価も含む
例
- 複雑で実行に時間がかかる場合
  - それを複数の小さなテストに分割する
実行されないテストを削除対象とする
- 複雑度を低減させる
- 保守が必要なものを明らかにする

おわりに

誰かの参考になれば幸いです。

所要時間

内容を理解しながら整理したので、体感4ページ/時間くらいのペースでした。
正味66ページだったので、20時間弱だったかな。
各章に書かれた目安時間合計してみたら、19.5時間で、想定された通りだったようです。

ぼやき

まあまあページ数があったので、疲れました。
試験の受付が急に開始され、2か月限定で、FL必須なので、FLとってから、こちらを読み始めたので、忙しなかったなぁ。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up