Open9

【シラバス要約】JSTQB AL TAE

tateishitateishi

0. イントロダクション


テスト自動化エンジニアとは、テストについて汎用的で幅広い知識を持ち、テスト自動化という特定の領域について深く理解している者を言う。深い理解とは、組織および/またはプロジェクトが機能テストのために自動化ソリューションを設計、開発、保守する際に、方向付けとして使用できるテスト自動化理論とプラクティスについて、十分な知識を持っていることと定義される。

◆ 用語集
gTAA:汎用テスト自動化アーキテクチャ(Generic Test Automation Architecture)
   テスト自動化ソリューションの全体概要を提供する
GUI:グラフィカルユーザーインターフェース(Graphical User Interface)
SUT:テスト対象システム(System Under Test)
TAA:テスト自動化アーキテクチャ(Test Automation Architecture)
   TASのアーキテクチャを定義するためにgTAAを具体化したもの)
TAE:テスト自動化エンジニア(Test Automation Engineer)
   成果物であるTASの実装と、その保守や技術改善を含む、TAAの設計についての責任者
TAF:テスト自動化フレームワーク(Test Automation Framework)
   テスト自動化に必要な環境で、テストハーネスやテストライブラリなどの成果物を含む
TAM:テスト自動化マネージャー(Test Automation Manager)
   TASの開発と進化の計画および監督についての責任者
TAS:テスト自動化ソリューション(Test Automation Solution)
   TAAを具体化/実装したもので、テストハーネスやテストライブラリなどの成果物を含む
UI:ユーザーインターフェース(User Interface)

tateishitateishi

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

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

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

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

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

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

・テスト自動化アーキテクチャ(TAA)
 対象ソフトウェア製品のアーキテクチャと非常に密接に関連している。
 アーキテクチャがサポートする機能要件と非機能要件を明確にする必要がある。
 通常これが最も重要な要件となる。

・テスト対象システム(SUT)のテストのしやすさ
 =自動テストスクリプトの実装しやすさ
 テスト自動化エンジニア(TAE)は、簡単に自動テストできるSUTのモジュールまたはコンポーネントを特定し、そこから着手する必要がある
 →mablで言えば、Flowにしやすい機能から取り掛かる、など

・テスト自動化フレームワーク(TAF)
保守性の高いTAFを維持すること
それには以下のことが重要である

・ステークホルダーが品質の概要を把握できるようにレポート機能を実装する
 ・失敗したテストのトラブルシューティングを簡単にする
  →例えば、問題の切り分けをしやすくする
 ・環境やテストデータを制御しやすいように自動テスト専用のテスト環境を用意する
 ・自動テストの目的を明文化する
  →テスト観点、テストタイプ、テストの流れなどをテストケースにまとめる
 ・自動テストの個々のステップをトレースできるようにする
  →トレースログとか?
 ・自動テスト・テストケースの保守を簡単にする
  →自動テストケースを簡単に分析、変更、拡張できるようにする
   変更が必要になる項目数を最小限に抑える
   →保守作業はSUTに対して行う変更の規模に比例するのが望ましい
 ・変更によってテストが失敗した場合はすぐに修正し、自動テストを常に最新の状態に保つ
 ・導入の計画を立て、テストスクリプトを簡単に導入、変更、再導入できるようにする
 ・自動テストを定期的に見直し、不要な項目は削除する
 ・SUTの監視を行い、何か問題が発生した場合にTAFが速やかにエラーから回復するようにし、
  問題のあるテストケースをスキップして、次のケースからテストを再開できるようにする

また、以下のようなことは行うべきではない
 ・インターフェースの影響を受けやすい自動テストの作成
  →GUIやAPIの重要でない部分の変更により影響を受ける自動テスト
 ・データの変更による影響を受けやすい、または特定のデータ値に大きく依存するテストの作成
 ・コンテキストの影響を受けやすいテスト自動化環境の作成
  →OSの日付・時刻・多言語化のパラメーター、別のアプリケーションのコンテンツなど
   →環境を制御しやすいように、必要に応じてテスト用のスタブを使うのが望ましい

上記を参考に、TAAが整ったら今後何をしていくべきかを調査することが重要

tateishitateishi
  1. テスト自動化の準備

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

・SUTのインターフェース
 SUTを制御できるインターフェースをSUTが提供する必要がある
 →E2EであればUI、APIテストであればAPI、など

・サードパーティ製ソフトウェア
 SUTの内部や連携の対象に含まれるサードパーティ性のソフトウェアも考慮する

・干渉のレベル
 要するにSUTにどれだけ変更を加える必要があるか、ということ
 既存のUIのまま自動化する場合は干渉レベルが低い=自動化が難しい
 
・異なるSUTアーキテクチャ
 異なるSUTアーキテクチャには、異なるテスト自動化ソリューションが必要になる場合がある
 →例えば、COMテクノロジーを使う C++ で書かれたSUTは、Pythonで書かれたSUTとは異なるアプローチが必要

・SUTのサイズと複雑度
 小さく単純なSUT→単純なテスト自動化アプローチ
 大規模で複雑なSUT→柔軟度の高いテスト自動化アプローチ
 →複雑なSUTでも小さく単純なものから始めるのが適切な場合もあるが、
  これは一時的なアプローチとすべきである

上記の要因に関してはSUTが利用できるようになってから明らかになるが、ほとんどの場合テスト自動化の開発はSUTが利用可能になる前に開始すべきである

SUTがまだ存在しない場合でも、以下のようなところからテスト自動化計画を開始することができる
・要件(機能または非機能)が分かっている場合、その要件とそれをテストする手段から
 自動化の候補を選定し、自動化要件の特定やテスト自動化戦略の決定などを行う
・アーキテクチャと設計が作成されている間に、テストをサポートするソフトウェアインターフェースの設計に着手できる

◆ 2.2 ツールの評価と選定
TAEはツールの評価および選定プロセスの全体に関与するが、特に以下の作業を中心に行う

・ツールの情報収集、選定
・ツールベンダーの成熟度、サポートの評価
・目的やプロジェクトの制約に対するツール情報の分析
・投資対効果(ROI)の見積り
・ツールとSUTコンポーネントとの互換性の調査

○ 自動化ツール導入時のよくある問題点と対応策

◆ 2.3 試験性と自動化を考慮した設計
試験性を考慮したSUTの設計は、以下の要素によって構成される

・観測性: SUTは、システムの内部を把握できるインターフェースを提供する必要がある
・制御性: SUTは、SUTを操作するインターフェースを提供する必要がある
     →UI要素、関数呼び出し、通信要素(TCP/IP、USBプロトコルなど)、電気信号など
・明確に定義されたアーキテクチャ: すべてのテストレベルにおいて制御と可視性を実現し、明確でわかりやすいインターフェースを提供するアーキテクチャであること

また、テストをサポートするソフトウェアインターフェースの例には、以下のようなものがある

・最新のスプレッドシートによる強力なスクリプト機能
・スタブまたはモックを適用したシミュレート
・ソフトウェアインターフェース(スタブおよびドライバ)を用いたエラー条件のテスト
 →HDDを搭載したデバイスの例
  この HDDを制御するソフトウェア(ドライバ)には、HDDの故障や摩耗に対する
  テストを行う必要があるが、これを行うためにHDDが故障するのを待つのは、
  効率のよい・信頼性が高い方法とは言えない。
  そのため、HDDの欠陥や遅延をシミュレートするソフトウェアインターフェースを実装すれば、
  ドライバソフトウェアが正常に動作すること(エラーメッセージ、リトライなど)をテストできる
・利用できる UIがまだ存在しない場合は、別のソフトウェアインターフェースを使ってテストする
 →組込みソフトウェアの例
  デバイスの温度を監視し、温度が一定レベルを超えたときに冷却機能を起動する必要があるが、
  温度を指定するソフトウェアインターフェースを使えば、ハードウェアがなくてもテストできる

また、自動化の設計では、以下を考慮すべきである

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

tateishitateishi

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

3.1 gTAAの概要

・テスト自動化で繰り返し発生するタスク、質問への解答、問題への対処などの概念、手順、アプローチは、gTAAの基本となる
・gTAAは特定のTAS向けのTAAの元となり、具体化したものがTAAとなる
・TASはテスト環境、テストスイート、TAFで構成される
・TAFはテスト環境の具体化のサポート、ツール、テストハーネス、サポートライブラリを提供する

TASのTAAは、TASを簡単に開発、改良、保守できるように以下の原理に従うことが推奨される

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

・拡張性:オープン・クローズドの原則
 あらゆるTASコンポーネントは、拡張に対してオープン、変更に対してクローズドでなければならない
→既存の成果物を変更せず、新たに情報を追加するだけで対応できるようにする

・置換:リスコフの置換原則
あらゆるTASコンポーネントは、TASの全般的な振る舞いに影響を与えずに置換可能でなければならない。
→オブジェクト指向プログラミングにおいて、サブタイプのオブジェクトはスーパータイプのオブジェクトの仕様に従わなければならない

・コンポーネントの分離:インターフェース分離の原則
汎用的で多目的なコンポーネントよりも、具体的なコンポーネントの方が望ましい
→一つひとつのコンポーネントの役割・目的を明確にする

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

・gTAAは特定のベンダーに依存しないことが重要であり、TASを実現するいかなる具体的な手法、技術、ツールも規定しない

3.1.1 gTAAの概要

gTAAは以下の4つのレイヤーに分かれている

① テスト生成レイヤー
テストケースの手動または自動での設計をサポートし、テストケースを設計する手段を提供する

② テスト定義レイヤー
テストを定義する手段が含まれており、テスト条件、テストデータ、テストケース、テスト手順、テストライブラリ、およびそれらの組み合わせによって構成される

③ テスト実行レイヤー
テストを自動的に実行するテスト実行ツールと、記録およびレポート用のコンポーネントを提供する

④ テスト適合レイヤー
SUTのさまざまなコンポーネントやインターフェースを自動テストに適合させるために必要なコードを提供する。API、プロトコル、サービスなどを通じてSUTに接続するための各種アダプターを提供する

・TASにはこれらのレイヤーが存在することもあれば存在しないこともあるという点を理解する
・つまりテスト設計を自動化する場合はテスト生成レイヤーが、テストケースの作成などを自動化する場合はテスト定義レイヤーが必要になる
・また、テスト実行を自動化する場合はテスト実行レイヤーとテスト適合レイヤーの2つを利用する必要があり、この 2つを分離する必要はなく、テストフレームワークなどで同時に実現することも可能である
・TASは早い段階でプロフジェクトに導入することが理想なため、段階的に実装することや概念検証(PoC)を行うことが推奨される
・すべてのテスト自動化プロジェクトは、ソフトウェア開発プロジェクトとして認識、編成、管理する必要があり、専任のプロジェクトマネジメントも必要になる
・TAF開発のプロジェクトマネジメント(企業全体やプロダクト横断でのテスト自動化)とTASのプロジェクトマネジメント(具体的な一つひとつのプロダクトのテスト自動化)は分離できる

3.1.2 テスト生成レイヤー

テスト生成レイヤーでは以下のことを担当する

テスト設計

・テスト方針の定義
・テストケースの手動・自動設計
・テスト設計の文書化
・テストデータの作成・キャプチャ・導出
・SUT・SUTの環境・テストシステムのモデル化
・SUTやその環境を定義するモデルからのテストケースの自動生成(自動モデルベースドテスト)
・生成されたテストからモデル(要素)にさかのぼる機能
・テストスイート構造の編集
・テストケースとテスト目的・SUT要件の関連付け
・テスト生成アルゴリズムの構成・パラメーター化

3.1.3 テスト定義レイヤー

テスト定義レイヤーでは以下のことを担当する

テスト実装

・テストケース・テストデータ・テスト手順・テスト条件の定義・文書化
・テストケースを実行するためのテストスクリプトの定義
・テストライブラリへのアクセスの提供(キーワード駆動テストの場合など)
・テストデータの分類・制限・パラメーター化・具体化
・テストの一連の流れや振る舞いの明示、それらのパラメーター化・グループ化

3.1.4 テスト実行レイヤー

テスト実行レイヤーでは以下のことを担当する

テスト実行

・テスト準備の構成・設定
・テストデータ・テストケースから実行可能スクリプトへの変換
・テスト実行のためのSUTの前処理・後処理
・テストスイート(テストデータを含む一連のテストケース)の前処理・後処理
・テストケースの自動実行
・テストケースの実行結果の判断・記録・レポート
・テスト実行・フォールトインジェクション中のSUTの測定・記録・後続のテストの進行調整
・自動テスト実行時間の制御

3.1.5 テスト適合レイヤー

テスト適合レイヤーでは以下のことを担当する

