アジャイル・DevOps時代の テストと品質保証 （完全版） / Testing and Quality Assurance in Agile and DevOps Era

この10年は多くの変化がありました。

ソフトウェア開発プロセスにおいては、アジャイル開発の普及が進み、さまざまな現場でスクラムが活用されるようになりました。

技術面では、コンテナ技術やその管理の自動化が進み、システムはどんどん複雑になりつつあります。

一方で、テストや品質保証はどのように変わってきたでしょうか？

私はアジャイルコーチとして10年活動してきましたが、 最近話題の「DX（デジタルトランスフォーメーション）」の影響か、 開発に速さがより求められるようになってきたように感じています。

そして、その影響もあってか「テストがボトルネックになりがち」や 「マニュアルテストのチームがコストセンターになってしまった」という相談をよく受けるようになりました。

このセッションでは、アジャイル・DevOps時代におけるテストと品質について、

- 現在
- 戦略と戦術
- 組織未来

のお話させていただきます。

そして特に、「テスト・品質保証」について、現状と課題や求められる要件を整理し、未来のあるべき姿を、議論したいと思います。

https://confengine.com/conferences/devopsdays-tokyo-2021/proposal/15151/devops

Transcript

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

   View Slide

2. 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/
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

6. 現在
   戦略
   戦術
   組織
   未来
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

15. 現在
    戦略
    戦術
    組織
    未来
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

19. テストピラミッドの呪いとの戦い方例
    単体(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などツールの進化でスピードは速くなり、コストは下がってきてい
    るので、テストピラミッドにしばられすぎず（それが呪い？）に理想を目指せばいいと思う。
    

    View Slide

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

    View Slide

21. 継続的デリバリ 成熟モデルの活用
    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まで整理され
    ていてわかりやすい（情報はちょっ
    と古いかも知れないけど）
    ● 自分たちがいまどういうレベルで、
    自分たちが目指すゴールがどこ
    か。その道程はどういったものか
    がよくわかる
    ● 地図があると改善は進みやすい
    

    View Slide

22. 現在
    戦略
    戦術
    組織
    未来
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

32. 現在
    戦略
    戦術
    組織
    未来
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

36. 現在
    戦略
    戦術
    組織
    未来
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide