[Lesson Test Automation. Day 08] Test Automation Operation

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

Outline

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

今回は、テスト自動化の実装にあたって、どのようにプログラムを組むとよいかの設計に関することを記載する。
尚、開発言語に依存しないレイヤーである、概念について記述する。

今回は、テスト自動化の運用に関して執筆する。
テスト自動化の成功可否の半分以上は、テスト自動化を作成後の運用が握っている。

[Lesson Test Automation. Day 04] Test Automation Code Design vol.01のcondition（前提条件）で定義した通り、test automationをjenkinsで毎日実行運用を前提とする。
test automation の使われ方が異なれば、運用は当然変わるからである。

運用で考慮するポイントは以下の通りである。

1. Keep environment
2. Version up environment
3. Synchronize application
4. Improve test automation script
5. Visualize report
6. Handle error report

1. Keep environment

環境を維持することが求められる。
環境として、以下のようなものがある

  • サーバー
  • ネットワーク（インフラ）
  • プロキシ―サーバー（テスト環境の接続方法に依存）
  • クライアントPC
  • クライアントスマートフォン

サーバーやネットワーク等は、エンジニアが運用している場合がある。

これらが常に安定して使える状態にしておく必要がある。
とくに、サーバーやネットワーク側は、test automation以外の人たちも共通して使うことが多い。
また、サーバーがエンジニア主導で運用している場合、テスト環境の利用ルールを整えておかないと、デバッグ等の使われ方により、test automationが失敗することが多く発生する可能性がある。

2. Version up test environment

さまざまなものをupdateする必要がある
（テスト自動化を実行する、クライアント視点に絞る）

  • クライアントPCのOSやセキュリティパッチ等
  • WEBテスト時に使用するブラウザ
  • スマートフォンのOS、WEBブラウザ
  • スマートフォンのテスト対象のアプリ
  • test automationのツール (Ex. Ranorex, Selenium , Appium)
  • CIツール (Ex. Jenkins , plug-in)

最新のOSのテストを常に追従する場合、定期的なversion upが欠かせない。
また、version up時に発生しうる、以前のものが動かなくなる問題もあるため、検証・修正等の作業も発生する。

3. Synchronize application

test automationは、基本的にテスト対象のアプリケーションに修正が入った場合、test automationも修正が必要である。
「Test Automation Code Design」でも記載しましたが、多少のUIの変更にも強いテスト自動化の実装を行うことを勧めている。
しかし、それでも動作検証と必要に応じて修正を行い、常に対象のアプリケーションに追従する必要がある。

追従するにもいろいろと検討する必要がある課題がある。

  • テスト対象のアプリケーションの更新情報の取得と、既存のテスト自動化の影響範囲
  • アプリケーションがテスト環境で更新するタイミングと、それに対応するテスト自動化の修正スケジュール
  • アプリケーションが安定化するタイミングの見極めと、テスト自動化のscriptingの開始のタイミング検討
  • テスト自動化の修正期間に起きうる、既存のテスト自動化失敗の取り扱い

テスト自動化のscriptingのタイミングは重要である。
なぜなら、アプリケーションがバグを含んでおり、マニュアルテスト等でテスト中にscriptを作成しても、そのscriptはバグのあるアプリケーションに対して正しく動くものになりうるからである。
理想を言えば、正しく動くアプリケーションに対してテスト自動化scriptを行うことである。

4. Improve test automation script

「3. Synchronize application」の理由で修正すること以外に、scriptを修正することが求められる。

  • script実行時間の短縮
  • テストシナリオの最適化による修正
  • Flakyなscriptの改修
  • リファクタリング

などである。

テスト自動化は、quick feedbackが売りである。
そのため、テスト実行時間がかかってしまうと、自動化の効果が薄れてしまう。
そのため、scriptの無駄な処理（よくあるのが、wait処理）を省き、もしくは重複するscenarioがあればscriptをマージするなどを行い、処理時間の短縮を図ることは、日々のオペレーションで求められる。

Flakyなscriptも発見し、改善していくことが求められる。
アプリケーションは問題がないのに、不安定なscriptのためにテストが失敗するのは、運用の無駄になる。
それが発生しないように修正することが求められる。

5. Visualize report

テスト結果をどう活用するかを検討する必要がある。
目的として以下のことが考えられる

  • どのシナリオが成功、失敗したか
  • 失敗の履歴がどのようなものか （不具合の傾向、Flakyのscriptの検知など）
  • 実行時間がどれくらいか　（feedbackが遅いものがないか）
  • 失敗したときに、原因調査を行いやすい情報が揃っていて、すぐに使うことができるか

どのような運用を行うか、そしてテスト結果をどのように使っていくかによって求められるものは異なる。
多くのテスト結果から、上記の目的を達成するための仕組み、ツールが求められる。

例えば、Jenkinsのステータスを集計し、各サービスのテスト成功情報を可視化するものが以下である。
Jenkinsが複数ある場合、その情報を１か所に集約したほうが、日々のオペレーションで効率が良い。

各scriptの実行履歴、成功率、実行時間等も可視化すると、どのスクリプトに改善したほうがいいかなどもすぐにわかる。

6. Handle error report

これは、当然の作業である。
テストが失敗したため、何故失敗したのかを調査する必要がある。
放置していたら、何のためのテストなのか、意味がない。

概ね、以下のような作業になる

  • エラーレポートから原因を調査
  • 特定できない場合、再実行して目視して原因調査
  • アプリケーションの不具合であれば、バグレポートを作成
  • テスト自動化の不具合であれば、scriptを修正
  • 問題が解消すれば、再実行し、成功することを確認

Finally

今回で、Test AutomationのBasicなlessonコンテンツは終了です。

次は7月31日（金）頃配信予定です。
何を題材にするか、検討中です。

reference

  • A Journey through Test Automation Patterns (Book)

back number