Slide 1

Slide 1 text

E2Eテストを自動化したら 開発生産性はどうなった? 2024/6/28 開発生産性Conference 2024

Slide 2

Slide 2 text

目次 ● mablのご紹介 ○ mablについて ● E2Eテストを自動化したら開発生産性はどう なった?hacomonoの事例紹介 ○ はじめに ○ E2Eテスト自動化の挫折する壁 ○ hacomonoE2Eテスト自動化事例紹介 ○ 開発生産性どうなった? ○ まとめ ● お知らせ はじめに

Slide 3

Slide 3 text

はじめに スピーカー紹介 odasho (Shohei Oda) Quality Advocate / Product Marketing, mabl Japan 国内SIerにてインフラやPaaS App開発まで幅広く経験。その後 コミュニティ活動をきっかけにMicrosoftに入社。Evangelistと してAudience Marketingに従事。2022年10月にmablにJoin、 TestingやQAの啓蒙活動に取り組む。現在もDevRel Meetup in Tokyoやmablers_ jpを中心に複数のコミュニティを運営/支援。 書籍執筆など。iPhone絶対並んで買うおじさん(2011 - 2023) Most DevRel Committer 2020、名城大学情報工学部非常勤講師 odashoDotCom odasho0618 odasho Ryo Morishima QA / SET Engineer, hacomono inc. ワークスアプリケーションズにて製品開発やチームマネジメント に従事したのち、開発チームの開発生産性向上をミッションに自 動テストなどに取り組む。テストを通した品質への興味が強くな り、その後MIXIにてQAエンジニアやスクラムマスターとして幅広 く品質向上活動を経験し、2023年11月にhacomonoにSETエンジ ニアとしてjoin。E2E自動テストを中心とした品質向上活動に従 事。 m39ryo

Slide 4

Slide 4 text

mabl について

Slide 5

Slide 5 text

What's mabl? ● 「めいぶる」と読みます ● Stackdriver(現Google Cloud Operations)の 創業者IzzyとDanが2017年ボストンで創業 ● 2021年8月に日本法人設立 ● グローバルの社員数は約110名 ● Fortune Globalの35社含む300社+が採用 ● GV、CRV、Amplify、Vista Equity Partner、 Presidioより 7,700万ドル (120億円) を調達 mabl について

Slide 6

Slide 6 text

アクティブユーザー数 48% 2% 13% 2% 2% 12% 21% mabl について

Slide 7

Slide 7 text

Web/Mobile/APIのための統合型プラットフォーム AI、クラウド、ローコードの 最新テクノロジーを軸に 構築されたプラットフォーム Web、モバイル、APIテストを 単一のプラットフォームで実行 テストの再利用性を備えた 真のエンドツーエンドテスト mabl について

Slide 8

Slide 8 text

Home grown mablの裏側 mabl について

Slide 9

Slide 9 text

ノーコードでテストを作成、ローコードで拡張 mabl について テスト作成の流れ 1. ブラウザでテスト対象アプリを 操作 2. トレーナー(右側ウィンドウ) が各操作をステップとして記録 してテストを作成 3. 必要に応じてステップの追加・ 削除・変更が可能

Slide 10

Slide 10 text

単一プラットフォームで広範囲なテストをカバー mabl について 機能/非機能テストをカバーするプラットフォーム ● Web UIテスト ● モバイルWeb UIテスト ● APIテスト ● アクセシビリティテスト ● UI/API パフォーマンステスト ● NEW! ネイティブモバイルアプリテスト

Slide 11

Slide 11 text

Join mabl webinar 7/11 14:00 ~ 15:00 モバイルアプリテストの最新トレンドと モダンなテストとは? お知らせ https://www.mabl.com/ja/webinar/lp/modern-mobile-app-testing

Slide 12

Slide 12 text

(機能強化) 生成AIが言語理解をサポート 要素の検索モデル DOM エキスパートシステム Autonomous Agent mabl について

Slide 13

Slide 13 text

