Outline

今年2024年でQAにjob changeして7年目くらいになる。
そこでこれまでのテスト自動化に関して振り返り、テスト自動化を整理してみた。
テスト自動化を導入する視点で発表資料をまとめた

前提

WEBサービスのUIテストの自動化を対象とする
テスト自動化の（たぶん）一般論がメインです
技術的なことは含まれていません

1. テスト自動化の目的は明確にする

テスト自動化は手段である、目的ではないはず。
自動化を始めたいという人に話を聞くと（最近、以下のような目的の人は減りましたが）以下のようなことがよく聞かれた。

上から自動化導入しろと言われた
カバレッジを上げたい
コスト削減をしたい

1番目はナンセンスで手段が目的になっている。
2番目は、何のためにカバレッジを上げたいのかがわからない。たぶん、Unit Testである程度のテストカバレッジを高めているため、UI Testに関してもカバレッジを上げたいのだろうが、どこに課題があってUI Testの自動化をやりたいのかが不明である。
3番目は、大きな目的としては理解できる。ただ、現在の課題がどこにあって、なんのコスト削減を行いたいのか漠然としている。テスト自動化はコスト削減には強力なツールではある。しかし、イニシャルコスト、追加コスト等増えるコストもある。やりかたをミスると、かえってコスト増になりかねない。

このようにテスト自動化を始めるにあたって、目的を明確にしたほうが後戻りがなくてよい。
目的を整理するにあたって、以下のようなことを最初にクリアにしたほうがいい

1.テスト自動化の大きな目的　（テスト目的として、リグレッション、スモークテスト、新規機能テスト、データ作成等のテストサポート、負荷試験等）

2.品質において、マニュアルテストと役割分担を明確にする。重複してテストするのか？双方のテストのすり合わせをどうするのか？等
　以下は、マニュアルテストとテスト自動化でどこを担当すべきかを明確にする例である

3.テスト自動化の実行頻度を算定する。テスト環境にdeployされたタイミングで行うのか？それとも定期的、不定期に実施するのか？　テスト自動化のボリュームや、もとめられる実行パフォーマンスや、テストリソースの検討に必要となる
　以下は、テストの実行頻度とテスト自動化の実行時間見積を可視化した例である。この例では、deploy後にテスト自動化実行する。テスト実行時間がdeploy間隔に追いついていない。この場合、理想的なDeploy-テスト連携にならないことがわかる。

4.対象のアプリケーションの更新（リリース）頻度を確認する。　アプリケーションの更新頻度がテスト自動化のメンテナンスコストに比例するからである
　以下は、アプリの更新頻度（Project）とその仕様変更によりテスト自動化の新規作成・既存のscriptの修正などが発生する運用タスクを可視化したものである。もし、テスト自動化の運用が追いつかないようだと、将来破綻する。

他にも、テスト自動化導入時にクリアにしておくべきことはあると思う。これらを明確にしたうえで、自動化導入の検討に入ったほうが、導入後の後戻りが減ると思います

余談 1 実行回数が増えると、元が取れるから?

むかしの本で、マニュアルテストとテスト自動化のコストの損益分岐の記事を見たことがある。
3-4回実行すれば、テスト自動化の構築時の元が取れるのでやったほうがいい、と。
当時信じていましたが、これはあかんなといま振り返って思う。
まず、後述するが、テスト自動化には運用コストが必ず発生します。場合によってはマニュアルテスト以上に発生する可能性があります。ただ、それでもテスト実行スピード等の利点からやるという判断もあります。
そもそも、品質活動を上げることが目的である（とおもう）から、ｘ回数目指して実行しよう、といったよくわらからない目的は一掃すべきである。

余談 2 テスト自動化は、仕様修正が発生しにくいところを自動化すべし？

