AI系E2Eテストツール 導入後に広がる景色 〜紆余曲折の軌跡〜 STAC2021/12/11 株式会社SHIFT 矢野崇 1

登壇の背景 WEBアプリのテスト自動化をSelenideで行っていた現場で キャプチャ&リプレイ型のAI系テストツール(以後ツールと表記)を 今年3月に導入し検証、4月から本格的に運用を開始しました テスト活動にどのような変化や気づきがあったのか 事例をもとに紆余曲折をご紹介します ※Selenide：Selenium WebDriverをラップしたOSSフレームワーク 2

本内容の前提 ● ツールはAutifyを使用しています ● 特定のツール、ソフトウェアの推奨や非推奨をするものではありません ● ツール自体の細かい機能やTipsを紹介する内容ではありません ● ツール導入後の変化を大局的に捉えたもので抽象度は少し高めです ● 月1回のリリースサイクル、テスト環境へのデプロイは週に数回行われる 現場での導入事例で、他の現場でも同様の事象が起きるとは限りません ● 現時点での景色のスナップショットであることをご理解ください 3

ツール導入前の状況① ● テストは手動での実施がメイン ○ テスト自動化を導入し推進していくタイミング ● SelenideでE2Eテスト自動化の導入を実施 ○ ハッピーパステストや手動で実施するのが大変なリグレッションテスト(RT)は自動化 ● KarateでAPIテスト自動化の導入検証も行っていた ○ API自体のテストやAPIで確認できるRTはAPIテストで実施 4

ツール導入前の状況② ● 更にテスト自動化の推進を行うためにツールの選定と導入を行う ○ キャプチャ&リプレイで簡単に自動化 ○ ブラウザバリエーション(Chrome,Edge,IE)対応のコスト削減 ○ セルフヒーリングAIによるテストメンテナンスの軽減 5

実際に導入してみた 6

ツールが解決してくれたこと① ● テスト自動化を誰でも簡単に作成し実行、メンテナンスできる ○ ノーコードツールなので自動化のためハードルが下がる ■ コーディング ■ 構造化, 共有化のためのデザインパターン ■ テストレポートでの可読性担保 ○ テストを安定化させるための実装に悩むことが減る ■ 要素のロケータ選択 ■ 待機処理 ○ 消して作り直すのもやりやすい ➡ E2Eテスト自動化がスケール 7

ツールが解決してくれたこと② ● SaaS上でシナリオの共有と管理、実行が可能 ○ 自動化のための環境構築不要 ○ バージョン管理システムの知識も不要 ● テストシナリオの可読性が担保される ○ ステップ毎に画面キャプチャもある ○ 保存されたテストシナリオの操作手順がわかる ● テスト結果の失敗原因がわからないときCSサポートに頼れる ○ E2Eテストコード側の調査をしなくてよい ○ 技術的要素が隠蔽されているのでSUT(System Under Test)に向き合える 8

キャプチャ&リプレイの進化 キャプチャ&リプレイはテスト自動化ではないと言われていた ● 作った人にしかテストがわからない ○ キャプチャしたテストスクリプトの可読性の悪さ ○ リプレイ後のテスト結果の可読性の悪さ ● 入力の自動化になりがち ○ テスト結果のチェックがないと入力の自動化であって テストの自動化にはならない ● メンテナンス性の悪さ ○ SUTの変更の度にキャプチャをとりなおし ➡ 昨今のツールはSaaS上のUIやセルフヒーリング 　といった技術で欠点の多くをカバーしている Mark Fewster; Dorothy Graham. テスト自動化研究会 (訳) 「システムテスト自動化 標準ガイド」 1版.翔泳社.2014,p765 9

ツール導入後の変化 ● RT実行にかかっていた時間をテスト設計や分析、探索的テストなどに使える ● 自動化エンジニアは非機能系のテストやAPIテスト自動化に時間を使える テストリーダー テストエンジニア 自動化エンジ二ア E2Eテスト自動化 + APIテスト自動化 APIテスト自動化 + 非機能系テスト ツール導入 E2Eテスト 自動化 10