アプリケーション内の要素が大幅に変更され、 テスト対象要素が見つからない場合に、テスト を自動修復を試みる。 80%程の精度だった従来の自動修復機能に生成 AIを組み込み、95%まで修復精度が向上。 テストで出力されるLog上にテスト結果だけで なく判断内容を記載。 GenAIによる作成済みテストの高度な自動修復 mabl について

Slide 14

Slide 14 text

より複雑なテストシナリオのためにJavaScript スニペットの作成が必要な場合には、生成AIに よるスニペット生成支援の機能を活用して作成 可能。 作成したいスニペットについて、プロンプトを 用いて指示を記載することで、サンプルコード を出力。 GenAIによるJavaScriptスニペット作成支援 mabl について

Slide 15

Slide 15 text

アサートとは、『アプリケーションが期待した 動作通りに動くか』を確認すること。 例えば『パスワード未入力でログインボタンを 押したら、パスワード入力を促すメッセージが 表示されること』など。 『GenAIによるアサーション』はプロンプトを 活用して、より複雑なアサート処理をテスト ステップに組み込むことが可能。 右の例では『画像の背景に山が表示されている こと』をプロンプトベースでテストし、結果や 判定理由も併せて表示。 GenAIによるアサーション mabl について

Slide 16

Slide 16 text

Join mabl webinar 7/25 14:00 ~ 15:00 統合型ノーコードテスト自動化プラット フォーム 『mabl』ご紹介ウェビナー お知らせ https://www.mabl.com/ja/webinar/lp/mabl-introduction-webinar

Slide 17

Slide 17 text

既存ツールとの統合 mabl について メッセージング Issue管理 アナリティクス Jira Slack Teams BigQuery CI/CDツール GitHub GitLab Jenkins Bamboo BitBucket Azure CircleCI Octopus https://www.mabl.com/integrations Mabl CLI Mabl API

Slide 18

Slide 18 text

hacomono 活用事例

Slide 19

Slide 19 text

19


Slide 20

Slide 20 text

hacomonoの特徴について はじめに ● 管理者様向けサイト(管理サイト)、利用者様向けサイト(メンバーサイト)など 複数のWebサイトが存在する ● 管理サイトでメンバーサイトのカスタマイズができる 設定によりメンバーサイトの振る舞いが変わる ● メンバーサイトでレッスンを予約すると 管理サイトに予約状況が反映される ▶それぞれのサイトを行き来するようなシナリオが多く複雑

Slide 21

Slide 21 text

本セッションで伝えたいこと はじめに ● E2Eテスト自動化の挫折しやすい壁を知る ● E2Eテスト自動化の壁を乗り越えるの事例を知る ○ 自動化にどんな目標を掲げていたか ○ 壁を乗り越えてどんな結果が得られたか ● 自動テストを開発生産性向上につなげるヒントを掴む ● 自動テストをはじめるきっかけを持って帰ってほしい

Slide 22

Slide 22 text

本セッションの対象者 はじめに ● これからE2Eテストの自動化を始めようと考えている方 ● E2Eテストの自動化を何から始めればいいか検討中の方 ● E2Eテストを自動化の運用に悩んでいる方 ● E2Eテストを自動化によりどんな効果が得られるか他社事例が知りたい方

Slide 23

Slide 23 text

E2Eテスト自動化 挫折する壁

Slide 24

Slide 24 text

テスト実行までの道のりが長い E2Eテスト自動化の挫折しやすい壁 ● 自動テストの環境構築に挫ける ○ コマンドライン操作によるツールのインストールや ツールの英語ドキュメントを読みながらエラーを解消したり 慣れない人には環境構築の難易度が高い ● テストの作成に挫ける ○ ロケータなど基礎知識がないと 要素選択して操作するのに苦戦する

Slide 25

Slide 25 text

運用が続かない E2Eテスト自動化の挫折しやすい壁 ● テストを実行できた! ただ運用し続けるための工数が取れない… ○ 仕様変更によりメンテナンスが追いつかない ○ 新しい自動テストの作成工数が取れない ○ テストが安定しないため失敗原因の切り分けに工数が取られる ● 次第に自動テストの失敗が多くなり 実行もされなくなってなり頓挫…