テスト実装(の一部)

・テストハーネスの制御
・SUTの操作・監視
・SUT環境のシミュレート・エミュレート
・特定の技術によらないテスト定義と、SUTやテストデバイスに固有の技術要件との間の仲介
・SUTと連携するためのさまざまな技術固有のアダプター(プラグイン)の適用
・複数のテストデバイス・テストインターフェースへのテスト実行の分散管理、ローカル環境でのテスト実行

3.1.6 TASの構成管理

TASの構成管理には、以下が必要になる

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

・これらは、SUTのバージョンと一致した正しいバージョンでなければならない
・状況によっては以前のTASのバージョンに戻さなければならない場合があるが、これは適切な構成管理を行えば可能となる

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

・テスト自動化プロジェクトはすべてソフトウェアプロジェクトであるため、他のソフトウェアプロジェクトと同じプロジェクトマネジメントが必要になる
・TASの開発においては、TAEは確立された SDLC手法のすべてのフェーズのタスクを行う必要がある
・TAEは、ステータス情報(メトリック)を容易に抽出できるか、またはTASのプロジェクトマネジメントに自動的に報告されるようにTASの開発環境を設計しなければならない

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

・TASはテスト結果記録やテスト結果を含むテストレポートを容易に抽出できるか、SUTのテストマネジメント(人またはシステム)に自動的に提供される必要がある

3.2 TAAの設計

3.2.1 TAAの設計の概要

テスト自動化のアプローチの要件として考慮するべきこと

・どのテストプロセスを自動化対象とすべきか?
→テストマネジメント、テスト設計、テスト生成、テスト実装、テスト実行など

・どのテストレベルをサポートすべきか?
→テストレベルコンポーネントレベル、統合レベル、システムレベルなど

・どのテストタイプをサポートすべきか?
→機能テスト、適合テスト、相互運用性テストなど

・どのテストに関する役割をサポートすべきか?
→テスト実行者、テストアナリスト、テストアーキテクト、テストマネージャーなど

・どのソフトウェアプロダクト・製品ライン・製品ファミリーをサポートすべきか?
→実装されるTASの寿命や存続期間などを定義するため

・どの技術をサポートすべきか?
→SUTに使われる技術との互換性を考慮してTASを定義するため

TAAの各レイヤーを設計する際の考慮事項

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

・テスト生成を手動・自動のどちらにするか?

・どのテスト生成方法を選択するか?
→要件ベースド、データベースド、シナリオベースド、振る舞いベースドなど

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

・どのテスト選定戦略を選択するか?
→すべての組み合わせのテストを生成するのは不可能なため、現実的なカバレッジ基準、重み付け、リスクアセスメントなどを参考にして、テスト生成およびそれに続くテスト選定を行うべき

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

・どのテスト定義を選択するか?
→データ駆動、キーワード駆動、パターンベースド、モデル駆動

・どのテスト定義の表記方法を選択するか
→スプレッドシート
 ドメインに特化したテスト用の言語
 Testing and Test Control Notation(TTCN-3)
 UML Testing Profile(UTP)などを使用した表
 状態ベースの表記法
 確率的表記法
 データフロー表記法
 ビジネスプロセス表記法
 シナリオベースの表記法 など

・スタイルガイドやガイドラインを選択するか?
→高品質なテストを定義するため

・どのテストケースリポジトリを選択するか?
→スプレッドシート、データベース、ファイルなど

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

・どのテスト実行ツールを選択するか?

・インタプリタ型のアプローチとコンパイル型のアプローチのどちらを選択するか?
→通常、このアプローチは選択されたテスト実行ツールに依存する

・どの実装技術(プログラミング言語)を選択するか?
→C などの命令型
 Haskell や Erlang などの関数型
 C++、C#、Javaなどのオブジェクト指向型
 Python や Ruby などのスクリプト
 ツール固有の技術 など
→通常、この技術は選択したテスト実行ツールに依存する

・どのヘルパーライブラリを選択するか?
→テストデバイスのライブラリ、エンコーディング/デコーディングライブラリ など
→テスト実行を容易にする

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

・どのテストインターフェースを選択するか?
→GUI、CUI、API、プロトコル、シミュレーター、エミュレーター など

・どのテストインターフェース操作・観測ツールを選択するか?
・どのSUTモニタリングツールを選択するか?
・どのテスト実行トレースツールを選択するか?

抽象化によるメリットが得られる領域を特定する

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

・TAEはソフトウェア開発、品質保証、テストにおいて、以下についてステークホルダーと議論する必要がある
→TASのどの領域でどのレベルの抽象化を使用するか
 →例えば、テスト適合レイヤーやテスト実行レイヤーのインターフェースのうち、どれを外部化し、どれを形式的に定義し、TAAの存続期間にわたってどの安定性を確保する必要があるかなど
→抽象化したテスト定義が使われるのか、それともTAAはテスト実行レイヤーでテストスクリプトのみを使うのか
→テストモデルとモデルベースドテストアプローチを使用してテスト生成を抽象化するかどうか

・TAEは、機能性、保守性、拡張性のすべてにおいて、TAAの高度な実装と単純な実装との間にトレードオフがあることを認識しておく必要がある
→TAAでどの抽象化を使用するかを決定するにあたっては、これらのトレードオフを考慮する

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

・ROI(投資利益率)について詳細に検討することは TAM の責任範囲であるが、TAEはさまざまなテスト自動化のアーキテクチャやアプローチについて、タイミングやコスト、工数、利益に関する技術的評価や比較を行い、ROI分析に必要な情報を提供する必要がある

SUTに使われる技術やTASとの関係について理解する

・SUTのテストインターフェースへのアクセスは以下のレベルで実現される
→ソフトウェアレベル:SUTとテストソフトウェアが相互にリンクされる場合など
→APIレベル:APIが提供する関数/操作/メソッドをTASが呼び出す場合など
→プロトコルレベル:HTTP、TCPなどでTASがSUTと通信する場合など
→サービスレベル:Web サービスや RESTful サービスなどでTASがSUTのサービスと通信する場合など

SUT環境を理解する

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

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

・テスト環境の例とサンプル使用の例
→SUTとTASの両方の機能を備えたコンピューター
 →ソフトウェアアプリケーションのテストに有用。
→SUTやTASのそれぞれとネットワークで接続された個々のコンピューター
 →サーバーソフトウェアのテストに有用。
→SUTの技術的インターフェースを操作および観測する追加のテストデバイス
 →セットトップボックス(ブラウン管テレビの上に置き電波を受信する機器)などのソフトウェアのテストに有用
→SUTの操作環境をエミュレートするネットワーク接続テストデバイス
 →ネットワークルーターのソフトウェアのテストに有用
→SUTの物理環境をシミュレートするシミュレーター
 →組込み制御ユニットのソフトウェアのテストに有用

指定されたテストウェアアーキテクチャ実装の時間と複雑度

・TASプロジェクトにかかる作業の見積り方法の例
→類推による見積り
 →ファンクションポイント、3 点見積り、ワイドバンドデルファイ(専門家による見積り) など
→WBSの使用による見積りマネジメント
→Constructive Cost Model(COCOMO)などの係数見積り
→サイズベースの見積り
 →ファンクションポイント法、ストーリーポイント法、ユースケース分析 など
→グループ見積り
 →プランニングポーカー など

指定されたテストウェアアーキテクチャ実装の使いやすさ

・TASの使用性に影響を与えるもの
→TASが使いやすく、分かりやすい設計になっていること
→ソフトウェア開発、品質保証、プロジェクトマネジメントなどにおける他の役割に対して、TASがサポートできること
→TASのマニュアルが用意されていること
→TASがTAS自体の実用的なレポートを出力できること
→TASに対するFBなどに対して、反復的にアップデートできるような設計になっていること

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

・SUTに対して実行される一連のアクションをテスト手順として文書化・テストスクリプトとして実装する
・一連のアクションの他に、テストデータの定義や期待結果確認の操作も必要である
・一連のアクションを作成する際に使用できるアプローチは以下のようなものがある

① TAEが自動テストスクリプトに直接テストケースを実装する
→この選択肢は抽象化が不足しており、保守の負荷が増加するため最も推奨されない
→キャプチャ&リプレイ

② TAEがテスト手順を設計し、それを自動テストスクリプトに変換する
→この選択肢は抽象化されているが、テストスクリプトを生成する自動化が不足している
③ TAEがツールを使用してテスト手順を自動テストスクリプトに変換する
→この選択肢は、抽象化と自動テストスクリプト生成の両方を組み合わせている

→構造化スクリプティング、データ駆動、キーワード駆動

④ TAEが自動テスト手順を生成するツールを使用する・モデルから直接テストスクリプトを変換する
→この選択肢は、自動化の成熟度が最も高い
→モデルベースドテスト(プロセス駆動を含む)

・各選択肢はプロジェクトの状況に大きく依存する
・一般的に容易な選択肢ほど実装も簡単であり、まずは簡単な実装からテスト自動化を始めることが効率的な場合もある
→短時間で付加価値を提供できるが、保守性の低いソリューションになる懸念も

・上記①~④の概要・メリット・デメリットについて以下に記載する

キャプチャ&リプレイ

◆ 概要
後で実行できる自動テストスクリプトを生成するために、テストオブジェクトへの入力が手動テスト中に記録されるテスト自動化アプローチ

・自動化ツールを使用し、テスト手順に沿ってSUT上の一連の操作をキャプチャする
・キャプチャされる操作には、SUTに対する入力(インプット)のほかに、期待結果確認を行うためのSUTからの出力(アウトプット)を記録する場合もある
・キャプチャした操作をリプレイ再生する際には、以下のような様々な出力チェックを行う
→手動:テスト担当者はSUTの出力を監視して異常がないかを確認する必要がある
→完全、厳密:SUTはキャプチャの際に記録されたすべてのシステム出力を再現する必要がある
→チェックポイント:ある時点で選択されたシステム出力の指定された値のみがチェックされる

◆ メリット
・GUI・APIレベルでSUTに使用でき、導入初期の段階ではセットアップや使用が容易

◆ デメリット
・キャプチャした操作はキャプチャ時のSUTバージョンに強く依存するので、保守や拡張が難しい
→例えば、要素の位置が変更されただけだとしても、テストスクリプトに影響する可能性がある
・SUTが利用できるようになって初めてテストスクリプトの実装を開始できるため、適用時期が遅い

線形スクリプティング(=キャプチャ&リプレイのレベル1のスクリプティング技法)

◆ 概要
テストスクリプト内に制御構造を含まない単純なスクリプト技法

・手動テストをもとにスクリプトを作成する
・どのテストをどのように実行するかは、テストアナリストの暗黙知である場合がある
・記録されたスクリプトを編集して可読性を向上させたり(重要な場所に何が起きているかのコメントを追加するなど)、ツールのスクリプト言語を使用してさらにチェックを追加したりすることができる
・記録時にテスト担当者が行ったのと同じ手順を繰り返す形で再生して実行できる

◆ メリット
・自動化を始めるにあたって必要になる準備作業がツールの学習コストのみでほとんどない
・プログラミングスキルは必須ではない

◆ デメリット
・自動化に必要な作業量がテスト手順の数に依存することが多い
・スクリプトがモジュール形式ではないのでスクリプトの記述が冗長になり、保守性が非常に悪い
・プログラミングスキルが必要なため、学習コストがかかる

構造化スクリプティング

◆ 概要
再利用なスクリプト、またはその一部のライブラリを構築し活用するスクリプト技法

◆ メリット
・既存のスクリプトを再利用できるため、SUT変更時の保守や新規テスト追加時の拡張にかかるコストが大幅に削減できる

◆ デメリット
・プログラミングスキルが必要なため、学習コストがかかる
・作成するライブラリは文書化し、必要なスクリプトを容易に見つけられるように「分かりやすい命名規則にする」など適切に管理される必要がある

データ駆動テスト

◆ 概要
・テストスクリプトの実行に必要なテストデータおよび期待結果を含んだデータファイルを利用するスクリプト技法
・構造化スクリプティングをベースとする
・テストの入力データをテストスクリプトから切り離し、外部のデータファイルから取り込む
・テストを実行するために必要な一連の操作を含んだ再利用可能なテストスクリプトは「制御スクリプト」と呼ばれる

◆ メリット
・テストスクリプトの実装コストを大幅に削減できる
・テストが外部のデータファイルで記述されるので、データファイルを投入するだけでテストを実行でき、テスト担当者の負担・依存度を軽減できる

◆ デメリット
・TASが読み取れるようにデータファイルを管理する必要がある
・否定(準正常系)テストの観点が見逃される可能性がある

キーワード駆動テスト

