アジャイル・DevOps時代の テストと品質保証 （完全版） なんでもできる！なんでもなれる！輝く未来を抱きしめて！ Dai Fujihara, mabl Inc. DevOpsDays Tokyo 2021

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

参考： https://daipresents.com/service/

アジャイル・DevOps時代の テストと品質保証 （完全版） なんでもできる！なんでもなれる！輝く未来を抱きしめて！ Dai Fujihara, mabl Inc. DevOpsDays Tokyo 2021

輝く未来を抱きしめてシリーズ完結編（ありがとう） 2019年 輝く未来を抱きしめて。アジャイル・ DevOps時代の品質組織づくり https://bit.ly/3fP6nVj 2021年 アジャイル・ DevOps時代のテストと品質保証 - 輝く未来を抱きしめて！技術やツールが変えてしまうこと、変えられないこと https://bit.ly/3dJ6krG 2021年 アジャイル・ DevOps時代のテスト自動化戦略 - 輝く未来を抱きしめて！ 現場から学ぶベストプラクティス https://bit.ly/3mpFUz7 技術とツール 組織 戦略

現在 戦略 戦術 組織 未来

現状をとりまいているもの アジャイル・DevOps時 代に突入 イテレーティブ＆インクリメンタ ル すばやいリリースとフィードバッ ク 正しいものを正しく作りたい アジャイル・DevOpsを 支える技術の進化 CI/CDサービスのコモディティ化 Docker, k8s の急速な広がり クラウド環境の繁栄 求められるアジャイルな テスト 従来からテストフェーズがボト ルネックになりがち アジャイルなテスティングの事 例不足・マニュアル依存 さてどうしよう？

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

データ：自動テスト vs マニュアルテスト 2020 Testing in DevOps Benchmark Survey, mabl 機能テスト、システムテストなどはまだマニュアルが主流

テストフェーズがボトルネック 要件定義 設計 リリース before 開発 テ ス ト after テスト 要件定義 設計 開発 リリース

継続的テストするしかない プログラム テスト ＆ 自動化 インフラなどあらゆる開発アクティビティ デザイン スプリントレビュー スプリントプランニング ふりかえり スプリント ここでも テスト デ リ バ リ ！ 仕様 設計 実装 テスト ここでも テスト ここでも テスト ここでも テスト たまに第三者検証 フェーズ

一言でいうと スプリントの最後に テストをしない。 そのためには？

時代遅れの考え方・プロセス・ツールではついていけない Testing Development Operations

一言でいうと テスト自動化は必然 もしくは大人数でがんばるか

現在 戦略 戦術 組織 未来

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

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

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

テストピラミッドの呪いとの戦い方例 単体(UT) 機能 API ・IT 探索的 受け入れ リグレッショ ン（松） リグレッション （竹） リグレッション （梅） パフォーマンス・ セキュリティ 狙い プログラム レベル 機能レベル APIレベル / 統合レベ ル UI/UX、特 定機能集 中型 スプリントレ ビュー 全機能網 羅 全機能正常系 のみ網羅 最低限の機能 正常系のみ網 羅 特定観点のテ スト 種類 自動化 手動（でき れば自動 化） 自動化 手動 手動 自動化 自動化 自動化 自動化 いきなりUT増やすのがしん どければ、狭い範囲のリグ レッション（ スモークテスト、 ここではリグレッション梅）か ら自動化をはじめるのが現 実的。 理想には ほど遠いけど・・・ UT API 徐々にUT/APIテストの数を増や してリグレッションの数を減らす。 粒度の細かいテストも増やしてい く。 梅 UTやAPIをコツコツ増やし、松竹梅の順で減らしていく。経 験的に松は作るのがしんどいので、竹梅だけ、もしくはリグ レッション全体の 20〜30％ぐらいの網羅性を目指せば十分 に思う。 UI UT API UT API リグレッション梅 UT API API リグレッション竹 UT リグレッション竹 リグレッション梅 リグレッション松 リグレッション梅 リグレッションもスコープを3 つぐらいに分け、粒度が荒い テストから実装ていくと失敗 しにくい。 メモ： テストピラミッドは上に行くほどスピードが遅く（ FBサイクルが長い）、上に行くほどコストが高いが、 mablなどツールの進化でスピードは速くなり、コストは下がってきてい るので、テストピラミッドにしばられすぎず（それが呪い？）に理想を目指せばいいと思う。