Slide 26

Slide 26 text

hacomono流 壁の乗り越え方 テスト実行までの道のりが長い壁 ● mablで環境構築の手間なく圧倒的スタート ダッシュできた ● 最初に実装する自動テストを厳選した ● 実現したいテストが素早く検証ができた ● テストが常に実行されている状態にできた ● 簡単Slack連携で実行結果を通知できた 運用が続かない壁 ● テスト自動化担当を任命した ● 運用ガイドラインを作った ● 保守性が高いテストを作った ● 自動化対象のテストを整理し直した E2Eテスト自動化の挫折しやすい壁

Slide 27

Slide 27 text

hacomono E2Eテスト自動化 事例紹介

Slide 28

Slide 28 text

mabl導入前のhacomonoの状況 E2Eテスト自動化事例紹介 ● hacomonoにQAが存在しない ○ 第三者検証機関の方にテストをおまかせしていた ● 2週間ごとのリリースサイクル リリース前にリグレッションテストを実施している ● hacomonoに機能が爆速で増え続ける ○ リグレッションテストが山のように増えていく ● フロントエンドの自動テストは充実していない

Slide 29

Slide 29 text

E2Eテスト自動化導入のきっかけ E2Eテスト自動化事例紹介 ● 工数削減:当時約11人日かかる手動リグレッションテストの実施工数を減らしたい ○ 管理者向けサイトの実施工数:4.5人日 ○ 利用者向けサイトの実施工数:6.3人日 ● フロントエンドに対するテストを兼ねたい ▶どちらも目的としてあまりおすすめしない

Slide 30

Slide 30 text

mablの導入へ ● 複数のツールを選定して結果、mabl が一番マッチしていた ○ 誰でも自動テストが実装できること ○ メンテナンス性が高いこと ○ エンジニアも利用できること ■ JavaScript ○ 自動化を実現したいシナリオが構築 できること E2Eテスト自動化事例紹介

Slide 31

Slide 31 text

自動テストを始める壁を登る E2Eテスト自動化事例紹介 ● mablで環境構築の手間なく圧倒的スタートダッシュできた ○ 準備はmablアプリのインストールだけ ○ 当時は英語のヘルプページだったけど読まなくてもわかる 直感的なUIに助けられた ● 実現したいテストが素早く検証ができた ○ 操作を記録するだけで簡単に自動テストが作成され、つまずかない ■ サイト間の移動ができる、サイトごとのウィンドウサイズに対応する、 タブ移動ができる、など

Slide 32

Slide 32 text

自動テストを始める壁を超える E2Eテスト自動化事例紹介 ● 最初に実装する自動テストを厳選した ○ まずは画面遷移・CRUD操作ができるテストのみを実装 ○ 自動テストを量産しすぎず気軽に実行できるように ● テストが常に実行されている状態にできた ○ スケジューリングで定期的に実行 ○ デプロイ後に自動でテストを実行 ● 簡単Slack連携で実行結果を通知できた ○ 定期実行される結果を常に見ることで実感と安心感を得た

Slide 33

Slide 33 text

運用継続の壁を登る E2Eテスト自動化事例紹介 ● テスト自動化担当を任命した ○ まずは一人自動化できる人を創出する 自分がやるという使命感 ○ 実行結果を見て、粘り強くメンテ!メンテ!!メンテ!!! ■ 実行結果から原因を推測しやすいのが救い ■ 実装や失敗原因の勘も掴んでくる ■ 失敗が多くても負けないで!

Slide 34

Slide 34 text

運用継続の壁を登る E2Eテスト自動化事例紹介 ● 運用ガイドラインの作った ○ 命名規則や実装フローなど言語化した(詳細はテックブログへ) ■ 一人担当でも実装に迷わず統一感を持って進められた ● 保守性が高いテストを作った ○ すべて再利用可能なステップとして定義した(mablのFlowを利用) ■ 一連処理が日本語で定義されているので何をしているかぱっと見わかる ■ 仕様変更があったときのメンテナンス工数が最小(実装工数はやや重い)