◆ 概要
・データ駆動テストをベースとする
・主な違いは、以下の 2 点である
 ① データファイルは「テスト定義」ファイル(またはキーワードファイルなど)と呼ばれる
 ② 制御スクリプトは 1 つしかない
・テスト定義ファイルは、データ駆動テストのデータファイルより分かりやすい表現がされる
・テスト定義ファイルには高レベルな命令(キーワード)も含まれる
・キーワードは、ビジネスとシステムの高位レベルの相互作用(例えば注文の実行など)を表す
・実際にはそれぞれのキーワードには複数の詳細な手順が含まれているが、キーワード駆動テストでは「アカウントの作成」、「注文の実行」、「注文ステータスのチェック」など、ハイレベルなアクションだけでテストを定義できるようにする
・アサーションには特殊なキーワードを使うことができる。また、キーワードに通常の操作とアサーションの両方のステップを含めることもできる
・テスト担当者の責任範囲には、テスト定義ファイルの作成と保守が含まれる

◆ メリット
・テストスクリプトの実装コストを大幅に削減できる
・テストが「キーワード」で記述されるので、キーワードと関連するデータを使用してテストを記述するだけで自動テストが実装でき、テスト担当者の負担・依存度を軽減できる
・テストの複雑さがキーワード(構造化スクリプティングで言うライブラリ)で隠蔽されるので保守性が高く、SUTのインターフェースの複雑度を抽象化することができる

◆ デメリット
・キーワード駆動テスト技法をサポートしていないツールの場合、キーワードの実装は大きな負担となる
・小規模なシステムには実装のコストがメリットを上回る可能性がある
・適切でないキーワードは1回~数回しか使われないため、複数回利用される適切なキーワードが実装されるように設計を行う必要がある

プロセス駆動スクリプティング(機能ごとのモジュール分割的なイメージ)

◆ 概要
・キーワード駆動テストをベースとする
・シナリオ(SUTのユースケース=バリエーション)がスクリプトで構成される点がキーワード駆動テストと異なり、このスクリプトはパラメーターとしてテストデータを受け取るか、ハイレベルのテスト定義と組み合わされている
・このテスト定義は各操作間の相互関係を扱いやすい。例えば、
  機能テストで「注文の実行」→「注文ステータスのチェック」を行ったり、
  ロバストネステストで「注文の実行」を行わずに「注文ステータスのチェック」を行う
 などを決めることができる

◆ メリット
・スクリプトがシナリオベースで構成されることで、SUTのワークフローからテスト手順を定義することができる
・詳細なテスト手順を表すテストライブラリを使用し、ハイレベルのワークフローを実現できる

◆ デメリット
・ツールがプロセスのロジックをサポートしていない場合、SUTのプロセスの理解、プロセス指向スクリプトの実装が難しい
・適切でないキーワードを使ったプロセスは他のプロセスからあまり参照されないため、多くの関連するテストで活用される適切なキーワードを使ったプロセスとなるように設計を行う必要がある

モデルベースドテスト

◆ 概要
・「キャプチャ&リプレイ」「線形スクリプティング」「構造化スクリプティング」「データ駆動テスト」「プロセス駆動スクリプティング」を使用してテストケースを自動生成することを指す(テストケースの自動実行のアプローチではない)
・前述したTAAの各スクリプティング技法を抽象化した(準)形式モデルを使用する
・異なるテスト生成手法を使用して、各スクリプティング技法のフレームワーク用のテストを導出することができる
・参考:https://www.jasst.jp/archives/jasst07e/pdf/D4-1.pdf

◆ デメリット
・SUTのインターフェース、データ、振る舞いを抽象化してモデリングを行うには、モデルに関する専門知識が必要になる
・モデリングやモデルベースドテストの主要なツールがまだあまりない
・「テスト設計者の役割を確立する」など、テストプロセスの調整が必要になる
・テスト生成に使用するモデルがSUTの品質保証の主な成果物となるため、モデルの品質の担保や保守を行う必要がある

3.2.3 SUTの技術的考慮事項

◆ SUTのインターフェース
・SUTには内部インターフェース(システムの内部)と外部インターフェース(実際にユーザーが操作するもの、コンポーネントによって外部に公開されているもの)がある
・SUTのインターフェースはテスト手順による影響を受ける可能性があるため、TAAはこれらすべてのインターフェースを含めて制御、観測を行える必要がある
・SUTとTASとの相互作用をさまざまな詳細レベルでタイムスタンプを付けて記録する(ログを残す)
・試験性を考慮した設計を行う。具体的には、SUTがテストするために必要なテストインターフェースやテスト設備の可用性を検証するために、プロジェクトの初期段階におけるアーキテクチャ設計の際に、個々のテストにフォーカスをあてる必要がある

◆ SUTのデータ
・SUTは
 ・構成データを使ってインスタンス化、構成、管理などを制御する
 ・ユーザーデータの処理も行う
 ・他のシステムからの外部データを使用してタスクを完了させることもある
・SUTのテスト手順によっては、これらすべてのデータがTAAにより定義、構成、かつインスタンス化できる必要がある
・SUTのデータを扱う具体的な方法はTAAの設計で決まってくる。アプローチによっては、データをパラメーター、テストデータシート、テストデータベース、実データなどとして扱うことができる

◆ SUTの構成
・SUTは、異なるオペレーティングシステム、異なる対象デバイス、異なる言語設定など、さまざまな構成で導入される可能性がある
・テスト手順によっては、複数のSUT構成に対処するためにTAAを設計する必要がある
・指定されたSUT構成に伴わせて、テスト手順には異なるTAAのテスト設定(ローカル)や仮想テスト設定(クラウド)が必要になる場合がある。また、SUTのシミュレーター/エミュレーターが必要となる場合もある

◆ SUTの標準と法的設定
・互換性のある方法で設計できるように、TAAの設計はSUTの技術的側面に加えて法律や標準に関する要件を考慮しなければならない場合がある
・例えば、テストデータのプライバシー要件や、TAAのログ記録およびレポート機能に影響する機密性要件などがある

◆ SUTの開発に使用されるツールおよびツール環境
・SUTの開発における要件定義、設計、モデリング、コーディング、統合、導入などには様々なツールが使われる
・SUTの開発に使われるツールとの互換性、トレーサビリティ、成果物の再利用を実現するために、TAAで使うツールを考慮する必要がある

◆ ソフトウェアプロダクトのテストインターフェース
・プロダクトリリースの前に、すべてのテストインターフェースの削除を行わないことを強く推奨する。なぜなら、ほとんどの場合これらのインターフェースは最終的なプロダクトに影響を与えることなく、SUTに残しておくことができ、プロダクトに何か問題が起きた際の診断や保守リリースのテストに使用することができるからである。ただし、そのためにはインターフェースがセキュリティリスクとならないことを検証することが重要である
・必要があれば、開発担当者は開発部門のメンバー以外がテストインターフェースを使うことができないように無効化できる

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

◆ テスト実行制御要件
・TAAで必要とされる自動化のレベルによっては、TAAは対話形式のテスト実行、バッチ処理で行うテスト実行、完全に自動化されたテスト実行をサポートしなければならない場合がある

◆ レポート要件
・種類やフォーマットなどのレポート要件によっては、TAAはフォーマットやレイアウトが異なるテストレポートの固定、パラメータ化、定義をサポートできる必要がある

◆ ロールとアクセス権
・セキュリティ要件によっては、TAAがロールやアクセス権のシステムを提供しなければならない場合がある

◆ 確立されたツール群
・確立されたツール群を構成するツールでは、SUTプロジェクトマネジメント、テストマネジメント、コード・テストリポジトリ、欠陥追跡、インシデントマネジメント、リスク分析などがすべてサポートされている場合がある
・TAAは、ツール群の中の他のツールとシームレスに統合されているツール・ツールセットによってもサポートされている
・テストスクリプトは、SUTのプロダクトコードと同じプロセス・同じ方法で保存およびバージョン管理すべきである

3.3 TASの開発

3.3.1 TASの開発の概要

・TASの開発は、他のソフトウェア開発プロジェクトに類似する
 ex.) 開発担当者とテスト担当者によるピアレビューなどを含め、同じ手順やプロセスに従うことができる点など
・TAS固有の点として、SUTとの互換性と同期がある。この点は、TAAの設計(3.2節を参照)およびTASの開発で検討する必要がある
・TASがテストインターフェースを利用できるようにしなければならないなど、SUTはテスト戦略の影響を受ける

・本節では、ソフトウェア開発ライフサイクル(SDLC)をもとに以下の「TASのための基本的なSDLC」を使用して以下について説明する。
 ・TASの開発プロセスの特徴
 ・開発プロセスに関連するSUTとの互換性や同期の特徴
・これらの特徴は、SUT・TASの開発にあたって選択・実施されている他の開発プロセスにおいても同様に重要であり、適切に対応させる必要がある

・TASの一連の要件を分析および収集する必要がある。TAAで定義されているように(3.2節を参照)、この要件はTASの設計の指針となり、ソフトウェアエンジニアリングのアプローチにより、この設計がソフトウェアになる
・他のソフトウェアと同じように、TASについてもテストをする必要がある。通常、これはTASの基本的な機能をテストすることを指し、テスト後にTASとSUTは相互に影響するようになる
・TASを導入した後は、さらにテスト機能の拡張をしたり、SUTの変更に合わせてTASを修正・変更したりするために、TASを改善していくのが一般的であり、TASを改善するにはSDLCに基づき新たな TAS開発のサイクルに入っていくことになる
・SDLCにはTASのバックアップ、アーカイブ、廃棄などの運用に関連する作業については示されておらず、これらはTASの開発と同様、組織で確立された手法に従って行う必要がある

3.3.2 TASとSUTの親和性

◆ プロセスの親和性
・SUTのテストはSUTの開発と同期すべきであり、またテスト自動化を行う場合はTASの開発とも同期させる必要がある。よって、SUTの開発プロセス、TASの開発プロセス、テストプロセスの整合性をとることが望ましい
・プロセス構造、プロセスマネジメント、使用する関連ツールの面でSUTとTASの開発に親和性があると大きな利点となる

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

◆ 技術の親和性
・最初からTASとSUTとの間のシームレスな相互作用を設計および実装しておくのが良い
・TASにもSUTにも技術的ソリューションが利用できないなどの理由でそれが不可能だとしても、アダプターやラッパーなど何らかの仲介するものを使用することで、シームレスな相互作用を実現できる可能性がある

◆ ツールの親和性
・例として、例えば要件マネジメントや課題マネジメントに同じツールを使用している場合、TASとSUTの開発に関する情報交換や調整が容易になる

3.3.3 TASとSUTの同期

◆ 要件の同期
・TASの要件は、大きく次の2つのグループに分けることができる
 ① ソフトウェアベースのシステムとしてTASの開発に対処する要件
  これにはテスト設計、テスト仕様、テスト結果分析などのためのTASの機能要件が含まれる
 ② TASを用いてSUTのテストに対処する要件
  これらはテスト要件と呼ばれ、SUTの要件に対応してTASがテストする全ての機能や特性を反映する

・SUTやTASの要件が更新されるときは必ず両方の一貫性を検証し、テスト要件の中ですべてのSUTの要件が定義されていることが重要である

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

◆ 欠陥追跡の同期
・欠陥はSUTに関連するもの、TASに関連するもの、要件・設計・仕様に関連するものなど様々である
・両方の開発には関連性があるため、片方で欠陥を修正するともう片方に影響が及ぶ可能性があり、欠陥追跡と確認テストはTAS・SUTの両方で行う必要がある

◆ 改善の同期
・SUTとTASの両方とも、新規機能の組込み、機能の無効化、欠陥の修正、環境の変更(SUTとTASは片方がもう片方のコンポーネントとなっているため、片方だけへの変更も含まれる)に対応するために改善できる
・SUTとTASのどちらかに変更が適用されるともう片方が影響を受ける場合があるので、変更のマネジメントはSUTとTASの両方で行う必要がある

SUTとTASの開発プロセス間を同期させる2つのアプローチ

◆ アプローチ1 SUTとTASそれぞれの開発サイクル内の2つのフェーズで同期されるアプローチ
① TASの分析はSUTの設計に基づき、SUTの設計はSUTの分析に基づく
② SUTのテストには導入済みのTASを使用する

◆ アプローチ2 手動と自動両方のテストを使用したハイブリッドアプローチ
① TASの分析はSUTの設計と手動テストの両方に基づく
② SUTのテストには導入済みのTASと手動のテスト両方を使用する

3.3.4 TASの再利用性の構築