テスト自動化の立ち上げ時は、たしかに仕様修正が発生しにくいところを自動化していくと、はかどるでしょう。
初めての構築でもあるため、自動化スクリプト中に仕様が変わり、都度修正を要求されると、自動化のプロジェクトも難航し、特に初心者にとって萎えてしまい、テスト自動化プロジェクトはうまく軌道に乗りません。

ただ、そこを超えてしまえば、その制限を見直したほうがいいでしょう。
なぜなら、テスト自動化は、重要な機能の品質や、修正がはいることによるリグレッションの担保等が目的であるからである。
ほどんど修正の入らない機能のテストは、たぶんマニュアルテストでも重要視されないでしょう。そういった、手動でおこなって効果のないテストを自動化しても無駄である。

2. テスト自動化の特徴を知る

テスト自動化はテストスピードの改善や、大量テスト実施によるコスト削減が期待される。
しかしながら、全能ではない。銀の弾丸にはならない。
そのため、テスト自動化の特徴（有利・不利）を知ったうえで、いいとこどりをしながら導入を進めると成功する。

以下、テスト自動化のメリット、デメリットをいくつか挙げてみる。

テスト自動化のメリット

一貫性。　つまり正確に同じ作業を行う。不具合があったとき、その再現性を担保する（不安定サービスによる、まれにおきるバグ等は除く）
マニュアルでは厳しい複雑なテストが実施。例えば、100個の入力フォームへの入力テストは、マニュアルではしんどい。しかも、それを繰り返し実施するとなると。。。
高速feedback（不具合があった場合、すぐに見つける）、大量実行、四六時中実行をする。そして人間は暇になり、もっと知的な作業に集中できる

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

1.決められた手順しかやらない（探索的テストは当然やらん）

2.新規性のバグを見つけるのは困難（決められたテストしかやらない、その同じテストを繰り返し実施するため、探索的テスト、嫌がらせテスト等で見つかるようなバグはほぼ出てこない）

3.機械で判別できる基準が必要（validationの処理で機会がpass/failを判断する必要がある。そのため例えば、”UIがくずれている”、という判断を機械にどう設定するか、難しい）

4.きわどいタイミング要求、手動操作を介在するテストは不向き。（完全自動化をもとめないほうがいい）
例として

裏でいくつかのバッチを実行して、処理が終わったらUIのテストを行う
非同期でデータが更新する仕組み。更新処理をして数分後にUIのテストを行う

なんとか、自動化で頑張ることは可能だが、複雑な設定や、判断基準があいまいになったりするため、あまり向かない。

5.新規シナリオのテスト自動化の開始時期は遅くなる
　以下に開発プロセスとテスト自動化の開始タイミングを可視化したものである。
　WEBサービスのテスト自動化をする場合、基本的にはテスト対象が出来上がってからスクリプトを作成する。なぜなら、どんなテストツールでもUIからxpathなどで要素を取得して、それをもとにシナリオを作成する。もしくは、キャプチャー＆リプレイがもっと理解しやすい。このキャプチャー＆リプレイ型のテスト自動化は、一連の操作を行って、スクリプト作成する。まず、テスト対象ができてからでないとスクリプトを開始できない点がある。
　さらに不幸なことに、テスト対象ができたとしても、不具合のある状態のものに対してスクリプトを作成しても、不具合のなくなったものに対してそのスクリプトが成功するとは限らない、もしくはテストの意味をなさない。そのため、テスト対象に対して不具合をつぶして、安定化してからスクリプトを開始しないと、意味あるテスト自動化にならない可能性がある。
　このように、テスト自動化は、マニュアルテストより遅れて設計・実装となってしまう。

3. テスト自動化の実装法を検討する

では、具体的にテスト自動化をどうやって構築するかを検討する。
その検討に当たって、以下のキーポイントが考えられる。

誰が実装するか（構築エンジニア）
誰がどのように利用するか（運用者）
テスト自動化の品質
テスト実行以外に求められる機能