ツールでは解決できなかったこと ● ツールの機能で実現できない操作を含むテストの自動化 ○ ファイルのダウンロード、ファイルの中身確認 ○ 大容量ファイルのアップロードなどツールに制限されるもの ○ 複数ユーザーをシミュレートするテスト ● IE(Internet Explorer)対応 ○ テスト自動化では対応工数掛かりがち ■ ツールとSUTとの相性が悪かった ○ JS(JavaScript)ステップで対応することは可能だがツールの利点が失われる ➡ IEのテストはしばらく手動で行っていたがサポート対象から外れた ● Microsoft社のIEサポート終了に伴うプロジェクトの判断 ● 時間が解決してくれる問題もある 11

ツールの利点を失わないためのJSステップ利用方針 ● JSステップを増やしすぎると失われる利点 ○ テスト実装、メンテナンス人員が制限 ○ テストシナリオの可読性低下 ● JSステップの利用は必要最小限に ○ 1シナリオ中にどうしても必要な数ステップ ■ メール内のパスワードを正規表現で取得したい時 ■ アサーションに日時情報の利用など数値計算が必要な場合 ➡ JSステップが大量に必要なテストは、Selenideなど別手段を選択 12

Selenideとの対比 Autify Selenide Pros ● キャプチャ&リプレイによる 自動化が誰でも可能 ● SaaSノーコード開発で実装 ● AIによるセルフヒーリングで 画面の変更にある程度強い ● 構造化、共有化で再利用が簡単 ● ファイルのダウンロードやチェック ● 複数ユーザのテスト ● 痒い所に手が届く(Java) Cons ● ファイルダウンロードできない ● ファイルアップロードも制限ある ● テスト手順の変更時は 再度キャプチャが必要 ● ない機能は要望を出して待つ ● コーディングが必要で 自動化できる人が限られる ● メンテナンスできる人も限られる ● ロケータの指定次第で画面変更に弱い 13

極力ツールに寄せていくテスト手段の選択フロー DnDの操作 部分を切り分ける ファイルダウンロード 部分を切り分ける Yes NO ドラッグ& ドロップ操作 が必要？ 手動実行 DnD操作あり DnD 操作なし ファイル ダウンロードが 必要？ NO Autify Yes ツールで 使用できない ファイル アップロードが 必要？ Yes NO ファイルアップロード 部分を切り分ける Selenide Selenide DL操作あり UL操作あり DL 操作なし UL 操作なし 14

ツール導入直後の景色 E2Eテスト自動化がスケール ⇩ テスト自動化の民主化 テスト自動化の経験やスキルがなくても簡単に自動化できる これまでのキャプチャ&リプレイツールの欠点の多くをカバーしている 当然ツールには得手不得手がある ⇩ 手動テストはもちろんのこと別のテスト自動化の手段と 組み合わせて使用することで それぞれの強みを活かすことができる 15

しばらく運用を続けてみた 16

運用を続けていくと顕在化した問題 1. テスト実行方法が様々なところに分散してしまう 2. テスト結果レポートが集約されない 3. 肥大化するE2Eレベルの自動テスト 17

1.テスト実行方法が様々なところに分散してしまう ● Autify ○ SaaS上のテストシナリオ、テストプランを選択して実行 ● Selenide ○ E2Eテスト用リポジトリのGitHub Actionsからテストシナリオを選択して実行 ● Karate ○ APIテスト用リポジトリのGitHub Actionsからテストシナリオ選択して実行 ➡「このテストどこから実行するんだっけ？」状態 18

スプレッドシートから管理と実行をする ● 各種テストをスプレッドシートで管理しつつシートからの実行も可能に ○ 実行のためにツールやGitHubにログインしなくてもOK ○ GAS(Google Apps Script)でテスト実行用APIをリクエスト ➡「誰でもテストを実行できる」状態 19