マニュアルテストの「ただの」自動化は失敗しやすい マニュアルを自動化しても思ったほどコスト削減でき なかったり 確認しながら進む作戦もある 完全自動は難易度が一 気に上るので目指さな い このあたりでスモー クテスト完了 このあたりでリグレッション（ハッ ピーパス）完了

継続的デリバリ 成熟モデルの活用 CD成熟モデル https://speakerdeck.com/daipresents/the-continuous-delivery-maturity-model-in-agile-and-devops 成熟度 テストのプラクティス Level 3 - 最適化: プロセス 改善に集中 本番でのロールバックがほとんどない。欠 陥が見つかってもすぐに Fixされる Level 2 - 定量的に管理: プロセ スは測定・管理されている 品質メトリクスとトレンドは追跡できている。 非機能要件も定義・測定できている Level 1 - 一貫性: アプリの開発 ライフサイクル全体に自動化が 適用されている 自動化されたUTとUATがありUATはテス ターが作成している。開発プロセスの一部 分がテストされている。 Level 0 - 繰り返し可能： プロセ スがドキュメント化・一部自動化 されている UTは自動化。ストーリーをもとにした開発 において部分的にテスト自動化できてい る。 Level -1 - 後退： プロセスは繰 り返せず管理もまだまだで後手 後手 開発後のマニュアルテスト。 DEV/STG/PROのように環境分離。 ● Level -1 からLevel 3まで整理され ていてわかりやすい（情報はちょっ と古いかも知れないけど） ● 自分たちがいまどういうレベルで、 自分たちが目指すゴールがどこ か。その道程はどういったものか がよくわかる ● 地図があると改善は進みやすい

現在 戦略 戦術 組織 未来

インテリジェントなテスト自動化 ● クラウド/SaaSで初期コスト低 ● 簡単操作でテストの作成や修正可能 ● AIでテストを自動修復、自動画面分析 ● クロスブラウザ対応、並列/同時実行、など クラウドならではの恩恵多数 ● CI/CDへの組み込みも簡単

これまでやってきたこと テストケース作成、自動テストコード実装、自動テストのリファクタリング、テスト実行環 境構築、クロスブラウザ環境構築、並列・直列実行サポート、テスト結果データ基盤構 築、テスト結果レポート作成、定期実行基盤構築（CI）、CI/CD連携実装、通知機能実 装、画面崩れ検知、JSエラー検知、ネットワークエラー検知、APIテスト実行環境構築、 モバイルアプリテスト環境構築・・・

これまでやってきたこと テストケース作成、自動テストコード実装、自動テストのリファクタリング、テスト実行環 境構築、クロスブラウザ環境構築、並列・直列実行サポート、テスト結果データ基盤構 築、テスト結果レポート作成、定期実行基盤構築（CI）、CI/CD連携実装、通知機能実 装、画面崩れ検知、JSエラー検知、ネットワークエラー検知、APIテスト実行環境構築、 モバイルアプリテスト環境構築・・・

テスト自動化設計 小さく、大量に、並列で ● 機械は小さいものを大量に並列処理する のが得意 ● ケースは5分以内。ステップ数は 25~50 以内 ● 共通部品を作る。2回やるなら部品にす る ● 並列実行できるケースを作る（テストの独 立性） 昔 今 時間 並列数

ベストプラクティスのハンズオン 観点は一つ、小さく作る（1シナリオ5分以内）、遷移や表示ごとにア サート、部品を作る、一意な文字を入力に使う、大切なものだけアサー ト、スリープではなく〜まで待つ、分岐やループやXpathやJSは最低 限、コメントを書こう、ラベルで管理、CI/CDに組み込む・・・などなど mablでE2Eテストを自動化するためのベストプラクティス 2020年版 https://daipresents.com/2020/test-automation-practice/

ベストプラクティス例： コメントとアノテーション テストはチーム作業 ● 「どうやってナレッジを共有する か？」 ● チームや組織の人数増加にともな い必ず直面する課題 ● テストケースに残せばそれが仕様 になり、ドキュメントになる

ベストプラクティス例： 部品の共通化 再利用！再利用！再利用！ ● 2回やることは部品（mablだと Flow）にする ● Flowの引数を活用して汎用性を高 める ● Flowをたくさん作ってつなげる ● 部品を磨きつづける はじめは、大きく「処理」 「処理結果の確認」「遷 移」にわけて部品を作る のがおすすめ。

テストしやすいシステムへのリファクタリング テスタブルであること ● テスト用APIの整備（ユーザ作成、特定処 理のデータ準備など） ● テストしにくい（操作しにくい）仕様の改善 提案（オンマウス、hoverなど） ● テスト範囲の分割（Mockやスタブの活 用） ● 原因特定しやすいログ設計