1番目、誰が実装するか。昔は、アプリケーションエンジニアがJava/Python/Ruby + Selenium , Appium といったOSSを用いて実装することが多かったのではないだろうか。
ただ、最近はローコード、ノーコードのテスト自動化ツールが登場により、実装のハードルが下がってきている。
これらのツールは、キャプチャ＆リプレイ型が主流であり、実装テストシナリオの可読性、容易な修正を可能とするメンテナンス性等が担保されている。

2番目、誰がどのように利用するか。作った後、実際にこのテスト自動化のシナリオをどのように実行するかを考える。
例えば、QAと開発部署が分かれているとき、そのテストをQA部署が実行するのか？そしてその実行のトリガーは、開発が開発環境に最新のコードをdeployしたタイミングで実行するのか？その場合、開発側とどのように連携するかを検討したうえで実装方法を考える必要がある。
また、プロダクトの更新・リリースサイクルの周期も検討材料になる。
例えば、2 weeks単位で定期的に更新が発生するとしたら、その更新スピードに追従できるような仕組みを検討しなければならない。

3番目、テスト自動化の品質であるが、テスト自動化もアプリケーションである。そのため、テスト自動化もテストが必要であり、品質をKEEPしないといけない。
そのため、スクリプトを始める前にアプリケーションと同じで実装方針を固めるとよい

まず、アプリケーション開発と同じでコーディングルール等、ソースコードのメンテナンス性を考えたほうが良い。ローコード、ノーコードでも、ツール上の記述ルールはあったほうが、メンテナンス性が上がる。そして、テスト基準（どこまでUIテストをするのか？ validationをどこまでするのか？　等）も決めたほうが良い。例えば、ページに遷移したとき、そのページであること・デザイン・状態などいろいろなテスト項目がマニュアルでは考えられるが、テスト自動化でそれらすべてをvalidateすると、実装工数・実行工数が膨れ上がる。また、実装者によって異なると、ソースコードのメンテナンス性が課題になる。

次に、実装方法。テスト自動化もテストが必要になる。テストのためのテストを極力抑えないと本末転倒になる。そのため、シンプルな実装にすべきである。アプリケーションエンジニアのように共通モジュール化でコードの再利用性・メンテナンス性を上げようとすると、かえって共通モジュール化の修正による、影響範囲のスクリプト修正が発生したりするため、あくまでテスト自動化のスクリプトの目的はシンプルにする（重複するモジュールの存在許容）ことである。

そして、この実装されたコードを誰が見るのか？そして、データ駆動のようにテストデータを変更して実行する場合、だれがそのデータを変更して使うのかを意識する必要がある。
例えば、このテスト自動化がどんなテストシナリオであるかを確認したい場合、コードから読み取れるようにしたほうが当然良い。

最後に、データ駆動、キーワード駆動といったフレームワークも考えるとよい。
先述のように、テストデータを変更しやすくするためのデータ駆動、テストスクリプトを抽象化して可読性を上げるキーワード駆動などがある。

4. テスト自動化は立ち上げ時より、導入後が大変になる

テストをあまり知らない人が勘違いしていることとしてよくあるのが
「テスト自動化は作ってしまえば、あとはお金かからないんでしょ？」
である。
いやいやいや、そんなことはない。いろんなコストが発生します。
そこをお金を出してくれるオーナーと認識持ったうえで進めないと、実際に運用してから予算がなくて頓挫することもなくはない。

以下に運用コストが発生する例を挙げる。

プロダクトの仕様変更にテスト自動化が追従
テスト自動化はFragile
テスト自動化実行してエラー発生時、その調査（マニュアルテスト以上に時間がかかるかも）
テスト自動化のパフォーマンス劣化の対応
ブラウザ、OS、テスト実機などの最新化への対応

1番目、プロダクトの仕様変更にテスト自動化が追従する必要があります。まったく仕様変更がないプロダクトであればたしかにこのコストは発生しないかもしれません。
ただ、基本的には頻繁なプロダクト更新に対してのリグレッションテスト工数削減、テストスピードを上げることが目的であるため、仕様変更に対して、テスト自動化のスクリプトの改修しなければなりません。

