E2Eテストツールに必須だと思う2つの機能のおはなし
こんにちは、自動テストアーキテクトの森川です。
みなさん、自動テストしていますか？
本日はE2Eテストツール、とりわけリグレッションテストツールには欠かせない2つの機能についてのお話です。
きっかけ
Seleniumベースの自動テストツール開発・運用に数年たずさわっている筆者ですが、ここ最近ノーコードAI系テストツールやオンプレの有償テストツールを、いくつかさわらせていただく機会がありました。
複数のツールを続けて触っていると何かしら別の観点から見えてくるものでして、テストツールに共通して求められる機能要素があることに気づきました。
「これは欲しい」「いやむしろ無いと困る！」という思いが日増しにムクムクと強くなり本エントリーに至ったというわけです。
なお、Seleniumベースのツールとは？ AI系テストツールとはなんぞや？
というところはAsterさんの「テストツールまるわかりガイド」に素晴らしくまとまっていますので詳細は割愛させていただきます。
ASTER テストツールガイド改訂WG（Test Tool Guide Working Group）
自動テストの作成を支援してほしい
SeleniumなどのOSSベースのツール、またはOSSを拡張したツールではコーディングが必須となります。
自動テストの作成は開発作業と言っても過言ではありません。
しかしアジリティが求められるこの現代でもなお、それでよいのでしょうか、とも思います。
自動テストエンジニアといえどもプロダクトを見る時間を増やして、プロダクトの価値向上、品質向上に貢献するべきではないでしょうか。
考えてみると自動テストエンジニアが自動テストコードのエディタばかり見ているという状態こそ問題なのかもしれません。
こんな声が聞こえてきそうです。
「ちょっとちょっと！うちの自動化エンジニア、Seleniumのソースコードばっか見て、 ぜんぜんプロダクト（サイト）見ないんだけど！！」
テストツールには自動テストの作成支援をして欲しいです。
リニア・スクリプティング、いわゆるキャプチャ＆リプレイでコードを書く時間を減らしてくれても良いですし、キーワード駆動やデータ駆動でファイルをINPUTにテストを書けるようにするのでも良いです。
自動テストエンジニアが、自動テスト作成に張りつかなくて済むように、なにがしかの工夫がされているべきだと思うのです。
ちなみにノーコードAI系テストツールでは、キャプチャ＆リプレイで記録したテストコードをクラウド側に持たせて内部で最適化しているようです。ユーザはUIを介して決まった操作のみでテストコードを編集するためノーコードな作成ができます。あまり凝ったテストシナリオは任せられないという特性はあるものの、このあたりは人気の理由の1つと言えそうです。
余談ですが、『キャプチャ＆リプレイツールを使ったテストはそもそもテストとしてOKなのか』という問題は賛否両論あるようです。弊社内で聞いてみても色々な方が様々な意見をお持ちでした。ゆっくり議論してみたいテーマですが、熱くなっているとうっかり朝になっちゃいそうですね。（徹夜は体によくないですよ）
過去のテスト結果を生かして修正を手伝ってほしい
ご承知の通りE2Eテストツールの主戦場はリグレッションテストです。
リリースを重ねる毎にテストは増えていきますし、テストスイートはCIサーバ上で何度も実行することが前提です。
だったらテストが失敗したときにCIサーバ上に溜まった過去データを使って、プロダクトのどこが壊れたのかもしくはどこでテストがコケたのか、調べてくれても良いんじゃないでしょうか？
調べるのは人間がやるにしても、差分や場所の特定、前々回はどうだったのか教えてくれるだけでも、随分と捗りそうです。
E2E自動テストは不安定 － 俗に言うFlaky Test － 私たち自動テストエンジニアのランチの時間を常に奪う憎いヤツ － になりがちですから。
この点についてもノーコードAI系ツールは数歩先を行っていると言えるでしょう。オートヒーリングやRCA（根本原因分析）などと呼び名やアプローチは異なりますが、総じてレコーディング時や過去のテスト実行時の情報を用いてテストコードの修復をアシストします。正誤判断（または修正の提示）にはAI/MLが活躍しているようです。蓄積したデータによるMLモデリング育成とSaaSの相性の良さに納得がいく感じがします。
Using the Root cause analysis feature - Applitools
しかし、必ずしもSaaS上である必要はなく、CIサーバと連携して自動テストの過去データを有効活用さえしてくれればよいとも言えます。
まとめ
今、E2E自動テストツールに求められる大切な2つの機能について考えてみました。
シンプルに言うとこんな感じです。
1. 自動テストの作成を助けてくれる機能
2. 自動テストが壊れたときに助けてくれる機能
「そんなの当たり前でしょ」というお叱りの声が聞こえてきそうですが
先日とある調査でこの機能を少しも備えていないツールをさわらせていただく機会がございまして、やや雄叫びに近い気持ちで本エントリーを書きたくなった、っというのは内緒の話です。
冗談はさておき、現代のソフトウェア開発ではアジリティが求められます。
Selenium等の自動テストの技術は素晴らしく進化してきましたがアプリケーションを取り巻く環境はそれを上回る速度で多様化・複雑化しているように思います。それにともなって自動テストエンジニアに求められる事も大きく変化していきているように感じます。
昨今ではSeleniumによるテストコード作成や保守に費やす時間がボトルネックとなっている現場も少なくないでのは？と思います。
現在あるテストを無理に自動化するのではなく、自動テストが必須となるようにスムーズ・スマートにプロジェクトのF/Wに組み込んでいくのかこれからの必須のミッションとなることでしょう。そんなときに「あって当たり前」のツールの機能要素とは何なのか、本エントリーを頭の片隅で思い出して頂けたら嬉しい限りでございます。
それでは皆さん
Happy Automation Testing Journey！！
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
執筆者プロフィール：森川 知雄
中堅SIerでテスト管理と業務ツール、テスト自動化ツール開発を12年経験。
SHIFTでは、GUIテストの自動化ツールRacine(ラシーヌ)の開発を担当。
GUIテストに限らず、なんでも自動化することを好むが、ルンバが掃除しているところを眺めるのは好まないタイプ。
さまざま案件で自動化、効率化によるお客様への価値創出を日々模索している。
★このSHIFT公式ライターの他の記事を見る
《NEW!!》資料ダウンロード／動画視聴ページはこちらから
■SHIFTについて
私たちはソフトウェアテスト(第三者検証)のプロ集団です。
■メディア掲載情報
SHIFTに関するメディア掲載の実績をご紹介いたします。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/