https://veriserve-event.connpass.com/event/226337/

Outline

3/17に VeriServe Test Automation Talk #2 「Webのテスト自動化ツール、どう選ぶ？経験者に学ぶツール選定の考え方」というテーマでオンラインイベントがありました。
今回、こちらで発表する機会がありました。VeriServeの方々誠にありがとうございました。
その発表内容をこちらにまとめました。

1. 1st Test Automation turned out to be a flop

2014年、アプリエンジニアの時、テスト自動化の導入をしたことがあります。

発端は、各開発チーム横串でテスト自動化を始めようということで始まりました。
いわゆる、「テスト自動化が目的」でした。
短期間でノルマ達成するために、E2Eテスト自動化がわかる出来るエンジニアだけで自動化プロジェクトを発足しました。
ただ、業務委託さんに自動化を作ることを丸投げし、具体的にどのように実装し、運用するかはすべてお任せ♪でした。

それが、半年後どうなったか？

よくわからない目的で、月に実行するにとどまった
テスト自動化を作ってくれた勇士たちは、契約満了していなくなった
最後にメンテナンスできなくなった

その後、そのテスト自動化は除却された。

ここからなぜ失敗したのかを振り返り、３つの不明確さがもたらしたと思われます

何のために、テスト自動化を使うのか？　手段が目的になってしまった
誰がテスト自動化を使うのか？　構築だけではなく、その後の運用担当を考えてなかった
どのようにテスト自動化を使うのか？　作ったものをどのように運用して使っていくのかが漏れていた。

2. 2nd Test Automation was born and success

2016年に、QAのテストエンジニアにjob changeしました。
QA組織の立ち上げと同時に、テスト自動化の導入を検討しました。
先のテスト自動化導入の失敗を踏まえ、３フェーズをしっかり踏んで進めることにしました。

Analyze : テスト自動化の要求分析
PoC : いくつかのテスト自動化ツールの Proof Of Concept
Implement : 決めたテスト自動化をチームに浸透させる

Step.1 Analyze Test automation requirement

テスト自動化を導入するにあたり、WHY、WHO、HOWを分析しました。
大きく5つテスト自動化に求められることがわかりました。

1. 毎日Regressionを実施

　　　　
テスト自動化の一番大きな目的として、「毎日Regressionを実施」を掲げています。
毎日実行することで、不具合をすぐに検知し開発へ早いフィードバックをするためです。
この運用のために以下のことが求められます。

日々変わる仕様変更にすぐに追従できる必要がある。　
毎日実行するテストで失敗が発生した場合、短時間でエラー原因を特定できる必要がある。

つまり、この運用を実現するために、テスト自動化には以下のことが求められます。

日々変わる仕様変更の、Script修正が容易である。
エラー原因を容易に特定できる、十分な情報（エラーレポート）を提供されている。

2. テストコストの削減

この時代に、マニュアルテストの工数と比較する議論は愚問だと思います。
とはいえ、マニュアルテストよりコストが削減されていて、かつ選択するテスト自動化のなかでコストが少なくなるものを考えたほうが良い。
テスト自動化のコストには大きく3つ考えられます。

初期ライセンスや、テストフレームワークの構築、初期テストのスクリプティング、テスト環境構築などの Initial 。
テスト対象の仕様変更に伴うスクリプト更新、テスト自動化のデプロイ、テスト自動化やテスト対象のversion upにともなう更新作業などのMaintenance。
テスト実行に伴うエラー分析などのOperation。

この３つのコストを中長期にわたって少なくなる手段を選んだほうが良い。

3. テストエンジニアが運用し、横展開可能

QAの部署のテストエンジニアが構築からメンテナンス、運用を行うことを前提としました。
このメンバーで、テスト対象のサービスを広げていくことも視野に入れています。

そのため、テストエンジニアのスキルセットに合わせたテスト自動化を選択する必要があります。