2番目、テスト自動化はFragile（失敗しやすい）。UIテストはマニュアルテストでも発生すると思うが、とにかく失敗する。そのため、その失敗原因を調査したり、失敗しにくいテスト自動化に改修する等の対応が求められる。
以下に、UIテストが失敗する要因のいくつかをリストアップした。

Networkの瞬断
テスト環境のサーバースペック不足
テスト環境へのDeploymentと被った
UIが描画完了せずに処理を進めようとして失敗した
テスト機のパフォーマンスが悪化した
ブラウザがメモリを枯渇した
サードパーティー（API、CDN等）の障害
ブラウザ・アプリが意図しないポップアップ・警告・通知を出した

3番目、テスト自動化実行してエラー発生時、その調査のコスト
テスト自動化は常に成功していれば問題はない。ただ、失敗したときその原因調査がある意味マニュアルテストより工数がかかることがある。テスト自動化失敗時に、ツールによって優れたログを出力されるかもしれません。ただ、そのログから、テストが失敗した原因を調査し、不具合なのかテスト自動化の問題や環境の問題だったのかを特定する必要がある。場合によっては、ローカル等で再実行して再現性を確認したりすることもある。

4番目、テスト自動化のパフォーマンス劣化の対応だが、アプリケーションと一緒でテスト自動化も実行を繰り返すことにより、実行時間（パフォーマンス）が劣化することがある。
アプリケーション側の不具合かもしれないし、テスト自動化のコード品質なのかもしれない。
後者であれば、テストスピードが売りのはずなので改修し、テストスピードをキープしなければならない

5番目、ブラウザ、OS、テスト実機などの最新化への対応ですが、WEBやnativeappがテスト対象であれば、そのアプリを動かすＰＣやマートフォンのブラウザやOSを、最新化サポートしていかなければいけない。
その更新作業で、たいていテスト自動化側のversion upを行う必要がでてきる。

5. テスト自動化の見える化をする

テスト自動化がうまく軌道に乗ったら、見える化をすすめましょう。
見える化には、いくつかの目的がある。

テスト自動化のアクティビティを可視化
プロダクトの品質を可視化
テスト自動化の品質を可視化

1番目は、おおきく２つに分けられる。
自動化メンバーのアクティビティを見えるようにすることで、やってきた成果の大きさがわかるようになり、また新しいメンバーが増えたときに、使えるドキュメントとなる。
もう一つは、関係者（マニュアルテストエンジニア、開発、お金を出してくれる人等）へ自動化の成果・ステータスを表現することである。
経験上、周りから言われたのは、「テスト自動化って結局何をやってるのかがわからない」というものでした。
特に、regression testで問題がない状態が続く（プロダクトの品質が保たれる）と、なおさらだ。
そのためにも、関係者へのテスト自動化の可視化は欠かせない。
例えば、マニュアルテストメンバーに対しては、自動化がカバーしているテストケース・テストステップ等だ。
開発側にはテスト自動化によるテスト効率・スピード・不具合数等だ。

2番目のプロダクトの品質の可視化は、常にわかる状態にする必要がある。
また、見る人に合わせたレポートにまとめるといい。
たとえば、外部向けであればさまった情報を提供するとよい。

3番目は、テスト自動化自体の品質を可視化することで、テスト自動化の信頼性（擬陽性・偽陰性など）、パフォーマンス等がわかり、自動化の改善活動に役立てることができる。

最後に、上記可視化をする上では、仕組化が必要である。
可視化もテスト自動化の運用の一つである。可視化する部分はマニュアルでやっていたら、テスト自動化エンジニアとして本末転倒である。この仕組化を組み立てることで、テスト自動化全体最適化ができるとおもう。

以下に、テスト自動化の可視化の例である。

Test Automation Journey 2023