CI/CDパイプラインに E2Eテストを統合する 2022/04/21 DevOpsDay Tokyo 2022 Dai Fujihara mabl Inc.

About Me 『アジャイル開発とスクラム』 https://www.amazon.co.jp/dp/4798129704/ 、『リーン開発の現場』 https://www.amazon.co.jp/dp/427406932X 藤原 大 / Dai Fujihara mabl Japan 株式会社せかい代表 ● 現在： 独立してスーパーアジャイルコーチ 開発組織の技術顧問（プロセス、 QA中心） CTOやEMへのコーチング mablの日本顧客向けサポート ● メルカリ： エンジニアリングマネージャ（ EM) Software Engineer in Test（SET) テスト自動化、QA組織立ち上げ ● 楽天： EM、アジャイルコーチ ● 某SIer： Javaエンジニア ● 活動: ○ 『アジャイル開発とスクラム』寄稿 ○ 『リーン開発の現場』翻訳 ○ Twitter: @daipresents ○ Blog: https://daipresents.com/service/

E2Eを考える前に 何をE2Eにするのか？ どんなE2Eになるのか？ どこでE2Eを実行するか？

アジャイル開発は「当たり前」に Agile is the new normal https://softwaretestinggenius.com/docs/4aa5-7619.pdf KPMG Global Agile Survey https://assets.kpmg/content/dam/kpmg/be/pdf/2019/11/agile-transformation.pdf 15th State of Agile Report https://digital.ai/resource-center/analyst-reports/state-of-agile-report ● HPによる調査では、24%がハイブ リッド、67％がアジャイル開発へ (2017) ● KPMG Global Agile Surveyで は、今後3年で企業レベルのア ジャイル開発が2倍以上増えると 予想（2019) ● digital.aiの調査では86%がア ジャイル開発を採用（2021)

DevOpsは「過渡期」に 2021 State of Testing in DevOps Benchmark Report, mabl

データ：短期間でのデプロイ回数が増加 2020 Testing in DevOps Benchmark Survey, mabl 年ごと Qごと 月ごと 2週間ごと 週ごと 日ごと 日に何回も 1日ごと、1週間ごと、2週間ごとのリリースが急増

何が問題になっているのか？ 開発がアジャイルなのに テスト・品質がウォーターフォール 軽量なプロセスに重量なテストをする場合、 4〜5チームを超えると生産性を落とさずスケールしなくなる傾向がある。

何が問題になっているのか？ QA = テストすること QA = テストする人 という組織文化 バグというモグラを叩き続けても品質は良くならない。

何が問題になっているのか？ 品質の保証 軽量な高速プロセスで品質保証（ QA: Quality Assurance）できるか？何を保証するのか？ そもそもシステムは落ちないように作っておらず、落ちる前提で（復旧しやすいように）作っている。 品質もそのように考えると品質合意（ QA: Quality Agreement）が妥当ではないか？

CI/CDパイプラインにE2Eテストを統合する テストがプロセスに統合される テストがプロセスに関わるチームに広がる テストが長持ちする

E2Eを考える前に 何をE2Eにするのか？ どんなE2Eになるのか？ どこでE2Eを実行するか？

AIを活用したブラウザテスト自動化サービス ● ボストンボストンで創業 （シリーズC） ● AI・クラウド・SaaS型 テスト自動化サービス ● ノーコード・ローコードで テストの作成や修正可能

ノーコード・ローコードでかんたんにテスト作成 ● mablトレーナーがテスト 作成・修正をサポート ● ひとつの動きをステップで 記録 ● ステップを並べてシナリオ として管理

mablの 簡単なデモ （ログイン） 14

ビジュアルテスト・ビジュアルリグレッション ● 動きの正しさだけでなく見た目の正 しさもテスト可能になった ● ステップベース、URLベース、ク ローリングベースで実行可能 ● 実行ログ、APIログ、リンク切れ、コ ンソールエラーなども検知可能

No content

Visual Test (Visual Regression, Screenshot test)

API 統合されたエンドツーエンドのテスト ● ノーコードでAPIテスト ● レスポンスを変数に格納等、APIをシナリ オ形式で実行可能 ● Postman双方向連携 ● マイクロサービス向けの統合テストとして も利用可能

mablの 簡単なデモ （APIテスト） 19

APIでデータ準備、Eメール経由のテスト、 PDFをダウンロードしてバリデーション、指定 した要素を検索、アクセシビリティチェック・・・

E2Eを考える前に 何をE2Eにするのか？ どんなE2Eになるのか？ どこでE2Eを実行するか？

どういう範囲ですべきか？ テストの 広さ メリット デメリット スモークテスト 狭い ・実行速度が速い ・はやくFBが得られる ・プロセスに組み込みやすい ・実行回数が増える リグレッション 普通 ・範囲を選んで実行すれば、 必要なテストを必要なだけ実 行可能できる ・実行時のスコープぎめが重要に なる フルリグレッション 広い ・安心感が高い ・実行時間が長い ・メンテコストが高い

範囲ごとに比較（E2E） 用途 タイミング 効果 スモークテスト ・E2Eレベルの動作確認テスト（ ふ るまい） ・範囲が狭いので気軽に実行でき る コミットごと、PRごと など ・動いてないじゃんブ ロッカーを減らす リグレッション ・E2Eレベルの動作確認テスト（ ふ るまい） ・範囲を絞って効率的に実行できる Mainブランチマー ジごとなど ・修正のリスクを減らす フルリグレッション ・E2Eレベルの動作確認テスト（ ふ るまい） ・時間はかかるが広範囲で実行で きる リリース前 ・結合リスクを減らす