・TASの再利用とは、他のプロダクトで(TAAの任意のレイヤーでの)TAS成果物を再利用することを指す
・他のプロダクトとの間でTAS成果物に関連性があるときに再利用する
・再利用可能なTAS成果物の例は以下のとおりである
 ・モデル化されたテストの目標、テストシナリオ、テストコンポーネント、テストデータ(の一部)
 ・テストケース、テストデータ、テスト手順、またはテストライブラリ自身(の一部)
 ・テストエンジン、テストレポートフレームワーク
 ・SUTのコンポーネントやインターフェースのアダプター

・再利用の方向性はTAAが定義されるときに既に確定しているが、TASの開発サイクルの中でも以下によって再利用性を高めることができる
 ・TAAに従うか、必要に応じて更新する
 ・TAS成果物を文書化することによって分かりやすくし、新しい状況に組み込めるようにする
 ・すべてのTAS成果物の正確性を保証し、新しい状況での使用が促進されるようにする

・再利用性を高める設計は主にTAAの設計に関することだが、TASの開発サイクル全般を通して再利用性を向上させるための保守や改善を続けていくべきである
・再利用の実現、再利用による付加価値の測定や提示、既存のTASの再利用促進には、継続的な検討と作業が必要である

3.3.5 様々な対象システムのサポート

・TASは様々な構成のSUTをテストできるのが望ましく、「様々な」とは以下のような例を指す

◆ すべてのテストレベル共通で適用
 ・SUTコンポーネントの数や相互連携
 ・SUTコンポーネントが実行される環境(ソフトウェア・ハードウェア両方)
 ・SUTコンポーネントを実装するために使われる技術、プログラミング言語、OS
 ・SUTコンポーネントが使用するライブラリやパッケージ

◆ おもにコンポーネント・結合テストレベルに適用
 ・SUTコンポーネントを実装するために使用するツール

・TASが様々な構成のSUTをテストする能力はTAAの定義の際に決定される
・TASはSUT間の技術的な差異に対応する機能を実装し、それらの機能やコンポーネントを管理しなければならない
・SUTの多様性に比例して多様化するTASに対応するには以下のような方法がある
 ・バージョン管理・構成管理を使用し、お互いに適合するバージョンや構成に調整する

・TASの可変性の設計は主にTAAの設計に関することだが、TASの開発サイクル全般を通して可変性を向上させるための保守や改善は続けていくべきである
・可変性の選択肢や形態を修正、追加、削除するには、継続的な検討と作業が必要である

tateishitateishi

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

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

・TASの実装と展開には、「パイロット(PoC、概念検証、実証試験)」と「導入」という 2 つの主要な作業が関連し、これら 2 つの作業を構成するステップは、TASの種類とさまざまな状況によって異なる

・パイロットでは以下のステップについて考慮する
 ・適切なプロジェクトの選定
 ・パイロットの計画、実行、評価

・導入では、以下のステップについて考慮する
 ・最初の対象プロジェクトの選定
 ・選択したプロジェクトへのTASの導入
 ・計画した期間の後のプロジェクトのTASの監視および評価
 ・他の組織/プロジェクトに展開

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

通常、ツールの実装はパイロットプロジェクトから始まる
パイロットプロジェクトの目的は以下のとおりである

・TASを使用することによって意図した目的を実現できることを確認する
・TASに関する理解を深める
・TASが既存のプロセス、手順、ツールにどのように適合するかを確認し、変更が必要になる点を特定する
 →通常は、既存のプロセス/手順に適合するようにTASを変更することが一般的である
 →どうしても既存のプロセス/手順をTASに合わせて変更する必要がある場合、少なくともプロセス自体を改善するべきである
・テスト担当者のニーズに一致するように自動化のためのインターフェースを設計する
構成管理や変更管理との統合を含むTASやテストのアセットの使用、管理、格納、保守の標準的な方法を決める
 →ファイルやテスト成果物の命名規約の決定
 →テストスイートのライブラリの作成と部品の定義 など
・テスト自動化を監視するための使用性、保守性、拡張性などの指標(メトリクス)とその測定方法を選定する
・期待するメリットが妥当なコストで実現可能かどうか(投資対効果、ROI)を見極める
 →TASを使ってみた後で期待を見直すこともある
・必要なスキルを把握し、そのうち既に持っているスキルと足りていないスキルを判断する

適切なプロジェクトの選定

パイロットプロジェクトは、以下のガイドラインに基づいて慎重に選択すべきである

・重要なプロジェクトを選ばない
 →TASの導入によって遅延を引き起こすなど、何らかの影響を及ぼす可能性がある
・単純なプロジェクトを選ばない
 →プロジェクトが単純だと、導入に必要な情報もあまり得られない
 →単純なプロジェクトで導入に成功しても、複雑・大規模なプロジェクトで成功するという判断材料にはならない場合が多く、適切な候補ではない
・選定プロセスに必要なステークホルダー(マネジメント層を含む)を関与させる
・パイロットプロジェクトのSUTは、他のプロジェクトの基準となるようにする
 →例えば、SUT内に代表的なGUIコンポーネントを含むなど
・パイロットは通常の開発プロジェクトとして扱い、計画の作成、予算・リソースの確保、進捗の報告、マイルストーンの定義などを行う
TASの導入に携わるメンバー(責任者)のリソースに留意する。他のプロジェクトでリソースが求められているとしても、作業の時間を十分に確保できるようにする
 →特にメンバーが共有リソースの場合のマネジメントは重要である
・TASがベンダーツールではなく内製ツールである場合、その開発担当者を導入作業に含める必要がある

パイロットの実行・評価

・TASからツールベンダーが説明した・期待どおりの機能・効果が得られたかを評価する。もしそうでない場合、その原因をツールベンダーやステークホルダー間でコミュニケーションを取りながらなるべく早く特定する必要がある
・TASが内製ツールの場合、開発担当者は不足している機能があれば追加で実装し、導入を支援する
・TASと既存のプロセスがうまく連携できているかを評価する
・評価にはステークホルダー全員が関わるようにする

4.1.2 導入

パイロットの評価が完了し上手くいきそうだと判断できた場合、TASの導入に移行する
導入は以下の点に注意しながら進める

・段階的に展開する
 →他の組織に段階的に展開することで
  ・新規ユーザーのサポートにかかる工数を分散できる
  ・ボトルネックの可能性を特定しやすくし、問題が生じる前に対処できる
  ・ライセンスの追加・管理がしやすい

・TASの使用に適したプロセスの適合と改善を行う
 →様々なプロジェクトでTASを導入するとそれぞれ異なるプロセスでTASを使用していくため、TASを既存のプロセスに合わせて変更したり、逆に既存のプロセスをTASに合わせて調整したりする必要がある

・新規ユーザーに対し、トレーニングやコーチングを行う
 →新規ユーザーには、新しいTASを使用するためのトレーニングやコーチングを行う
 →トレーニングはハンズオンやワークショップの形式で行う
 →トレーニングはユーザーが実際にTASを使用する前に提供するのが理想である

・TASの利用ガイドラインを定義する
 →新規ユーザーのサポートにおける質問を削減するため、TASの利用に関する、ガイドライン・チェックリスト・FAQなどを作成しておく

・使用状況に関する情報収集の方法を定義・実装する
 →TASの使用状況を監視するため、使用状況に関する情報を自動的に収集する方法を確立しておく
 →全体的な使用状況だけではなく、TASの特定の機能についての使用状況の情報も得られることが理想的である

・TASの使用、メリット、コストを監視する
 →一定期間TASの使用状況を監視することで、TASが実際に使用されているかどうかを把握する。この情報は「どのくらいの時間を節約できたか」「どのくらいの問題を防げたか」などのビジネスケースの分析にも使用できる

・TASのテストチームと開発チームを支援する

・各チームから得られた教訓を集める
 →TASを使用した各チームと評価・振り返りミーティングを行い、得られた教訓を集める
 →TASの使用法を改善するために各チームは情報提供を行い、またその重要性や必要性を理解することでさらに情報が集まりTASの改善に繋がる

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

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

・TASの導入は、各プロジェクトの開発フェーズに大きく依存する
・一般的に、新しいTASの導入は「プロジェクトの開始時」「コードフリーズ期間」「スプリント終了時」などの「マイルストーン到達時」に行われる
 →テスト・修正を伴う導入作業に時間・労力を注力できるようにするため
 →「TASが上手く動作しない」など、テスト自動化プロセスに影響が及ぶリスクを軽減するため
・ただし、「TASに修正が必要な重要な問題がある」「TASが実行されている環境のコンポーネントを置き換える必要がある」などの場合は、SUTの開発フェーズとは切り離して考え、導入を行う

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

技術的な問題がプロダクト・プロジェクトのリスクにつながる可能性があり、一般的に見られる技術的な問題には以下のようなものがある
過度な抽象化(キーワード駆動など)により、実際に何が起きているのかが理解しづらくなる
データ駆動テストにおいて、データテーブルが大きすぎる・複雑すぎて扱いにくい
・TASがOSライブラリなどのコンポーネントに依存しているが、それらがSUTのすべての対象環境で利用できるとは限らない

一般的に見られる導入プロジェクトのリスクには以下のようなものがある
・TASのソースコードを保守する適切な人員を確保するのが難しいなどの要員の問題
SUTの新しく追加された機能によって、TASが正常に動作しなくなる
SUTの変更に対応するTASのアップデートが遅れてしまう
・自動化の導入がスケジュール通りに進まない
・TASで追跡が必要な特定のオブジェクトをキャプチャできない場合がある

TASプロジェクトで失敗する可能性が考えられる場面には以下のようなものがある
・異なる環境へのTASの移行
・対象環境へのデプロイ
・SUTにおける新規機能の実装

このようなリスクに対処するために利用できるリスク軽減戦略が多数存在する。以下では、これらについて説明する

・ベンダーツールか内製ツールかによらず、TASにはそれぞれのソフトウェアライフサイクルがある
・TASは他のソフトウェアと同じくバージョンコントロールを行い、ドキュメント化をする必要がある
 →そうしない場合、TASの一部を導入したり、連携して動作させたり、一部の環境で動作させたりすることが非常に難しくなる
・TASには明確で使いやすい導入手順が必要である
 →この手順はTASのバージョンに依存するため、同じくバージョンコントロールの対象とする

・TASの導入には2つのフェーズがある
 1. 初期導入
 2. 保守(TASが既に存在し、保守が必要な場合)

・初めてTASを導入する前に「その環境でTASが動作すること」「予期せぬ変更の影響を受けないこと」「テストケースを更新および管理できること」を確認する必要がある
・TASの導入にあたり、TASとそのインフラの両方を保守しなければならない

初回導入の場合は、以下のステップが必要になる
・TASを動作させるインフラ(環境)の定義・構築
・TAS・インフラ(環境)の保守手順の確立
・TASが実行するテストスイートの保守手順の確立

初回導入に関連するリスクには、次のようなものがある
テストスイートの合計実行時間が、テストサイクルで計画した実行時間よりも長くなる
 →この場合、次に予定されたテストサイクルが始まる前に、テストスイートを実行を完了させる十分な時間を確保することが必要である
・「データベースのセットアップ」「初回ロード」「サービスの起動/停止」などの「テスト環境のインストール・構成」に関する問題が発生する
 →「テスト環境での自動テスト実行に必要な事前条件を設定しておく」など、効率的に導入できる方法を考え確立しておく

TASの保守には、以下のステップが必要になる
・新しいバージョンのTASと古いバージョンのTASを比べ、変更点を評価する
・新機能・リグレッションの両方についてTテストを行う
・新しいバージョンのTASに合わせてテストスイートを変更する必要があるか確認する

TASの保守を行う際、以下の点に考慮する
・継続的なTASの改善を行い、TASの更新を本番環境に適用する
・更新したTASを本番環境に適用する前には、他のソフトウェアと同じようにテストを行う
・適用前のテストでは「修正・追加した機能のチェック」に加え、「更新したTASでテストが実行できること」「レポートが送信できること」「性能の問題や機能のリグレッション(デグレード)が起きていないこと」などを確認する
・場合によっては、新しいバージョンのTASに適用させるためにテストスイート側の変更が必要になることもある

TASの更新には、以下のリスク・リスク軽減活動がある
◆ リスク
・更新したTASに欠陥や性能の問題がある
 →リスクとメリットの分析を行い更新するかの判断を行う
  「見つかった問題 > 更新するメリット」の場合:
   →更新をしない、または次のバージョンのTASまで更新を保留する
  「見つかった問題 < 更新するメリット」の場合:
   →TASを更新する。ただし、既知の問題を記載したリリースノートを作成し、テスト自動化エンジニアおよびステークホルダーに通知していつ問題が修正されるかを見積るようにする