自動テストケース管理 Excel / Spreadsheet最強説 ● 観点レベルで一覧化 ○ 手動・自動まとめて管理 ○ マニュアルケースは別Excelに作ってリン クする ○ 自動テストもmablにリンクだけ ○ 現時点でベストプラクティスだと思う ● 機能別、優先度別、観点別でテストにラベリング

現在 戦略 戦術 組織 未来

Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む https://lean-trenches.com/scaling-agile-at-spotify-ja/ 組織も変わっていく QA iOS （現在から未来？）アジャイル型組織 チームでプロダクトへ Android Frontend Backend BI 上にマネージャがのっかれば 従来型のピラミッド型組織に近い どこに向かうチーム？ QA iOS Android Frontend Backend BI ←職能横断的チーム。 チームごとの成熟度を 高く育てられる。チーム 間のコミュニケーション 問題をギルドや支部制 度で弱めている 職能ごと縦割り組織型 → 管理効率が高いが、プロ ジェクト制度だとチームの成 熟度が高まらない。サイロ 化、組織間コミュニケーショ ンの課題がなかなか解決し ない

自動化はテスター撲滅の夢を見るか？ JaSST’19 「テストをする」という仕事が自動化に よって「置き換わらない」と答えた人は 0人 ただし「なくなる」わけではない。 テストの未来、品質の未来 ～自動化はテスター撲滅の夢を見るか？～ https://bit.ly/2Rh0UMN

開発チームに求められるスキルセット アジャイル開発・スクラムの 基礎知識 プロセス全体の品質に関わる QAエ ンジニアはスクラムマスターとの相 性がよい。 基本的なコンピュータ・サイエンス 知識があれば最高。 まずは「PRを読める」だけで十分。 テスト自動化も含めたテスト 業務 テスト自動化戦略策定、テスト自動 化戦術の決定、テスト自動・・・・特 にCI/CD技術 「開発だけ」「テストだけ」「テスト自 動化だけ」ではもう足りない。 新しいキャリアへのチャンス。 境界を超えられるスキル 我々が欲しい人材はご意見番では なくて専門家。 設計フェーズ、開発フェーズ、テス トフェーズといった境界を超えて、 その先で価値提供できできる人。 継続的改善できる人。

現在 戦略 戦術 組織 未来

来たるべき未来？ 技術は進化をし続ける AI/MLが常識を変えていく。 ● ペルソナを使った探索的テ スト自動化 ● 自然言語でテストケース作 成 ● ユーザ操作を学習してテスト 作成 などなどすでに実用段階 テストの民主化が進む ● プロダクトチームに境界 は必要ない ● テストやテスト以外もど んどん民主化が進む ● 品質が人やフェーズで はなく活動になる スピードへの自動化（技術）投 資が増える ● テスト自動化「だけ」、単純作 業をツールで楽する「だけ」 の価値や成果は小さい ● 人や時間のコスト削減は品 質を上げる活動として弱い ● デリバリスピードへの投資 に いきつく

テストデータ分析による品質情報の民主化 問題を事前に検知・予測する仕組みも簡単に作れる

民主化例： CI/CDによるプロセスやテストの民主化 DevOpsパイプラインのテスト：プルリクエストフェーズのテスト https://bit.ly/2RkqRes テスト！ テスト！ テスト！ テスト！ テスト！ テスト！ テスト！ テスト！ テスト！ テスト！ テスト！ テスト！ テスト！ テスト！ テスト！ テスト！

アジャイル・DevOps時代の テストと品質保証 （完全版） なんでもできる！なんでもなれる！輝く未来を抱きしめて！ Dai Fujihara, mabl Inc. DevOpsDays Tokyo 2021

このセッションのまとめ ● 現在： アジャイル＆DevOps時代 ● 戦略： ゴールを設定して自動化で実現する ● 戦術： 技術やツールの活用 ● 組織： プロダクト（価値）思考型のチーム ● 未来： さらなる民主化

バグというもぐらを 丁寧に時間をかけて 手でたたき続けるか？

価値を提供し続ける 品質組織づくりをするか？

プロセスやツールよりも 個人と対話を アジャイルソフトウェア開発宣言 https://agilemanifesto.org/iso/ja/manifesto.html

さぁ、境界を越えよう なんでもできる！なんでもなれる！ 輝く未来を抱きしめて！

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