Slide 35

Slide 35 text

運用継続の壁を超えていく ● 自動化対象のテストを整理し直した ○ リグレッションテストを自動化することは 決まっていたが、当時のリグレッションテ スト管理シートでは自動テストが管理しに くかった E2Eテスト自動化事例紹介

Slide 36

Slide 36 text

運用継続の壁を超えていく ● 自動化対象のテストを整理し直した ○ わかりにくいテストケース名を、中身を見ず とも管理できるように修正した ○ 優先度もこの機会に見直しした        ▼ ● 整理したことで見通しがよくなり、何を自動 化するかが明確になった ● 優先度が高いリグレッションテストから自動 化に着手することで、自動化のスピードが アップ E2Eテスト自動化事例紹介

Slide 37

Slide 37 text

運用継続の壁を超えていく ● 最近mablが進化して運用継続がさらに 容易に ○ 高度な自動修復により少しくらいの仕 様変更は乗り越えてくれる ○ 日本語のヘルプが充実、爆速返信の日 本語チャットサポート ○ 生成AIがJavaScriptを自動作成してく れる E2Eテスト自動化事例紹介

Slide 38

Slide 38 text

自動テストの範囲は拡大へ E2Eテスト自動化事例紹介 ● リグレッションテストの自動化数は約110シナリオに増加中 ○ テスト自動化率は約90%まで到達 ● 自動化担当以外にも利用を普及中 ○ QAメンバーも増えたので、E2Eテスト自動化ワークショップを開催して 一緒に自動テストを進めていく

Slide 39

Slide 39 text

現在のmabl運用状況 E2Eテスト自動化事例紹介 ● 2週間に1回リリース前にmablアプリから手動で実行 ○ 約110シナリオを最大46並列で実行 ● テスト成功率が平均80%超 ○ 2名体制で失敗原因を切り分け ● mablのプラン上限実行回数の500件/月のテストを実行

Slide 40

Slide 40 text

開発生産性は どうなった?

Slide 41

Slide 41 text

E2Eテスト自動化から得られた効果 開発生産性はどうなった? ● リグレッションテストの約8割の工数削減に成功 ● 自動テストから不具合の発見につながっている ● 探索的テストなど人ならではのテストを実施できる余裕ができた ● 急なリグレッションテストの実施も対応しやすくなった 約 2人日 2022年 2024年 約11人日

Slide 42

Slide 42 text

得られた効果と開発生産性 開発生産性はどうなった? ● 当初のテスト自動化目的は達成に近づいている ● 開発生産性には影響が少ない ○ 自動化前と後でテストの実施頻度が増えていない フィードバックの機会はリリース前に一度だけ ■ 自動化導入はじめが一番実行頻度が高かった ▶なぜ実行頻度が増えなかったか?

Slide 43

Slide 43 text

自動テストの実行頻度が増えなかった理由 開発生産性はどうなった? ● 自動テストを気軽に実行できなくなった ○ テスト実行前にテストデータの投入が必要 ● 再実行すると失敗してしまい冪等性がないテストが複数ある ○ 事前投入データに依存するテストのため 再実行には再度データ準備が必要

Slide 44

Slide 44 text

自動テストの実行頻度が増えなかった理由 開発生産性はどうなった? ● テストの成功率が平均80%と低い ○ 2人日の工数のほとんどは自動テスト失敗原因の切り分けと再実行 ○ 失敗が多くなるので再実行でmablの実行回数を消費してしまう

Slide 45

Slide 45 text

自動テストの実行頻度が増えなかった理由 開発生産性はどうなった? ● mablプランの実行回数を意識しすぎた設計にしてしまった ○ 導入から2年ずっとスタートアッププラン(実行回数上限:500回) ○ 「500回以内に実行数を超えないように」というバイアスが働いてしまった ■ 1実行あたりのROIを上げるために1つのテストケースが長くなり 失敗が多くなる ■ もったいないので再実行はローカル実行で確認して 効率が悪くなる

Slide 46

Slide 46 text