◆ リスク軽減活動
・更新したTASに対応したテストスイートの変更
 →テストスイートに必要な変更を行い、適用する前にテストする
・更新したTASに対応したテストスタブ、ドライバ、インターフェースの変更
 →テストハーネス(スタブやドライバ)に必要な変更を行い、TASに導入する前にテストする
・更新したTASに対応したインフラの変更
 →変更が必要なインフラのコンポーネントの評価・変更を行い、更新したTASを使用してテストする

4.3 テスト自動化の保守

・TASの保守では部品化、拡張性の確保、分かりやすさ、信頼性の高さ、テストの可用性が重要である
・TASは他のソフトウェアシステムと同様、改善し続けなければならない
・TASの保守では新しいシステムへの適応、新しいソフトウェア環境のサポート、新しい法律や規制への準拠などにより、TASの動作の信頼性と安全性を高め、TASの寿命や性能も最適化する

4.3.1 保守の種類

保守は運用中のTASで行われ、システムの変更、移行、廃止によって発生する
このプロセスは、以下のカテゴリに分けられる

・予防保守
 →TASによる以下のサポートをするための変更を行う
  ・様々なテストタイプでのテスト
  ・複数のインターフェースでのテスト
  ・複数のバージョンのSUTでのテスト
  ・新しいSUTでのテスト

・修正保守
 →運用中のTASを保守しながらTAS使用におけるリスクを軽減するための定期的な保守を行う

・完成度を高めるための保守
 →性能、使用性、堅牢性、信頼性など、非機能的な問題を修正するためTASを最適化する

・適応保守
 →市場に新しいソフトウェアシステムを投入する際、TASが以下へ正しく適応するための変更を行う
  ・TASによるサポート
  ・新しい法律、規制、業界固有の要件への準拠
 →法律や規則に準拠する場合は、固有の規則や要件、場合によっては監査要件を伴う保守が必要になるのが一般的である
 →統合ツールが更新されて新しいバージョンが作成される場合、ツールの統合エンドポイントを保守して機能を保つ必要がある

4.3.2 スコープとアプローチ

保守はTASのすべてのレイヤー・コンポーネントに影響を及ぼす可能性のあるプロセスであり、その範囲は以下の要因によって決定される。

・TASの規模と複雑度
・変更の規模
・変更のリスク

・TASの変更にあたっては影響度の分析を行い、その変更によってシステムにどのような影響が及ぶかを判断する必要がある
・TASの運用を確実に継続させるため、変更の影響度合いによっては段階的に変更を導入し、それぞれのステップ後にテストする必要がある
・仕様や文書が古いと、TASの保守が困難になる場合がある

テスト自動化の主な成功要因は時間効率であるため、以下のような手法を用いてTASの保守を行うことが重要である

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

サードパーティコンポーネントやその他のライブラリの保守については、以下の点を考慮する

・TASでのテスト実行の際にサードパーティ製のコンポーネントやライブラリを使用・依存することは非常に多いため、サードパーティ製の部分はすべて文書化し、構成管理の対象とする
・サードパーティ製のコンポーネント・ライブラリの変更や修正の際に必要な、それら(サードパーティ製ツール開発企業)の連絡先や問題の報告先を把握しておく
・サードパーティ製のコンポーネント・ライブラリを使用する際のライセンスについては文書化されており、「コンポーネントが変更可能か」「どの程度変更できるか」などの情報を把握しておく
・サードパーティ製の各コンポーネント・ライブライブを常に最新の状態に保つため、それらの更新や新バージョンについての情報を継続して取得する必要がある

命名規約やその他の規約については、以下の点を考慮する

テストスイート・TASの可読性・理解容易性・変更可用性を高めるため、命名規則やその他の規約(コーディング規約等)を導入する
 →これにより、保守プロセスにかかる時間を短縮でき、リグレッション(デグレード)や誤った修正が発生するリスクを最低限にとどめ、もし発生した場合にも容易に解決することを可能とする
 →新しいメンバーがテスト自動化プロジェクトに参画しやすくなる

・命名規則では変数、ファイル、テストシナリオ、キーワード、キーワードパラメーター等の名前を対象とする
・その他の規約ではテスト実行の前提条件・事後処理、テストデータの内容、テスト環境、テスト実行のステータス、実行結果記録、レポート等を対象とする
・命名規則やその他の規約は、テスト自動化プロジェクトの開始時にすべて同意され、文書化されていることが望ましい

文書化については、以下の点を考慮する

・テストシナリオ・TASについて十分な最新の文書が必要となる
・各文書は作成後、継続的に保守(アップデート)する必要がある
・テストツールのコード設計書は自動または半自動で文書化することができる。一方で、設計、コンポーネント、サードパーティ製のコンポーネント・ライブラリとの統合、依存性、導入手順等については誰かが文書化する必要がある
・開発プロセスの一部に文書作成を含めることは適切な(良い)方法である
・文書の作成・更新が行われるまでは、タスクは完了したとはみなされない

トレーニング教材については、以下の点を考慮する

前提としてトレーニング教材とは、TASの機能仕様、設計およびアーキテクチャ、導入・保守、使用方法(ユーザーマニュアル)、実例や練習問題、使い方に関するヒントなどを組み合わせたものである
・TASの文書化が十分行われている場合、それらをTASのトレーニング教材のベースとして使用できる
・トレーニング教材の保守(定期的な見直し)の作業はTASのチームメンバーが担当し、SUTのイテレーションの終盤(スプリントの終了時など)で行われることが多い

tateishitateishi

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

5.1 TASメトリクスの選択

・テスト自動化戦略とTASの有効性・効率性を監視するために使用できるメトリクスを説明する
 →これはSUTを監視するために使用するSUT関連のメトリクスとは異なり、プロジェクト全体のテスト自動化メトリクスである
・テスト自動化のメトリクスを使用することで、TAM・TAEはテスト自動化の目的に対する進捗を追跡し、TASに対して行われた変更の影響を監視することができる

TASのメトリクスは、「外部」と「内部」の2つのグループに分割できる

・外部メトリクス:他の作業(テスト活動など)に対するTASの影響を測定するために使用される
・内部メトリクス:目的達成におけるTASの有効性・効率性を測定するために使用される

◆ 外部TASメトリクス
・自動化のメリット
・テスト自動化の初期構築工数
・自動テストの結果分析工数
・自動テストのメンテナンス工数

・故障と欠陥の比
・自動テストの実行時間
・自動テストケースの数
・成功結果・失敗結果の数
・誤った失敗結果・誤った成功結果の数
・コードカバレッジ

◆ 内部TASメトリクス
・ツールスクリプトのメトリクス
・自動テストコードの欠陥密度
・TASコンポーネントのスピードと効率性

上記のそれぞれについて、以下で説明する

自動化のメリット

・コスト(一定期間に関与した人員の数)は目に見えやすいため、TASのメリットを測定し記録することは重要である
 →ROIを算出するためのメトリクスを取得するのは有効な手段の1つ
・テスト以外の作業に携わっている人員は「コストの全体像」はイメージできるが、「達成できた際のメリット」はなかなかイメージできない場合がある

メリットの測定はTASの目的によって異なり、例えば以下のようなものがある

・手動テスト・リグレッションテストの削減工数
・テストの増加数
・テストケース全体に対する自動テストケースの比率
 →ただし、自動化率100%を目指すと失敗する可能性が高い
・テストにおける要件・機能・構造などのカバレッジの増加数(率)
・TASによって早期発見できた欠陥数
 →欠陥の早期発見による平均的な効果が分かる場合、これを計算して予防されたコストの合計を導き出すことができる
・TASによって発見できた欠陥のうち、手動テストでは見つからなかったと思われるものの数(信頼性の欠陥など)

・テスト自動化によって節約できた工数は、その他の種類のテスト(探索的テストなど)に充てることができ、これらの追加テストで見つかった欠陥も間接的にはTASのメリットと見なすことができる

テスト自動化の初期構築工数

・テストを自動化するのにかかる工数は同じテストを手動で実行するコストよりも高くなることが多く、テスト自動化の利用を拡大する上で障害となる場合がある
・自動テストを実装するコストはテストの内容、スクリプティングアプローチ、テストツールの習熟度、環境、TAEのスキルレベルなどの様々な要素に依存する
・規模が大きく複雑なテストの自動化は短く単純なテストの自動化よりも工数がかかるため、テスト自動化の構築コストの計算には平均構築時間が使われることがある
 →これは同じ機能を対象としたテストやあるテストレベルのテストなど、特定のテストセットの平均コストを考慮することによりさらに精度を上げることができる
 →つまり、他の似たようなテストの自動化工数を参照するということである
・テスト自動化工数の1つのアプローチとして、テストを手動で実行する際に必要になる工数を「EMTE(Equivalent Manual Test Effort)」とし、その係数として自動化のコストを表現する方法がある
 →例えば、テスト自動化に手動テスト工数の2倍の時間がかかるとすると、テスト自動化の工数は「2EMTE」と表すことができる

自動テストの結果分析工数

・自動テスト実行での失敗したテスト結果を分析することは、手動実行での失敗したテスト結果を分析するよりも大幅に複雑になることが多い
 →手動テストでの失敗までの手順・事象は、テスト実行者が認識していることが多いためである
 →「3.1.4 節 設計レベル」や「5.3 ~ 5.4 節 レポートレベル」によって緩和できる可能性がある
・この測定値は、「失敗したテストケースあたりの平均」または「EMTEの係数」として表現できる
 →特にEMTEの係数は、自動テストの複雑度や実行時間が大きく異なる場合に適している

・自動テストの結果分析においてSUT・TASの結果の記録は重要であり、以下のような情報を提供する記録機能が望ましい
 ・SUT・TASの記録が同期されている
 ・TASの期待される振る舞い⇔実際の振る舞いの記録(の比較)
 ・TASでの実行されたアクションの記録

・また、内部エラーをすべて記録し、クラッシュダンプやスタックトレースも利用できるようにするためSUTは手動・自動問わず実行されるすべてのアクションを記録すべきである

自動テストのメンテナンス工数

・自動テストのメンテナンス工数は非常に大きくなる可能性があり、場合によってはTASによって実現できるメリットを上回ってしまうこともある
 →多くのテスト自動化プロジェクトが失敗する大きな原因の1つ
 →そのため、「メンテナンス工数を削減する必要がある」「メンテナンス工数が制限なく増加することを防ぐ必要がある」などの場合は、メンテナンス工数の管理・監視が重要になる
・メンテナンス工数の測定値は「SUTの更新ごとにメンテナンスが必要になるすべての自動テストの合計」で表現できる
 →また、更新された自動テストごとの平均工数、EMTEの係数としても表現できる
 →関連する指標として、メンテナンス作業が必要なテスト数や比率がある
・自動テストのメンテナンス工数が算出できる場合、その情報は「特定の機能を実装するかどうか」「特定の欠陥を修正するかどうか」を判断する際の材料となる
・SUTの変更と合わせて、そのテストケースのメンテナンス工数も考慮する

故障と欠陥の比

・自動テストでは失敗したテスト結果の分析工数が多くかかる。多くの自動テストが同じ理由、1つの欠陥のために失敗するのは無駄が多いため、少ないテストで多くの機能をカバーすることが重要である
 →同じ欠陥が原因で失敗した自動テストの数を測定することで問題の発生箇所を明らかにできる
 →これは、自動テストの設計と実行する自動テストの選択によって解決できる

自動テストの実行時間

・自動テストの実行時間は最初の段階では重要でないこともあるが、自動テストの数が増えるにつれて重要なメトリクスになってくる
 →開発の規模が大きくなってくると、実行時間の長さが開発へのFBの遅さに繋がってくることもあるので注意

自動テストの数

・自動テストの数はテスト自動化プロジェクトの進捗を示すために使用できる
 →ただし、単純な自動テストの数だけでは、多くの情報を明らかにできないことは理解しておく。例えば、自動テストの数が増えたからと言って単純にテストカバレッジが増加したことを示すわけではない

成功結果・失敗結果の数

失敗したテスト結果についてはその原因を分析し、SUTの欠陥による失敗なのか、環境やTAS自体の問題などの外部要因による失敗なのかを判断する必要がある

誤った失敗結果・誤った成功結果の数

・失敗した原因などがSUT自体ではなくTASやテストケースにある場合、テスト結果の分析には特に多くの時間がかかる場合がある
・「誤った『失敗』のテスト結果」が発生するとTASの信頼性が低下するため、誤警告の数(および無駄になる可能性のある工数)を低く抑えることが重要である
 →いわゆる「テストの安定性を上げる」「Flaky(不安定な)テスト結果を減らす」のが重要である
