[Lesson Test Automation. Day 03] introduce test automation

7509 ワード
automation test test テキストリンク

Outline

本コンテンツは、これからテスト自動化を始める人向けに作成するコンテンツ。
筆者のこれまでの経験を元に作成しているので、教科書と異なる場合があります。

今回は、テスト自動化を組織に導入するステップを記載します

Condition

筆者はWEBサービスのテストエンジニアである。
そのため、WEBサービスの開発を前提としたテスト自動化の話になる。
SCOPEは End to End のテスト自動化とする

Introduce process

以下のようなプロセスで自動化の導入を行う

1. Clarify test automation objectives
2. Organization for test automation
3. Choose test automation tool
4. Define metrics
5. Choose target, Define process & Start pilot

次の節で順に説明する

1. Clarify test automation objectives

まず始めるにあたって、以下をクリアにする

- Why do you use test automation
- What do you want to automate

目的を明確にしないと、テスト自動化を実装、運用フェーズに入ったときに、全く違った作業をしてしまう可能性が起きうる。

例.

  • テストデータ作成の作業効率・コスト削減
  • リリース前のリグレッションテストの実行時間削減
  • フォーム入力といったテストのバリエーションテストで人の作業を削減
  • 毎回発生するレグレッションテストのヒューマンオペレーションミス削減

ここを抑えておかないと、「なんか自動でテストが動いて成功している」ということになりかねない。
また、導入の効果測定をするときのメトリックスの参考となる

2. Organization for test automation

組織において、以下のようなことを踏まえて担当者を立てる必要がある

- Test automation is software 
- Test automation has SDLC(Software Development Life Cycle)
- Process compatibility
- Expand test automation

test automationはソフトウエアであるため、テスト対象のアプリを作成するエンジニアと同等の人材が望まれる。

Test automationを作成するための便利なツールが提供されているが、それを使いこなすソフトウェア開発のスキルが要求される

Test automationも運用フェーズがあるため、test automationの運用を含めて全体設計を行うことができるスキルが求められる。（次回以降詳細を執筆予定）

Test automationはテスト対象（アプリケーション）があって、意味がある。つまり、このテスト対象に追従しながら、テスト自動化を作成・修正・テスト自動化のテスト・テスト対象のテストを行うプロセスを設計、運用できる必要がある

最後に、導入する担当者がテストの組織内に展開、とくにテスト自動化未経験者にも導入することが求められる。また、ステークホルダー（上司、開発部門、事業部門等）にテスト自動化の成果を適切にレポーティングすることも求められる。それを行わないと、「テスト自動化の一部のメンバーがなんかやってるね」というブラックボックスな組織になりかねない。

3. Choose test automation tool

テスト自動化するためのツール選定。
選定するときに、以下のことを考慮する必要がある

- Scripting skill requirement
- Tool trouble shooting support
- Version up maintenability
- reporting function
- Tool cost & human operation cost balance

テスト自動化はnon-codeのものがある。例えばキャプチャー＆リプレイ（例 selenium IDE）がある。
ただ、non-codeだけではやれることは限られる。当然、マニュアルで操作したものを繰り返し実施するテスト（耐久性テスト等）であれば、事足りる。

ツールで困ったときに、すぐにサポートを得られるものを選んだ方がよい

WEBアプリケーションでは、iOSやAndroidのように常にバージョンアップしていくテスト環境を扱う。このバージョンアップに速やかに対応するツールを選定するとよい。

忘れがちなのは、テスト結果の結果レポートの作成。有償ツールの場合、失敗時の画面スクリーンショットや動画、失敗個所の明示したレポートを作成するものがある。OSSの場合、それも自分で作成する必要性があるため、ここを考慮しておく必要がある。

最後に、一番重要となってくるのはコストである。主に以下のようなコストを考えないといけない

  • Tool license cost
  • Initial coding cost
  • Maintenance coding cost
  • Coding speed

これらのコストを比較して、まず有償かOSSのような無償ツールの判断をするとよい。
また、実装スピードも一種のコスト（待機コスト等）として考えないといけない。
自分の部署にテスト自動化を導入した時のコストに関するお話が以下資料にあるので、参考にしてほしい。

4. Define metrics

Test Automationの成果を数値化し、pilotから本格稼働、他部署への展開などすることに活用できる。

実際に稼働してから検討してもよいが、Metricsで定義した数値を取れる仕組化を事前に考えておくとよい。Metricsの収集も自動化できるのであれば、自動化した仕組化を施すとよい

Metricsの例として以下がある

- Benefits
- Cost
- Speed
- Accuracy

テスト自動化のbenefitをさらに分解すると以下のようなものがある。

  • ヒューマン作業の削減工数
  • テストスピードで短縮される時間
  • テストサイクルの増加数
  • バグ検出数

costはテスト自動化の環境構築、scriptingの工数、テスト自動化の保守等である

speedはテスト対象に対してscriptを設計、実装、テスト、実施までのプロセスにかかる時間をさす。

accuracyはテスト自動化のテストの正確性（false-pass, failse-fail）を指す

5. Choose target , Define process & Start pilot

Choose target

テスト自動化をトライするための適切なサイズのテスト対象を探す。
小さすぎると、導入コストに対するメリットが小さいため、ROIの判断が難しい。
大きすぎると、初めてのことであるのでいろんな困難に遭遇し、それに対しての対処に時間がかかりなかななpilotを終わらすことができない。

例えば、会員申し込みフォームや単純な購入ステップ機能をターゲットとすると、機能的に完結し、規模も適切と思う。

尚、pilotでは既存機能のテストである、リグレッションテストを対象とした方がよい。
新規機能に対してテスト自動化をpilot導入しようとすると、後述するが時間的制約が厳しく、他部署にプロジェクト進捗等の影響を与えてしまう可能性がある。

Define process

先に述べたように、テスト自動化もアプリケーション開発と同じである。
リグレッションテストの構築するのであれば、基本的にテスト自動化単独で進められる。

1. Test scope
2. Test design for test automation
3. Setup test environment for scripting & testing
4. Coding Design
5. Script test automation
6. Debug test automation script
7. Run test automation for regression test

最初にテストスコープを明確にする。
次にテスト自動化でどのようなテストを行うのかを設計する。
JaSST'19 Tohokuここで述べたように、テスト自動化で何をテストするか、しないかを明確にしたほうが良い。

次からは実装にかかわるフェーズになる。
実装設計では、テスト自動化を効率よく動かすための設計（キーワード駆動、データ駆動、テストデータ設計、テスト実行順序　等）が重要になる。
その設計をもとに実装をし、その自動化スクリプトが正しいかどうかをデバッグする。
この自動化の確認は繰り返し実施して、検証したほうが良い。
テスト自動化は、成功したり失敗したりする状況(Flaky)が起きうる。
その原因として以下のようなものがある

  • ネットワーク断等の環境が不安定
  • 非同期処理等のタイミングに結果が依存する
  • 事前テストデータの不足（1回の実行でテストデータが使えなくなってしまう）
  • ブラウザ等のテスト環境の初期化処理の必要性（前回のテスト実行時のクッキーが残る）
  • UIが複数パターンある

このように、Flakyな場合があるため、繰り返し実施して動作検証をすることが望ましい。

これが終われば、実際にテスト対象のレグレッションテストとして活用フェーズになる。

Start pilot

上記、テスト自動化のプロセスを定義し、実行する。
そしてこのpilotが終わったら、定義したMetricsをもとに成果を整理する。
今後もテスト自動化を展開するためのレポート報告を作成しよう

Finaly

次は6月19日（金）頃配信予定です。
Test Automation Code Design を予定しています

reference

back number