自動テストの世界に、この5年間で起きたこと

自動テストの世界に、この5年間で起きたこと
2025/02/13 Developer Summit 2025
Quality Evangelist 末村拓也による発表

Transcript

1. 自動テストの世界に、 この5年間で起きたこと 2025/02/13 Developer Summit 2025 Takuya Suemura Quality Evangelist @ Autify, Inc.
2. 自動テストの世界に、 この5年間で起きたこと （30分短縮版） 2025/02/13 Developer Summit 2025 Takuya Suemura Quality Evangelist @ Autify, Inc.
3. 60分セッションだと勘違いしていたからです え、なんで短縮版？
4. 今日話すこと Autify が正式リリース されて丸5年が経ちました 現在も NoCode Web と名を変えて ご愛顧頂いております （おれは2019年8月入社）
5. ノーコードで誰でも簡単 AIが自動でメンテナンス AIを用いたノーコードテスト自動化ツール
6. 5年の間に自動テストの技術やエンジニアのマインドセット 開発スタイルの潮流は大きく変わりました この発表では5年前のカスタマーペイン それに対してAutifyが提示したソリューションと 5年間で変わったものについて リリース前夜から同社にいた 一人の自動化エンジニアの視点から語りたいと思います 今日話すこと
7. タイトルタイトルタイトルタイトルタ イトルタイトルタイトル 小見出し小見出し小見出し小見出し 末村 拓也 (Takuya Suemura) Autify, Inc. (2019 -) Quality Evangelist • Ex. QA Manager • Ex. Senior Technical Support Engineer • Ex. Test Automation Engineer OPENLOGI (2017 - 2019) QA Engineer それより前はPHP開発をしていたり 倉庫でフォークリフトに載ったりしていました ソフトウェア品質や自動テストのあるべき姿を 業界の皆さんと一緒に考えるのが仕事です
8. タイトルタイトルタイトルタイトルタ イトルタイトルタイトル 小見出し小見出し小見出し小見出し テスト自動化実践ガイド (2024) Coming soon… (2025 Summer)
9. Pain & Solution 01.
10. • テストコードの作成が面倒 • テストコードのメンテナンスが大変 • 環境構築と運用が大変 2019年当時の課題感
11. • 当時は id や class などの内部構造を要素探索のキーにするのが一般的 • テストコードを書くたびにDevToolsと格闘 • リーダビリティ上も問題があった 当時の課題感 (1) テストコードの作成 ぼくのかんがえたさいきょうのE2Eフレームワーク with CodeceptJS
12. • E2Eテストは開発が終わってから ステージングなどの統合環境で実行され ることが多かった • リリースの直前になってテストが古いこと が分かると駆け込みでの修正を余儀なく されてしまう 当時の課題感 (2) テストコードのメンテナンス テスト自動化実践ガイド 第2章「開発を支える自動テスト」より
13. レコードアンドリプレイ型のツール 「Autify Recorder」 操作した内容が 自動で記録されていく スクリーンショット付きで見やすいのは UI自動テストにおいて大きなアドバンテージだった ソリューション (1) ノーコード
14. Autify Recorderで記録した要素のメタ情報を元に DOM上の「一番近い要素」を探索 ソリューション (2) メンテナンス AI メタ情報の例 • タグ名 • アクセシブルロール • id や class などの属性 • 文言 • 親要素や兄弟要素 • 要素の座標 • 絶対パス
15. Autifyユーザーの方が （サポートから聞いた情報を元に） 仕組みを図示してくれている！ 余談）この図について https://qiita.com/megmogmog1965/items/53a201e09929aea34657
16. やりたいことに対して 準備しないといけないことが多い ほぼ別のアプリケーションを 作るぐらいのレベル 当時の課題感 (3) 環境構築と運用 Software Testing 誌 2020年6月 「はじめよう、高速E2Eテスト」を元に一部加筆
17. 色々なところに互換性バグの種があった • Webサイトとブラウザの互換性（←見つけたいやつ） • WebサイトとWebDriverの互換性 • ブラウザとWebDriverの互換性 • 自動化コードとWebDriverの互換性 • WebDriver自体のバグ 自分のプロダクトの自動テストをしたいのに 自動テストフレームワークのデバッグからはじめないといけない E2E自動テストは本質的に複雑
18. Webサイト <> Selenium/Appium間で発生する ありとあらゆるエッジケースを踏み抜いたものたちだ、面構えが違う • deprecatedのCSSスタイル zoom を使うとクリック位置がおかしくなる • 古いバージョンの prototype.js は Array.reduce() などの prototypeを書き換えておりSeleniumを壊す • AMPのサイトは HTMLElement を上書きしており、 instanceof HTMLElement が期待した値を返さない • Appiumの nativeWebTap を有効にした状態で JSの scrollTo() でスクロールされる とタップ位置がズレる 余談）Autifyのテクニカルサポート
19. ソリューション (3) Out of the box Autifyクラウド（エミュレーター環境） Autify実機環境（Device Farm） Windows 10.11 macOS 80種類を超える端末から 自由選択 Edge/Windows server Chrome/Linux Chrome / iOS,Android 「箱から出してすぐ」並列実行やクロスブラウザテストができる • Autifyがホストしているクラウド環境は並列実行向き • デバイスファーム上でクロスデバイス・クロスブラウザテストが可能
20. 私たちがつくりました
21. 世の中に起きた変化 03.
22. • フロントエンドエコシステムとの統合 • リッチなデバッグ体験 • CI/CDパイプラインへの組み込みが楽になった ◦ 同時期に登場した GitHub Actions / CircleCI Orb などが後押しした • クロスブラウザ環境構築が楽に 新たなツール群はテストのハードルを下げた
23. • テストはテスト対象のふるまいに依存すべきである • E2Eテストは技術的制約から内部構造に依存しがちであった ◦ ID, class, タグ名など • Testing Libraryの登場と共に 文字列、セマンティクス、 alt-textなど アクセシブルな属性をロケーターに使う考え方が普及した アクセシビリティベースのロケーター Testing Library page.getByRole('button', { name: '送信' }); page.locator('input[type="button"]');
24. マインドセットの浸透 🦁
25. マインドセットの浸透 🦁
26. マインドセットの浸透 https://findy-code.io/engineer-lab/t-wada より引用
27. • 多くの人々🦁🥦による普及活動の末、 自動テストの重要性や TDD/BDD/ATDD といった考え方が浸透した ◦ この2人と17時からパネルやるから来てね • 高速なリリースサイクルが 開発生産性を支えるという考え方が浸透した 今やテストの話が無いカンファレンスの方が珍しくなりましたね マインドセットの浸透
28. 自動テストのこれから 04.
29. 自動テスト実装は簡単になったが、どんなテストを実装すれば良いか分からない • E2Eテストカバレッジを増やしたいけど 何をどうすれば増えるのか分からない • どのようなテストがあれば障害の予防に 効果的なのかが分からない テスト設計に課題を抱える会社が多かったが 非定型的な業務のため、改善が難しかった 新たに見つけた課題
30. 既存の自動化とは異なり • 何らかのフォーマットで定式化されて いなくても理解できる • 繰り返し実施する ものでなくても効果を発揮する 仕様書の分析・テスト設計のような ワンショットかつ複雑な業務も自動化できる可能性が出てきた LLMは既存の自動化に向いていないタスクを処理できる
31. テキスト以外の入力も扱える = モック・画面遷移図なども扱える マルチモーダル AIの登場 出展: [マルチモーダルAIとは？](https://www.aist.go.jp/aist_j/magazine/20231129.html)
32. 開発者の視点 ユーザーの視点 テスト手法の視点 様々なドキュメントをシナリオ生成に利用する テストシナリオ 作成 トレーニング済みの観点 要件 定義書 画面 設計図 仕様書 開発ドキュメント
33. • E2Eテストそのもののアーキテクチャーの複雑さ ◦ ブラウザが複雑である以上どうしようもない • トラブルシュートの労力 自動テストツールの選定において 「サポートとNDAに金を払う」側面は今後も捨てきれなさそう （テストツールのトラブルシューティングに情熱を費やす人、良かったら弊社に来て下さい 超楽しいと思います） 変わらないもの
34. • 自動化を進めたいが、目先のテスト業務に追われている ◦ 既に手動テストがたくさんあるような会社だとこの感じが多い • 全員がモダンな文化を受け入れているわけではないことも ◦ 便利なツールを入れる前に良い文化を入れる必要があるかも ◦ ？？「自動テストの工数は誰が払うんですか？」 ◦ ？？「自動テストより売上につながる機能開発が もちろん優先ですよね？」 ベストプラクティスと現実の狭間に揺れる人たちは今も昔も多い印象 木こりのジレンマと文化
35. テスト自動化導入支援・品質保証サービス 自動化カバレッ ジの向上 QAコンサルティ ング 開発・テストのア ジャイル化 自社運用までの 伴走支援 自動テスト 作成・運用代行 QAリソース 確保・工数削減 QAチームの 立ち上げ 自動化導入支 援検証（PoC）
36. • 自動テストは手動テストの代替ではなく 高速な開発サイクルの礎になるものである • 「リリース前にテストしたい」から「常にテストし続けたい」に ニーズが変化した 高度化したニーズに対応できる 新たなソリューションが必要 ニーズの高度化への対応 https://en.wikipedia.org/wiki/DevOps_toolchain
37. • E2Eテストは忠実だが低速 • それゆえに限定的な利用がベストプラクティスとされていた 技術の進歩が促進するもの https://gihyo.jp/dev/serial/01/savanna-letter/0005 https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications これはアンチパターン
38. 理想的にはE2Eテストは「ユーザーが取りうるふるまい」の 数だけ存在していてほしい E2Eテストが十分高速になれば 「実行可能なユースケースの 完璧なカタログ」も 実用的になってくるはず 技術の進歩が促進するもの テスト自動化実践ガイド 第1章「自動テストに取り組む前に」より
39. 今後、E2E テストを縛る技術的制約が飛躍的に改善 されれば、将来のベストプラクティスはむしろアイスク リームコーン型に近い形になるかもしれません。 開発者たちが必要とする最低限の単体テストと、信 頼性を保つための多くの結合テスト、そしてユーザー 目線での品質を保つ大規模な E2E テスト群を備えた テストスイートは、さながらアイスクリームパフェのよう な形になるでしょう（図 4-4）。 技術の進歩が促進するもの テスト自動化実践ガイド 第4章「E2Eテストとは何か」より
40. • テスト設計などの上流工程の自動化 ◦ 生成AIの力で現実的になってきた • より良いソフトウェアエンジニアリングを支える 技術と文化の実装支援 • 高速なフィードバックサイクルを支援するE2Eテストの進化 ◦ ユーザージャーニーを直接テストできる唯一のテストレベル ◦ 最も忠実度の高い実行可能なユーザージャーニーのドキュメント これから
41. AI-powered Quality Engineering Platform AutifyはAI, 生成AIを活用したプロダクトと 品質保証のプロフェッショナルがテストプロセスのすべてをサポート
42. 何でも相談に乗ってくれる Testing Baby 自動化関係ない、Autify関係ないことでもOK テストとDevOpsのスペシャリストとして 何でも相談に乗ります • 自社の開発プロセスについて第三者の目線から意見を聞 きたい • 理想の自動テストのあり方についてエンジニアたちとざっく ばらんに意見交換してほしい • 講演しにきてほしい • サインほしい 詳しくはAutifyブース or 懇親会でつかまえてください
43. Appiumのミートアップやるからみんな東日本橋来てくれ！ 最後に1つだけおしらせ
44. ご清聴ありがとうございました 60分フルバージョンは後日またどこかで Enjoy Testing!