・さらに、「誤った『成功』のテスト結果」はさらに危険なものであり、誤った成功とは「テスト自動化がSUTに存在する不具合を特定できなかった状態」、つまり不具合を見逃してしまったということである

・誤った結果の原因の例としては、以下のようなものがある
 ・結果の検証(アサーション)が適切に行われなかった場合
 ・無効なテストオラクル(具体的な期待結果の元ソース)が使用された場合
 ・テストケースが誤った結果を期待していた場合
 ・テストコードの欠陥
 ・不安定な状態のSUTによる予想できない振る舞い(ネットワーク遅延、セッションタイムアウトなど)
 ・テストフック(テスト自動化のためにカスタマイズしたSUT⇔TAS間のインターフェース)の干渉

自動テストのコードカバレッジ

・コードカバレッジは単体テストだけのものではなく、ハイレベルな自動テストスクリプト(例えば、E2Eテストなど)でも測定することができる
・カバレッジが十分であることを示す絶対的な比率は存在せず、相当単純なソフトウェアアプリケーションでない限りコードカバレッジが100%になることはないが、カバレッジが十分であるほど機能追加時のデグレード見逃しのリスクは軽減でき、良い状態であるというのは一般的な共通認識である
・コードカバレッジはSUTの状態を示す働きもあり、例えばSUTに機能を追加した際にコードカバレッジが低下した場合、対応するテストケースが自動テストスイートに追加されていないことを示している

自動テストコードの開発におけるメトリクス

・自動テストスクリプト開発におけるメトリクスは多数あり、そのほとんどはSUTのプロダクトコードに関するメトリクスと同様である
 →コードの行数(LOC、Line of code)やサイクロマティック複雑度(IF文などのプログラムの分岐の数による不具合の混入確立の大小を表す指標)は、肥大化・複雑化したスクリプトに対して再設計(リファクタリング)が必要かどうかを判断する際に使用できる
 →コメントと実行ステートメント(コード1行分の命令)の比率は、スクリプトの文書化や注釈の程度を示す際に使用できる
 →スクリプト標準への準拠違反の数は、どの程度標準に準拠しているかを示す際に使用できる

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

・自動テストコードはソフトウェアであり、欠陥を含むという点でSUTのプロダクトコードと変わらないため、「自動テストコードはSUTのプロダクトコードより重要度が低い」ということはない
 →よって、優れたコーディングの慣習・標準を適用し、その結果をコードの欠陥密度などのメトリクスで監視すべきである
 →構成管理ツールなどを用いれば、これらの収集は容易になる

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

・同じ条件下で自動テスト実行時間に違いが出ている場合、これは許容範囲外のシステム性能のバラつきを示している可能性があり、負荷が増加するとさらに悪化する可能性があるため調査が必要である
・TASはSUTの性能を妨げないように、十分な性能を発揮できる必要があり、特に性能がSUTの要件にとって重要な場合は、その点を考慮してTASを設計する必要がある

傾向メトリクス

・多くのメトリクスとともに重要なのが傾向(測定値の経時変化)の監視である
 →例えば「今回のリリース時における平均メンテナンスコスト」が「直近2回のSUTリリースにおける平均メンテナンスコスト」よりも多いことがわかれば、増加の原因を判断するために調査を行い、その傾向を改善することができる

各メトリクスの測定コストはできる限り低く抑える必要があるが、多くの場合収集とレポートを自動化することで比較的容易に実現できる

5.2 測定の実施

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

・多くのテスト自動化ツールで使用するスクリプト言語は、各テストの実行前~実行中~実行後に情報を記録することによって測定・レポートを行っている
・各メトリクスの傾向を明らかにできるように、前のテスト実行結果を考慮した分析機能を備えた測定・レポート機能が必要である

・通常、テストを自動化するには「テスト実行」と「検証(期待結果の確認、アサーション)」の両方を自動化する必要がある
・期待結果の確認はテスト自動化ツールで行うのが一般的であり、その結果としてレポートされる情報のレベルや粒度を考慮する必要がある
・期待結果の確認ではテストのステータス(成功、失敗など)を正確に判断することが重要である
 →ステータスが「失敗」の場合、その原因について「スクリーンショット」「TASが出力したログ」などの調査に必要な詳しい情報が必要になる
・テストの実行結果と期待結果で予測される違い(例えば実行されるたびに変わる「日付や時間」「広告の種類」など)を無視しつつ、予測されない違いを明らかにする比較を行うためには、「AIによる機械学習」などツール側のサポートが役立つ

その他のサードパーティツールとの統合(スプレッドシート、XML、文書、データベース、レポートツールなど)

・自動テスト実行後に得られた情報を他のツールで使用する場合、これらのサードパーティツールに適切な形式で情報を提供することができ、多くの場合、これはテスト自動化ツールの既存の機能(レポート用フォーマットでのエクスポート機能など)によって実現できる
・他のプログラムと互換性のある形式(「.xlsx」「.docx」「.html」「.xml」など)で出力できるようにレポートをカスタマイズする必要がある場合もある

結果の視覚化(ダッシュボード、図、グラフなど)

・テスト結果やテストの進捗はその視認性を高めるため、図やグラフなどを使って視覚化すべきである
 →例えば、テストの結果を「成功(Pass):緑色」「失敗(Fail):赤色」で示すことにより、どのテストが失敗しているのかを一目で把握することができる

5.3 TAS・SUTの結果記録

・結果記録の作業には「テスト自動化自身」と「SUT」の両方の結果記録作業が含まれる
・テストの結果記録は、問題の分析をする際に頻繁に使われる情報源である
・TASの結果記録の作業は、「TAF」or「テストケース自体」のどちらが情報を記録するのかは重要ではなく、状況に依存する

本節では、TAS・SUTに分類されるテスト結果記録の作業例を示す

TASの結果記録の作業に含まれるもの

・現在実行中のテストケースと、その開始時間および終了時間
・テスト実行のステータス
 →失敗はログファイルで容易に特定できる
 →フレームワーク自体にもこの情報があり、ダッシュボード等を通して確認できる
 →テスト実行のステータスは、「成功」「失敗」「TASのエラー」のいずれかである場合が多い
 →「TASのエラー」の結果は、問題がSUTではない場合に使用される
・「タイミング情報」など、ハイレベルなテスト結果記録の詳細(重要なステップのログ)
・サードパーティツールとテストケースによって明らかになったSUTについての動的な情報(メモリリークなど)
 →実行結果や動的測定の失敗は、問題が検知された際に実行されていたテストケースとともに記録する
・信頼性テスト/ストレステストの場合は何度もテストを実行する必要があるため、テストの実行回数を記録する
・テストケースにランダムな部分がある場合(テスト中にランダムに生成される値など)、乱数/選択値を記録する
発生した不具合について同じ操作ステップ/タイミング/事象を正確に再現するために、テストで実行するすべての操作についてログ情報を記録する
 →これらの操作ログ情報は、エンドユーザーが発見した不具合を再現させて調査する際にも使用できるように、SUT自体に記録することもできる
・不具合の調査に使用できるよう、テスト実行の際にスクリーンショットなどの視覚情報を保存することができる
・テスト実行時に不具合が発生した場合、TASは不具合の調査に必要なすべての情報が保存されており、それらの情報を利用できることを保証する
 →関連するクラッシュダンプ(プログラムが異常/強制終了した直前のメモリの内容)やスタックトレース(プログラムが直前に実行していた関数やメソッドなどの実行履歴)がある場合、TASは安全な場所に保存する
 →上書き可能なログファイル(SUTのログファイルには循環バッファが使われることが多い)についても、後の分析で利用できるように安全な場所にコピーする。
・記録された情報の種類を区別する方法として色分け(エラーは赤、進捗情報は緑など)などをするとよい

SUTの結果記録の作業に含まれるもの

・SUTで不具合が発生した場合、不具合の調査に必要なすべての情報を記録する
 →日付、タイムスタンプ、不具合の発生元の位置、エラーメッセージ など
・SUTはすべてのユーザー操作を記録することができ、それらを使用してエンドユーザーが発見した不具合を開発側で調査し再現を試みることができる
・SUTの起動時には各ソフトウェア/ファームウェア(BIOS)のバージョン、SUTの構成、OSの構成などの構成情報をファイルに記録する

これらの様々な記録情報は、TAS⇔SUT同士のログファイルの関連性やタイムスタンプなどの情報により簡単に検索できるべきである

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

・テスト結果記録は、テストの実行手順や操作、その結果について詳細な情報を提供するが、それだけではすべてのテスト実行結果の全体像を適切に把握することはできないため、レポート機能が必要である
・テストが実行されるたびに簡潔なレポートを作成して公開するために、再利用可能なレポート生成機能を使用する

レポートの内容

・テスト実行レポートは実行結果の概要、テスト対象システムの情報、テストを実行した環境等の情報が分かるサマリーを含み、それを各ステークホルダーに提供する
・どのテストがどのような理由で失敗したかを明らかにするために、テストの実行履歴とその責任者(通常はテストの作成者、または最終更新者)を特定することが重要である
・テストの責任者は失敗の原因を調査して関連する問題を報告する。そして問題の修正をフォローアップしながら、正しく修正されたことを確認する
・テスト実行レポートはTAFコンポーネントの不具合を調査する際にも使用される

レポートの公開

・テスト実行レポートはWebサイトへのアップロード、メーリングリストへの送信、テストマネジメントツールなどのツールへのアップロードなどを行うことでステークホルダー全員に公開される
 →実運用においては、ステークホルダーにメールやチャットで定期的にレポートを送信する仕組みを導入することが多い
・SUTの問題がある部分を特定したり、頻繁に起こるリグレッションの内容を含んだテストの統計を集計できるように、レポートの履歴を保管したりすることも考えられる

tateishitateishi

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

6.1 自動化の移行条件

・手動テスト→自動テストに移行する際、手動テストの作りが「自動化に適した場合」と「自動化に適さない場合」で自動化の難易度が異なる
 ・自動化に適した場合:入力値や期待結果、操作手順などをそのまま再利用できる
 ・自動化に適さない場合:テストの多くの部分を作り直す必要がある

すべてのテストは自動化できるとは限らず、またすべてを自動化するべきでもない
 →テスト自動化の8原則「手動テストはなくならない」
・アジャイルなどでは、新しいテストの初回の実行から自動化できるとは限らず、手動となる可能性がある
・テスト自動化への移行には以下の2つのフェーズがある
 ① 既存の手動テスト→自動テストへの初回の移行
 ② ①の後の新しい手動テスト→自動テストへの継続した移行

・テストの中には、自動化することによって初めて効果的に実行できるタイプのテストがある
 →信頼性テスト、ストレステスト、性能テストなど

・テスト自動化を行うと、インターフェースのないアプリケーションでもAPIテストが実施できる
 →最悪手動でも実施はできるが現実的ではない
 →これにより、まだ手動でのシステムテストを行うことができない早い段階でテストを開始でき、欠陥を早期に検出することができる

テストによって「手動テスト」と「自動テスト」のどちらで実装・実行すべきか判断する必要があり、判断基準としては、以下のようなものがある
 ・テストの実行頻度
 ・自動化の複雑度
 ・ツールの適合性とサポート
 ・テストプロセスの成熟性
 ・SDLCにおける自動化の合目的性
 ・自動化環境の持続可能性
 ・SUTの操作特性

テストの実行頻度

リリースサイクルごとに定期的に実行されるテスト、例えばリグレッションテストのようなテストは自動化の候補となりやすい
 →一般的にリリースが頻繁に行われ、それに対応するテストサイクルが多いほどテストを自動化するメリットは大きい
 →よってリグレッションテストは投資収益率(ROI)が高く、プロダクトコードがリグレッションを起こすリスクの軽減にも繋がる
 →逆にテストの実行頻度が半年~1年に1回程度などの低頻度の場合は自動化の効果は薄く、またSUTなどのメンテナンス等を考慮すると手動で行う方が効率が良い場合が多い
・リリースごとに新規に実装する機能のテストを自動化すれば、以降のリリースでそれらのテストをリグレッションテストの一部として継続して再利用できる

自動化の複雑度

手動で実行すると手間や時間がかかり、エラーも起きやすい複雑な手順を繰り返すテストを自動化すると効果が非常に高い
・一方で、以下のような場合は自動化の効率性が落ちるため、自動化を避けた方が良い
 ・テスト自動化とSUTの互換性がない
 ・自動化を行うために、多くのプロダクトコードとAPIを新規に開発・修正しなければいけない
 ・複雑な外部システム・外部端末との連携がある(例えば多要素認証など)
 ・ユーザビリティテストや探索的テストなど、そもそも自動化に向かないテスト

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