2.テスト結果レポートが集約されない ● Autify ○ SaaS上にリプレイしたテスト結果 ● Selenide ○ GitHub ActionsのArtifactやGithub PagesにAllureテストレポート ● Karate ○ GitHub ActionsのArtifactやGithub PagesにKarateテストレポート ➡「テスト結果それぞれ見に行くの大変」状態 20

テスト結果のサマリをチャットに通知する ● Autify ○ Slack連携機能 ○ 失敗時や要確認の場合に通知内の URLリンクから詳細確認 ● Selenide、Karate ○ GitHub Actionsで通知用Stepを追加 ○ 失敗時に通知内のURLリンクから詳細確認 ➡「いつでも誰でも結果を確認できる」状態 21

3.肥大化するE2Eレベルの自動テスト E2Eテスト自動化がスケールして高速に作られるようになったということは... E2E IT UT E2E IT UT E2E IT UT 新機能リリース毎やテスト観点追加の度に肥大化 22

E2Eテスト自動化の問題 小規模テストから大規模テストへとピラミッドの段階が上がるにつれて、 各テストの再現性は向上しますが、 実行時間と保守およびデバッグの労力が増大します 。 したがって、統合テストより単体テストを増やし、 エンドツーエンドテストより統合テストを増やす必要があります。 https://developer.android.com/training/testing/fundamentals 23

ツールでE2Eテスト自動化の問題を全て解決できる訳では無い ● GUIを通してのテストの欠点 ○ 並列実行である程度軽減できるが実行時間がかかる ○ テスト結果のフィードバックも開発工程の最終辺りに ● 未解決のキャプチャ&リプレイの欠点 ○ 自動テストを先に実装できない ○ 操作手順の変更時にはメンテナンスが発生 ■ セルフヒーリングで軽減できるのはメンテナンス工数の一部 ➡　アジリティの限界が存在する 24

テスト結果のフィードバックループ比較 E2Eテストの場合 1. テスト担当者がテスト失敗を確認 2. SUTの問題か判断 3. バグの報告や起票 4. 開発者バグ確認 5. 開発者バグ修正 6. デプロイ 7. テスト実行(自動テスト含め) 8. テスト担当者が修正確認 9. 起票したチケットをクローズ ユニットテストの場合 1. 開発者がテスト失敗を確認 2. コード修正 3. 自動テスト実行 4. 開発者が修正確認 https://www.stickyminds.com/article/shift-left-approach-software-testing 25

E2Eテストだけで品質を保証する難しさ ● 上流テストをしなければ、下流テストをいくらしても 大きなリスクをもって出荷することになる ● 上流テストをしなければ、多くのバグを後半で つぶすことになり、出荷日を優先することにより、 ある確率でつぶしきれないバグが残る可能性がある 高橋寿一.『ソフトウェア品質を高める開発者テスト』 .1版.翔泳社.2021, p224 26

アジリティと品質を高めるテスト自動化が必要 テストを適切にテストピラミッドの下段に押し込んでいく コントロールが求められる 開発側と協力して推進していく必要性あり(現在推進中) E2E IT UT 27

ツール導入後の景色 E2Eテスト自動化がスケールし高速化 ⇩ テスト自動化の民主化 新機能にも自動テストを素早く追従させメンテナンスすることができる プロダクトに関わる人が誰でもテスト自動化できる時代 E2Eテスト自動化の問題を全て解決できる訳ではない ⇩ アジリティと品質の限界が存在 リリースサイクルや新機能のデプロイ頻度によっては ツールを頼りすぎるとボトルネックとなる 28

最後に SHIFT EVOLVEというオンラインイベントの運営をやっています ご興味あるときに是非遊びに来てください！ ご清聴ありがとうございました https://shiftevolve.connpass.com 29