4. スクリプティングよりテスティング

QAの部署ですから、テストが主目的です。
かつ、テストエンジニアは人数が多いわけでもありません。
以下のことが求められます。

テスト対象のテスティングに時間を費やしたい
テスト自動化もアプリであり、テストが必要です。テスト自動化のテストは目的ではない

このことから、テスト自動化に求められることは

短時間で構築できる
ロジックの実装は最小限に。ローコードやノーコード

5. テストケースの整合性取りやすさ

テストケースが増えてくると、テスト設計書、自動化スクリプト、そして実行環境のそれぞれの情報が増えてきます。
この整合性をつねに保たないと、運用が煩雑になり、何をテストしているのかもわからなくなってしまいます。
そのため、これらの整合性を簡単に保てることができることがテスト自動化に求められます。

Step.2 Proof Of Concept

Step.1 Analyze Test automation requirementでは、テスト自動化の要求を整理しました。
次に、この要求を満たすテスト自動化のツール探しです。

ライセンスツールに関して、Veriserveの「AIとソフトウェア品質技術」で情報がまとめられています

2016年当初、第2世代がピークであったかと思います。
第3世代は、ベータ版が出たばかりであり、なるべく安定したものを選びたいこともあり、第2世代のなかからいくつかを選択し、POCすることにしました。

POCとして、4つの工程があります。
これを１つのツールにつき約2週間と期限を設けました。長時間かけてPOCが終わらないなら、たぶんチームに合わないツールとして切り捨てました。

環境構築
コーディング（対象は、PC Browser、iOS, Android APP）
Localで実施　（実施方法として、Cross-Browser、複数のReal Smart Phone Device）
Jenkinsで実施

このPoCを経て、今現在使っているRanorexを選定しました

尚、テストケースの整合性取りやすさは具体的に以下のようなことです。

Step.3 Implementation

ツールを選定しました。
その後重要なステップとして、中長期にテスト自動化が正しく運用されるように、チームにしっかり浸透させることとして、以下のようなことをしました。
ただ、そこに工数を大きく割きたくないので、最小限にとどめます。

Document整備、ただしツールに関するマニュアル、チュートリアルなどはVendorのsiteを流用
ノーコード、ローコードとはいえ、チームに適した最低限のProject rule、coding ruleを設ける
こまったら、テクニカルサポートを最大限に活用

3. Current Status

2022年で、約6年たちました。
これまでのざっくりとしたimpressionです。

WEB Native APP両方を一つの言語（ツール）で対応できる利便性
困ったら、テクニカルサポートに頼れるので、technical調査工数が削減
Windowsがベースであり、Macが非対応。一部Macユーザーには不満
Ranorex Communityが限られているのが残念

4. Summary

テスト自動化導入にあたってのSummaryです。

テスト自動化のWhy Who Howを明確にする
POCをテストエンジニア（使う人）で実施し、チームに適合したものを選択する
導入したツールを長期に運用できるように仕組化する

5 Q&A

Q.1

Implementで苦労した点は？

Coding ruleを設ける重要性があった。
最初、codingに関してテストエンジニア任せでした。
Ranorexは複雑な処理をC#で独自実装（ユーザーコード）できます。
人によってユーザーコードを多用することがあり、せっかくのローコードの意味がなくなってしまうので、このルールをしっかりと適用しないといけないと実感した苦労があります

Q.2

マニュアルとの協業はありますか？

以下の図のように、マニュアルチームがプロジェクトのQAを主体でリードします。
regressionへの影響範囲、新規機能の情報をテスト自動化チームに共有してもらい、それに基づき自動化の実装を行います。
また、そのプロジェクトが終わるまでにテスト自動化は既存のregressionのscript修正を行い、マニュアル＋テスト自動化の結果でもってリリース判定を行っています

Jasst nano #6より

VeriServe Test Automation Talk #2 Presentation「How to introduce test automation」