・テスト自動化ツールの種類には、大きく分けて以下の3つがある
 ・商用ツール
  商用ベンダーから提供され、一般的に専門エンジニアによるサポートなど有償/無償サポートが存在する場合が多い
 ・オープンソースツール(OSS)
  OSSはオンラインフォーラムなどのサポートを提供していることがあり、そこから情報を得たり質問を投稿することで問題を解消したりすることができる
 ・内製ツール
  社内で開発されたテスト自動化ツールは、基本的に既存のスタッフがサポートを提供する
・テストの大半が自動化できたとしても最も重要なテストが自動化できない場合もあり、テストツールの適合性は過小評価すべきではない

テストプロセスの成熟性

例えばアジャイル開発で繰り返しのイテレーションの中で自動テストを実装/運用/管理/メンテナンスしていく場合、その各プロセスを構造化し、ルール等を決めて毎イテレーション繰り返し可能なものにしていくことが重要である

SDLCにおける自動化の合目的性

・昨今のプロダクトのSDLCはとても長く、その中で繰り返し機能の追加・改修が行われ、かつ開発スピードは速いため、テスト自動化を導入するためには以下の点に留意する
 ・開発初期はSUTの変更が多く自動テストの実装効率が悪い
 ・逆に、開発終盤のSUTに関してはそもそも自動化導入の意味がほとんどない
 ・変更が安定し、コア機能が実装されたタイミングで自動テストの実装も始めることが望ましい
・ただし、既存の機能を保持して異なるアーキテクチャで新規開発されるSUTの場合は、自動テスト環境やテストデータの再利用が可能である場合が多い

環境の持続可能性

・自動テスト環境は、SUTの変更に対して以下のように柔軟に対応できる必要がある
 ・新規機能の追加などの容易性
 ・問題を素早く特定して修正できること
 ・テストスクリプトのメンテナンス性
 →これらの特徴は、gTAAの全般的な設計や実装として不可欠な部分である

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

・自動テスト実装の容易性にはSUTの操作特性や視覚特性に依存するため、それがない場合には自動テストの実装容易性や保守性が低下する
(「2.3 試験性と自動化を考慮した設計」参照)

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

・自動テストの実装に入る前に、そのメリットと成果について評価を行いROIを算出する

・自動化に移行する前には以下の点について検討・整理しておく
 ・ツールの選定
 ・テストデータとテストケースの正確性の確認
 ・テスト自動化の範囲の検討
 ・テストチームの教育
 ・メンバーの役割りと責任の設定
 ・開発担当者とTAEの連携方法の確立
 ・手動テスト→自動テストへ移行する際の評価
 ・テスト自動化のレポート方法の決定

ツールの選定

・先行検証環境で選定されたツールについて以下のような確認を行う
 ・検証環境/自動化開発環境上でのTASの動作確認
 ・サービスパックやリリースアップデートの反映
 ・適切なインストール構成の選択(アドイン、プラグイン等を含む)

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

・テストを自動化した際に確実に予測したROIを出すために、明示的な入力データ、ナビゲーション、同期化、検証を行う

テスト自動化の範囲の検討

・テスト自動化を始める際は、まずはコアな機能など領域を絞ってパイロットプロジェクト(PoC)を行い、そこから学んだ教訓を今後の時間の見積りや技術的な検証に活かしていくというように、限定された範囲から始めるのが重要
・そのためには、自動化するテストケースを適切に選択する必要がある。基準としては「自動テスト実装の難易度が比較的低い」「大幅な工数削減など高い効果が出る」といったものがあり、当てはまるテストとしては以下のようなものがある
 ・リグレッションテスト、スモークテスト
  →実行頻度が高く、実装も比較的容易
 ・信頼性テスト
  →実行頻度が高く、複数のステップで構成されるため手動では明らかにしにくい問題も顕在化できる
 ・SUTの中でも特に重要な機能のテスト
  →優先度が高いことがチームの中で既に認識できているため、実装を進めやすい

・上記のことを意識してテスト自動化を開始し、PoCで工数削減などの成果を出し、徐々にテスト自動化の活動をエクスパンションさせていく

テストチームの教育

・効果的なテストを実現するには様々なスキル/背景を持つメンバーでチームを構成することが望ましいが、テストが自動化へとシフトするにつれ、逆に役割はそれぞれに特化されたものになる
 →そのため、テストチームの構成を変えることは自動化の成功にとって不可欠である
 →また、予定されている変更について早い段階でチームを教育することが必要である

メンバーの役割りと責任の設定

・テスト自動化は全員が参画できる活動にすべきだが、全員が同じ役割を担うということではない
 例えば以下のように、それぞれのスキルや経験に合ったメンバーをアサイン/教育すべきである
 ・自動テストの設計/実装、自動テスト環境の保守
  →プログラミングスキル、エンジニアリングスキル
 ・自動テスト結果レポートのレビュー
  →ドメイン知識、ドメインに対する専門性
・上記のような役割は開発担当者が担う場合もあるが、開発担当者はTAFやテストライブラリの構築/実装に集中することができるよう、テストケースの実装は引き続きテスト担当者が行うべきである
 →ただし、自動テストは技術者であっても非技術者であっても、同じように使用できる環境としなければならない
・最終的に、組織のマネジメント担当者がテスト自動化の成功に必要な役割の種類と責任を明確に理解していなければならない

開発担当者とTAEの連携方法の確立

・テスト自動化の成功には、TAEと開発担当者の連携が必要不可欠である
 TAEと開発担当者の連携には、例えば以下のようなものがある
 ・開発担当者→TAEへの開発手法やツールに対するサポートや技術情報の提供
  →例えば、システム設計や開発コードが標準に従っていない場合や、開発担当者が見慣れないライブラリやオブジェクト、内製ツールや極端に新しいツール、自動化ツールと適合性のないサードパーティ製ツールなどを使用している場合に、それらに対する情報の連携が必要である

手動テスト→自動テストへ移行する際の評価

・手動テスト→自動テストへと移行する際に、実装しようとしている自動テストが本当に既存の手動テストと同じ内容の確認が行えているかを検証する必要がある
 →評価の結果、さらに効果的な自動テストの実装を実現するために、既存の手動テストを再設計する場合もある
  →これが"自動テスト設計"と呼ばれるものの一部である

テスト自動化のレポート方法の決定

・TASが自動生成できるレポートには以下のようなものがある
 ・自動テストや自動テストの各ステップの結果(Pass/Fail)のステータス
 ・テストの実行時間/実行回数/実行タイミングなどの結果、およびそれらの推移/統計
 ・TASの全般的な性能結果
  →これらの結果から自動テストの運用、およびTASの運用が正常に行われているか可視化することも重要である

6.2 リグレッションテストを自動化する際に必要な手順の特定

・リグレッションテストは「実行頻度が高い」「機能の追加に伴いテスト数が増え続ける」等の理由から、自動化するテストにうってつけである(むしろ、自動化しなければならない)

・リグレッションテストを自動化する際は、以下の点について検討・整理する必要がある
 ・テストの実行頻度
 ・テストの実行時間
 ・「確認観点/内容」「確認手順/データ」の重複
 ・各テスト間の相互依存性
 ・テスト実行の事前条件/事後条件
 ・SUTに対する自動テストのカバレッジ測定
 ・自動テスト実装前の手動テストの実行確認
 ・大規模な自動リグレッションテストの運用

テストの実行頻度

・"「実行頻度が高い」「機能の追加に伴いテスト数が増え続ける」「既に手動テストとしてテストケースが実装されている場合が多い」という理由から、リグレッションテストは自動化するためのテストとして最良である"

テストの実行時間

・自動化するテストを選定する際の1つの指標として、「実行時間が長い」「手順が長い」テストの自動化が考えられる
 →それにより、"テスト全体の実行時間が短くなり、テストをより効率的に運用することができる"

「確認観点/内容」「確認手順/データ」の重複

・手動テストケース内での「確認内容/観点の重複」「確認手順/データの重複」という2つの点から、以下の点に意識して自動テストの実装を行う
 ・1つの自動テストとして実装し「確認内容/観点の重複」を減らす
 ・データや処理を共通化し、各自動テストで使い回して「確認手順/データの重複」を減らす
  →"その際、ある程度テストのカテゴリやグループを意識し、どのようにまとめて整理すればより効率的に自動テストを実装することが出来るかを検討する"

各テスト間の相互依存性

・"一連のテストシナリオを実行する場合、1つのテストが他の複数のテストに影響/依存する場合が頻繁にあり、それを考慮した自動テストの設計/実装が必要である"

例)「新しく注文を行い『注文 ID』が発行されること」というテストがあった場合
  以下のようなテストは、上記の「注文ID」に依存している
   ① 新しい注文がシステムに正しく表示されること
   ② 注文の変更ができること
   ③ 注文の削除ができること

テスト実行の事前条件/事後条件

・"テストを自動化する際には、手動テストで行っていた「テストを行うための事前条件(事前準備)」「テストを行った後の事後条件」を自動テストの「前処理(Setup/Precondition)」「後処理(Teardown/Postcondition)」として実装しておく必要がある"
 →テストの前処理には、例えば「テストで使用するデータの準備/選択」「パラメーターの初期化」などがある
 →テストの後処理には、例えば「使用したテストデータの削除」「パラメーターの初期化」などがある

SUTに対する自動テストのカバレッジ測定

・SUTに対して自動テストのカバレッジは広く、深くするように設計するのが理想である
 また、コードカバレッジツールを使用して自動テストの実行を監視し、それらを定量的に測定することもできる
 →リリースが繰り返されるとともに自動リグレッションテストの数も増え、それに比例してカバレッジも向上するが、それを定量的に測定することが自動テストの価値を測定する有効な手段となる

自動テスト実装前の手動テストの実行確認

・手動テストを自動テストとして実装する前に、元となる手動テストが正しく動作することを検証することが重要である
 →例えば以下のような理由から手動テストが正しく実行されない場合は、これらの問題を解消してから自動テストを実装する必要がある
  ・手動テストの内容が現在の(更新された)SUTと合っていない
  ・無効なデータを使用している
  ・更新によりSUTに欠陥が含まれている

大規模な自動リグレッションテストの運用

・リグレッションテストは気がつけば数が多くなりがちで、自動リグレッションテストを夜間や週末のうちに実行できないケースもある
 →上記のような場合、以下のような対応を行うことで自動テストを運用する
  ・複数のSUTを使用した同時並列実行
  ・一部だけを段階的に実行
   →長期間継続的に実行し続けて、最終的にリグレッションテスト全体を実行する
  ・リスク分析による絞り込みでの部分実行
   →例えば、最近変更した機能に深く関連する機能のリグレッションテストのみ実行する、など

6.3 新規機能のテストを自動化する際に考慮する要素

一般的には、新しい機能のテストケースの方が自動化しやすい。
これは、実装がまだ完了していない、あるいは始まってすらいないためである。
テストエンジニアは、テスト自動化ソリューションによって、効果的かつ効率的にテストできるようにするためには新機能に対して何が必要かを、自分の知識を使用して開発担当者やアーキテクトに対して厳密に説明できる。

・SUTに新規機能を追加する際、以下の点について考慮する
 ・新規機能をTASでテストしやすいようにTAEは開発担当者に説明し要望を出す
  →"例えば「要素にテスト用のカスタムデータ属性を付与してもらいテスタビリティを確保する」など"

・新規機能に対するテストを実装する際、既存のTASで自動テストを実装できるかどうかテスト担当者とTAEが連携して確認する
  →既存のテストツール、アプローチ、アーキテクチャ、サードパーティ製ツールなどの互換性を確認
   →例えば、キーワード駆動アプローチを使用している場合、新規機能に対応するための追加キーワードの開発や既存のキーワードの改修などが必要
  →TASに何か変更を加える場合、変更内容が既存のTASの機能(コンポーネントなど)に影響がないかを確認し、また変更内容を文書化する必要がある
   新規機能が別のクラスやオブジェクトなどで実装される場合、自動テスト側でもコンポーネントの更新や追加が必要になることがある

・新規機能に対して既存の自動テストを実行し、影響が出ているかどうかを確認する
 ・新規機能に対する自動テストの実装、および影響のあった既存の自動テストの改修は全体スケジュールに組み込み、計画的に実施する
  →"自動テストのメンテナンスやリファクタリングは継続的に日々行う"

6.4 不具合修正確認テストを自動化する際に考慮する要素

・"不具合修正後に実施する確認テストは、その対象の不具合が修正されていることの確認のためスコープは狭く、また対象の不具合は以降の開発でも構成管理に問題などにより再発する可能性があるため。既存の自動リグレッションテストに追加するのが効果的である"
・自動確認テストについて各情報(テストの実装時間、実行時間など)を追跡すると、対象の不具合の修正にかかった工数などを確認できる
・確認テストを行う際、不具合修正の副作用として新しい不具合の発生や過去の不具合の再発が起きていないことも併せて確認するために、リグレッションテストが必要になる場合もある