自動テスト効率は悪くなるループをたどる 開発生産性はどうなった? ● テスト失敗時の切り分け工数が出せず実行頻度を増やせない         ▼ ● 間が空き、その間にたくさん仕様変更や修正が入る         ▼ ● 失敗が減らずに原因切り分けに時間がかかる         ▼ ● 実行上限を気にしてもったいないから再実行はローカルで実行

Slide 47

Slide 47 text

目標を次のステージへ 開発生産性はどうなった? ● 「工数削減」から「開発生産性の向上」へ ○ リグレッションテストを自動化することはもう大丈夫! これからも続けられる ○ そのために実行頻度を増やすための対策を打つ

Slide 48

Slide 48 text

対策:実行回数上限を引き上げる 開発生産性はどうなった? ● 来期からプランのアップグレードする(実行回数上限:1000回) ● 成功率が高い自動テストは月2回→週1回→毎日とだんだんと実行頻度を上げる ○ テストごとの成功率はmablのカバレッジ画面から確認できる ● 失敗率が高い自動テストは失敗箇所の傾向を特定をして剪定する ○ 実行対象から外すことも検討する

Slide 49

Slide 49 text

対策:冪等性のあるテストへ 開発生産性はどうなった? ● 「テスト外」ではなく 「テスト内」で必要な前提条件データを準備する方へシフトする ● できるだけ前提条件データを安定性高く投入するため APIによる画面操作を伴わないデータ投入方法を検討する

Slide 50

Slide 50 text

対策:mablのROIを評価する 開発生産性はどうなった? ● 「テストいっぱい実行して開発生産性上げたいです!」では投資しづらい ○ mablによるテスト自動化を始めるときも一緒 ● 自動化担当者も役に立っている”気がする”けど どのくらいなのかはちゃんと把握していない ○ 予算交渉しづらくなる

Slide 51

Slide 51 text

E2Eテスト自動化による開発生産性向上のカギ ● 自動テストをいつでも動かせるようにする ● 自動テストを定期的かつこまめに実行する ● 自動テストを信頼できるように安定させる 開発生産性はどうなった?

Slide 52

Slide 52 text

まとめ ● mablを使うと素早くE2Eテスト自動化を始められた ● 運用を続けるサポートもmablに備わっている ● mablを使ってリグレッションテスト工数の削減ができた ● ただしツールは万能ではない… 人間が戦略を考える必要があり、勝手に開発生産性は上がらない ● 目的に合った使い方になっているか定期的にチェックと評価を!

Slide 53

Slide 53 text

おわりに ● 開発生産性にフォーカスしましたが 工数削減を目的としたテスト自動化は悪ではない ○ テスト自動化をしてみてたくさん学んだことがあった ■ 自動化のコツやロケータ、javaScript、APIなど開発知識から 自動テスト戦略までさまざま ○ テスト自動化にも慣れて次のステージにも向かう勇気も持てた ● hacomonoの事例がこれから自動化を始める方の 一歩を踏み出す勇気になることを願ってます

Slide 54

Slide 54 text

お知らせ

Slide 55

Slide 55 text

About the mabl University お知らせ How-to Videos (English only) How-to Lessons (Japanese only) On-Demand Training (English & Japanese) mabl Skills Certifications (English & Japanese) ● 33 ビデオ (各3 - 8 分程度) ● 英語字幕あり、日本語字幕なし ● 26 レッスン ● Step by stepで学習可能 ● 4 ラーニングパス ● 設定、基礎、高度、統合でそれ ぞれ30 - 90 分の学習パス ● 学習目標に応じたパスを提供 ● 3 つの資格 ● Foundations と Advanced ● NonFunctional ←NEW ● LinkedIn に掲載可能

Slide 56

Slide 56 text

mabl Skills Certification mabl Skills Certification: Foundations (基本レベル) mabl Skills Certification: Advanced (応用レベル) お知らせ mabl Skills Certification: Non-functional Testing (非機能テスト)

Slide 57

Slide 57 text

Thank you for joining‼ お手元のアンケートにご回答お願いします! ブースに持ってくると良いことあるかも…?