範囲ごとに比較（VisualTest） 用途 タイミング 効果 スモークテスト ・画面確認テスト（見た目） ・範囲が狭いので気軽に実行でき る コミットごと、PRごと など ・E2Eよりさらに簡単に 動作確認できる ・本番テストとして簡単 実行できる（影響も小さ い） リグレッション ・画面確認テスト（見た目） ・範囲を絞って効率的に実行できる Mainブランチマー ジごとなど ・修正のリスクを減らす ・本番テスト フルリグレッション ・画面確認テスト（見た目） ・時間はかかるが広範囲で実行で きる リリース前 ・結合リスクを減らす ・本番テスト

範囲ごとに比較（API） 用途 タイミング 効果 スモークテスト ・APIレベルのテスト（網羅性） ・範囲が狭いので気軽に実行でき る コミットごと、PRごと など ・エンドポイント全体の 疎通テスト ・高速なので網羅性を高 められる リグレッション ・APIレベルのテスト（網羅性） ・範囲を絞って効率的に実行できる Mainブランチマー ジごとなど ・エンドポイントを選んで 疎通テスト ・網羅性テスト フルリグレッション ・APIレベルのテスト（網羅性） ・時間はかかるが広範囲で実行で きる リリース前 ・エンドポイントやパラメ タ組み合わせ疎通テスト ・網羅性テスト

E2Eを考える前に 何をE2Eにするのか？ どんなE2Eになるのか？ どこでE2Eを実行するか？

mablはmablをmablでテストする mabl, The Guide to Testing in DevOps Pipelines

実行計画を立てる アジャイルな QAを実現するための「アジャイル QAインセプションデッキ」を作ってみた

例： リリース前フルリグレッション アジャイルな QAを実現するための「アジャイル QAインセプションデッキ」を作ってみた E2Eフルリグ レッション

例： スプリントごと結合リグレッション アジャイルな QAを実現するための「アジャイル QAインセプションデッキ」を作ってみた リグレッション E2Eフルリグ レッション

例： PRごとリグレッション アジャイルな QAを実現するための「アジャイル QAインセプションデッキ」を作ってみた スモーク リグレッション E2Eフルリグ レッション

例： スモークテストの活用、小さく、より事前に アジャイルな QAを実現するための「アジャイル QAインセプションデッキ」を作ってみた E2Eフルリグ レッション E2Eスモーク E2Eリグレッション APIリグレッション APIスモーク Visualスモーク Visual リグレッション Visualフル リグレッション

E2Eを考える前に 何をE2Eにするのか？ どんなE2Eになるのか？ どこでE2Eを実行するか？

いつもお客さまに問いかけていること ● 現状、テストや品質で一番困っていることはなんで すか？ ● mablでどうなることを期待していますか？ ● 成功のための指標は何ですか？ これらに回答できない場合はテスト自動化をすすめちゃダメ（ハート） きっとその前にやることがある（それはまた別の機会に）

何をテストすべきか？ 『リーン開発の現場』 18.5 ステップ 3:優先順位をつけて並べ替える より ● 目的ドリブン ○ スモーク ＞ リグレッション ＞ API・・・と目的で 優先順位をつける ○ リグレッションは細かく分ける ■ ハッピーパス ■ ハッピーパス＋例外系 ● データドリブン ○ ユーザがよく行う行動をもとに優先順 位をつける ● 価値ドリブン ○ 機能や画面をお金に換算して優先順 位をつける ● などなど テストケース リスク 手動テストの コスト 自動化 コスト 口座の凍結 高 5時間 0.5ポイント 振込の確認 高 3時間 1ポイント 取引履歴 中 3時間 1ポイント 検索結果の並べ替え 中 2時間 8ポイント お金の入金 高 1.5時間 1ポイント セキュリティアラート 高 1時間 13ポイント 新規ユーザー登録 低 0.5時間 3ポイント デザイン変更 低 0.5時間 20-ポイント

実行計画を立てる アジャイルな QAを実現するための「アジャイル QAインセプションデッキ」を作ってみた

テスト自動化を立ち上げる キックオフと ゴール設定。 継続的にテスト作成 （10〜20件）。 不安定なテストの安 定化とリファクタリン グ。 継続的にテスト作成 （20〜〜50）。 不安定なテストの安定化とリ ファクタリング。 テスト自動化ツールの セットアップ完了。 自動化基本トレーニング。 自動化応用トレーニン グ。 利用手順などの整備。 CI/CD統合。 まずはリリース前テス トやSTGデプロイタイミ ングで実行。 四半期レビュー 30日 60日 90日 成功に向けてテスト作成 の継続とメンテナンス。 APIテストへのカバレッジ 拡大（同時にリグレッショ ンテスト削減） はじめてのリグレッション テスト作成（まずは5〜10 件）。 通知設定。 定期実行の開始 。

Thank you very much 月次ウェビナー開催中！ 「探索的テスト」「テスト自動化」「次世代 QA組 織」といったテーマをもとに「アジャイル ・DevOps時代のテストや品質保証」を目指す ウェブナーです。 今後も、さまざまなトピックや、その道のプロ フェッショナルにご登壇いただく予定です。 https://mabl-japan.connpass.com 今すぐできる2週間の無料トライアル！ トライアルは無料。納得行くまで機能をお試しくださ い。 デモリクエストも大歓迎！ 技術トレンドや実事例をまじえたデモ MTGもお気軽 にどうぞ！ https://www.mabl.com/japan