tateishitateishi

7 TASの検証

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

・テスト自動化チームは自動テスト環境が期待通りに動作していることを検証する必要があり、これらはテストの自動化を始める前などに行われる
・自動テスト環境のコンポーネントの確認には、以下のようないくつかの確認観点がある

TASのインストール・セットアップ

・異なるSUTや自動テスト環境でTASのインストール・セットアップに信頼性と再現性を持たせるため、必要な各構成ファイル、設定ファイル、ライブラリ、アドイン等はGitHub等のSCMで管理するのが良い
 →TASのバージョン管理や構成管理が容易になる
 →TASの環境構築後、各環境で動作に目に見える差異が発生しない場合は管理が上手くいっている

・GitHubリポジトリでのリソースの管理方法、およびTASのバージョンアップ等の管理方法は、開発での管理方法・プロセスと同様にすべきである

自動テストの動作確認・修正

・「問題なく動くはずの自動テストが失敗する」or「失敗するはずの自動テストが成功する」場合、以下のようなアプローチで早急に原因を特定し修正する必要がある
 ・正しく動作していたバージョンの自動テスト、およびその前処理・後処理のコンポーネントを確認する
 ・タイプやレベルが異なる自動テスト(機能テスト、性能テスト、コンポーネントテストなど)ごとに動作を確認する

・"TASを構成する各コンポーネントについて深く理解し文書化することで、SUTの変更に対してどのコンポーネントに影響があるのか容易に理解できるようになる"

内部/外部のシステム・インターフェースに対する接続性の確認

・TASのインストール後、実際にTASを使用する前に内部/外部のシステムやインターフェースなどに接続できることを確認する
 →そのため、一連の動作チェックや運用前の事前条件を管理しておく

SUTとTASの干渉関係

・多くの場合、SUTとTASの設計・構成は高いレベルでの互換性を実現するために密接に関係しているが、これに関しては以下のようなマイナス面のリスクもある
 ・TASがSUTと同じ環境にある場合とない場合とでSUTの動作が異なる
 ・SUTを手動で操作する場合とTASで操作する場合とでSUTの動作が異なる
 ・SUTに対してTASを実行するときにSUTのパフォーマンスが下がる

・SUTとTASの干渉関係は、選択された自動テストアプローチによって異なり、例えば以下のようなものがある。

・SUT側が提供するインターフェース(API)使用してSUT⇔TASの接続を行う場合、エンドユーザーには使用されないAPI(テスト用API)を用意したり、想定する使用方法とは異なるAPIの使い方をするかのうせいがあるため、結果的に干渉のレベルは高くなる
  一方で、APIを経由して自動テストを行うのは非常に簡単でコストが低く、潜在的なリスクを理解している限りはAPIを使用してのテストを行うのが効率的である

・SUTとTASの干渉のレベルが高いと、通常の手動でのSUTの操作では起こりえない不具合などが起こる可能性がある
 →これはTASの信頼性の低下にも繋がるため、「同事象を手動で再現させられるか確認する」などの調査や分析を早急に行う必要がある

TAFのコンポーネントの確認

・TASの確認と同様に、TAFのコンポーネントも個々に検証し確認する必要がある。
・TAFの確認には機能テストと非機能テスト(性能、資源効率性、使用性など)が含まれる
 ・機能テスト
  例えば、オブジェクトのテストを行うコンポーネントは、正しく機能するように幅広いオブジェクトのクラスに対してテストを行う必要がある
  また、エラーログやレポートを出力するコンポーネントは、テスト結果の正確な情報を提供しているかを確認する
 ・非機能テスト
  非機能テストには、TAFのパフォーマンス、メモリリークなどの問題を起こす可能性のあるシステムリソースの使用状況、TAFの内外のコンポーネントとの相互運用性などを確認する

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

・自動テストスイートについて、振る舞い、完全性、一貫性、継続的実行などを確認するために様々な観点で検証を行う必要がある
・自動テストスイートの確認には、以下のようないくつかの確認観点がある

「想定外の失敗」or「想定外の成功」がある自動テストの動作確認

・「問題なく動くはずの自動テストが失敗する」or「失敗するはずの自動テストが成功する」場合、以下のようなアプローチで早急に原因を特定し修正する必要がある
 ・正しく動作していたバージョンの自動テスト、およびその前処理・後処理のコンポーネントを確認する
 ・タイプやレベルが異なる自動テスト(機能テスト、性能テスト、コンポーネントテストなど)ごとに動作を確認する

テストスイートの確認

・テストスイートの完全性(すべてのテストケースに期待結果、テストデータが存在すること)を確認する

TASの新規機能の動作確認(を行うテスト)

・テストで初めてTASの新規機能を使用する場合、その機能が正しく動作することを確認する

自動テストの安定性の確認

・自動テストを繰り返し実行する場合、テストの動作/結果は常に同じになるべきであり、そうならない場合は「テスト結果が不安定(Flaky)なテスト」と言える
・"テストの動作や結果が不安定なテストは、毎回の実行ごとにその問題の分析にコストがかかってしまうため、一度運用中の自動テストスイートから除外して個別に分析・調査を行う必要がある"
・"「自動テストそのものの作りが悪い」「SUT側のパフォーマンス低下による読み込み時の問題」「ネットワークトラフィックの遅延」など、動作や結果が不安定になることには様々な原因がある"
 →これらの根本原因を見つけるため、開発担当者やTAEが協力しテスト結果のログやレポートの分析やデバッグ作業を行う必要がある

自動テストに十分なアサーションが含まれていることの確認

・自動テストはSUTを自動で操作するだけでなく、その操作した結果の確認をテストケースの期待結果確認の内容に沿って行う必要がある
 →これについては「テスト結果レポート」「各自動テストの実行ステータス」などで実際にテストが正しく実行されたことのエビデンスを提供する必要がある

tateishitateishi

8 継続的な改善

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

・TASの継続的な保守作業と併せて、効率性、使用性、カバレッジなどの向上のためにTASの改善も継続的に行う必要がある
・TASの改善活動には、例えば以下のようなものがある
 ・スクリプトの改修
 ・アーキテクチャの見直し
 ・文書化
 ・TASの機能追加

スクリプトの改修

・スクリプティングアプローチは、単純な構造化アプローチからデータ駆動アプローチ、キーワード駆動アプローチまで様々な種類がある(3.2.2節参照)
・TASの改善において、現在のスクリプティングアプローチを大幅に変更させることが適切な場合もあるが、既存の自動テストがすべて更新される場合もあり、その場合かなりの量の改修が発生する
 →そのため、すべてを一度に変更するのではなく、部分的なスクリプトの実装にのみ着目する場合もあり、例えば次のような改善点が考えられる

・"各自動テスト内の各処理(ステップ)で同一の処理がある場合は関数化し、ライブラリに追加して各自動テストで再利用できるようにする"
 ・"各ステップの取りうる値が自動テストごとに異なる場合は、それらの値をパラメーターとして管理する"
  →キーワード駆動テストにおける典型的なアプローチ
  →"mablでいうところのFlow・パラメーターに該当する"

・"TAS、およびSUTでエラー発生時の回復プロセスを確立しておく"
  →例えば以下のような対策が考えられる
   ・"SUTでエラーが発生してフリーズした場合、TAS→SUTに対して必要な回復操作(アプリケーションの再起動など)をできるように構成しておく"
   ・"自動テストが途中で失敗した場合、自動テスト内で登録したデータ等は後処理で削除するように設定しておく"

・"自動テストの各ステップのの待機(Wait)のメカニズムを最適化する"
  →一般的な待機のメカニズムには以下の3つがある

① ハードコードによる待機(指定の秒数だけ待機する)
    →"これはテスト自動化において様々な問題の根本原因となる可能性があるため推奨できない"

② ポーリングによる動的な待機(例えば要素が表示されるまで待つなど)
    →"必要な時間だけ待機するためテスト時間が無駄にならない一方で、何らかの理由でプロセスに長い時間がかかる場合も待機し続けることができる、ポーリング条件が true になるまで待機を続けるため、①よりもはるかに柔軟で効率的"
    →"ただし、タイムアウトのロジックを含めておかないと、問題が発生した場合にテストが永久に待機を続けてしまう可能性もある"

・"TASや自動テストスクリプトを1つのソフトウェアとして扱う"
  →"コーディング規約の使用、コードの静的解析、コードレビューなどを適用する"
  →特定のライブラリをTAEではなく開発担当者が行うなど、部分的に実装を分担する

・TASの機能を追加する
  →「詳細レポートやログの出力」「他ツールとの連携」など、テスト自動化の初期段階では実装できなかった機能の追加を検討する
   ただし、使用されない機能を追加してもTASの複雑さが増して信頼性と保守性が低下するだけなため、機能を追加する場合は「実際に使用する機能かどうか?」を考慮する必要がある

・既存の自動テストをリファクタリング・削除する
  →"自動テストを運用していると、中には「失敗率が高い」「保守コストが高い」などあまり自動テストに向いていないものが出てくることがあり、それらのテストはリファクタリングを行ったり自動テストスイートから削除することも検討する必要がある"

アーキテクチャの見直し

・SUTの試験性を向上させるために、アーキテクチャの変更が必要になる場合がある
 →例えば、テスト用のAPIを提供するためにSUTを改修する場合、TASも適切にリファクタリングされる必要がある
 →ただし、テスト自動化活動の後半でこのような改修を行うと非常にコストがかかるため、自動化の初期段階で考慮しておくのが本来は望ましい

文書化

・文書化にはいわゆる「TASのマニュアル化」の他にも「自動テストの文書化(各自動テストがどのような処理を行うか」や「TASが生成するレポートやログの説明」など、あらゆる形態の文書化が含まれている

TASのアップグレード

・TASを新しいバージョンにアップグレードすると、新しい機能が提供されたり不具合が修正されたりする一方で、既存の自動テストの実行に影響が出る可能性があるため、アップグレードをする前にサンプルのテストを実行して既存の自動テスト実行に影響が出ないかを確認しておく
 →"サンプルのテストは、異なるアプリケーション/テストタイプ/環境での代表的なケースを使用する"

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

・TASの変更・改修は、どれほど些細な内容であろうとすべてTASの信頼性や性能に影響する可能性があるため、慎重に計画し調査を行う必要がある

TASの変更点を特定し、段階的に変更を行う

・テストソフトウェア、ライブラリ、OSにどのような変更が必要になるかを確認する
・T"ASの変更・改修時も自動テストができるだけ継続的に動作し続けられるようにするため、変更に影響する個所のテストスクリプトを限定的に実行し、既存の動作に影響がないことが確認できればそのまま実装することができる"
 →その後、すべてのリグレッションテストを実行し、改めて既存の動作に影響がないことを確認する

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

・TASが成熟するにつれて、以下のようなさらに効率的なテストの実行方法を見つけることができ、これらはすべてのプロジェクトで使用されるコア機能ライブラリに組み込む必要がある
 ・テストコードの最適化
 ・新しいOSライブラリの使用

機能を統合する

・"ブラウザの自動テストで起きていることを端的に表すと、「Web UI上の操作対象の要素を特定して指定された操作(クリックや入力など)を行うこと」である"
 →そのため「どの要素に対して」「どんな操作を行うか」を指定する必要がある
・"その際、例えば「ドロップダウンリストからメニューを選択する」のような1つの操作を行うための「細分化された機能(関数)」と、「ドロップダウンリストからメニューを選択し登録ボタンを押す」のようなパラメーターの1つとして関数を指定することで、いくつかの機能を組み合わせて動作する「汎用的な機能(関数)」が存在する"
 →"「細分化された機能」を統合して「汎用的な機能」を作ることによってメンテナンスコストを削減することができる"

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

・SUTの変更に対応する際、単純にTASの機能を拡充していくのではなく、TAAを分析してアーキテクチャレベルで変更を行うようにしなければならない

命名規則と標準化

・TASを変更する際、新しい自動コードや機能ライブラリの命名規則は、既存のものも踏まえて一貫性を持たせる必要がある
 →"そのため、あらかじめ命名規則を決めておいたり標準化をしておく必要がある"

既存の自動テストの見直し・改善

・変更や改善のプロセスには、以下のような既存の自動テストの見直しなども含まれる
 ・あるテストが複雑で実行に時間がかかる場合、それを複数の小さなテストに分割する
 ・あまり実行されないテストは削除し、TASの複雑度を下げて保守性を向上する