[Developers Summit 2023] ソフトウェアテスト新時代の幕開け: 機械学習とデータサイエンスで実現するテスト運用の高度化

Developers Summit 2023 の公募セッションで発表した資料です。https://event.shoeisha.jp/devsumi/20230209/session/4142/

Transcript

1. ソフトウェアテスト新時代の幕開け
   機械学習とデータサイエンスで実現するテスト運用の高度化
   2023.02.09
   渡辺 喬之
   Developers Summit 2023
   

   View Slide

2. 発表者のプロフィール
   ▶ 渡辺 喬之 (Takayuki Watanabe)
   ▶ ソフトウェアエンジニア (Launchable, Inc.)
   ▶ SNS
   ▶ ブログ: https://blog.takanabe.tokyo
   ▶ GitHub: takanabe
   ▶ Twitter: @takanabe_w
   ▶ 専門分野
   ▶ Developer Productivity
   ▶ Site Reliability 2
   

   View Slide

3. 3
   本プレゼンは個人の意見・経験に基づく見解が多分に
   含まれています(その方が面白いと思うので)。
   発表者の所属組織の考えを丸ごと反映しているわけで
   はありません。
   Caution!!
   

   View Slide

4. 今日伝えたいこと
   近い将来ソフトウェア開発におけるテストの運用に機械学習とデータサイエンスを取
   り入れたアプローチが一般に広く普及するかもしれないということ
   4
   

   View Slide

5. 今日の話の流れ
   5
   ▶ ソフトウェア開発におけるテストの位置付け
   ▶ テストを取り巻く環境の変化
   ▶ テストが抱える新たな課題
   ▶ 機械学習とデータサイエンスを用いた次世代のテスト運用
   

   View Slide

6. ソフトウェア開発における
   テストの位置付け
   6
   

   View Slide

7. ソフトウェア開発におけるテストの位置付け
   7
   E2E Test
   Integration
   Test
   Unit Test
   (referenced from Wikipedia)
   ▶ ウォーターフォール(V字モデル)、アジャイル開発どちらもテストは必要
   Costが高く開発者へのフィードバックが遅い
   Costが低く開発者へのフィードバックが早い
   

   View Slide

8. 8
   ▶ テストを書くことで長期的な開発速度と品質にプラスの効果がある
   ▶ テストを書くことでコード (あるいは機能)に対して品質を保証できる
   ▶ テストに対象のコードの使い方が書かれるため 設計書として使える
   ▶ テストがあれば積極的な機能追加やリファクタリングによる 改善ができる
   ▶ テストを書くことで開発中のコードに対して早いフィードバックを得られる
   ▶ 特別なケースを除けばテストを書かない理由はもはやない
   ▶ 近代のソフトウェア開発ではテストを書くのが標準
   ▶ 書けない場合はその理由が明らかになっていることが重要
   なぜテストを書くのか？
   

   View Slide

9. テストを取り巻く環境の変化
   9
   

   View Slide

10. テストを取り巻く環境の変化
    10
    ▶ テストの設計や実装に関するノウハウの普及
    ▶ テスト実行環境の進化
    ▶ CI/CDを通じたテスト自動化の重要性の認知
    ▶ テスト生成技術の進化
    ▶ テスト実装・自動化の容易性と実行数の相関
    

    View Slide

11. テストの設計や実装に関するノウハウの普及
    11
    (引用: “ソフトウェアテストの歴史と近年の動向 ”, https://www.slideshare.net/Bugler/ss-139696080)
    

    View Slide

12. テスト実行環境の進化
    12
    ▶ CI/CDパイプラインを実現する多種多様のソフトウェアが台頭した
    ▶ On-premise: Jenkins, Drone CI
    ▶ Managed service: CircleCI, GitHub Actions, Gitlab CI, AWS CodePipeline
    ▶ コンテナの普及により再現性の高いテスト環境が構築できるようになった
    ▶ Container Runtime: Docker, containerd
    ▶ Repository: Docker Hub, Amazon ECR, Google Container Registry
    ▶ Orchestration: Kubernetes, Mesos, Rancher, Amazon ECS, Google Cloud Run
    

    View Slide

13. CI/CDを通じたテスト自動化の重要性の認知
    13
    ▶ 構築コストの低下とその重要性から近年のソフトウェア開発では
    CI/CDパイプラインは開発の初めから導入されることも多い
    

    View Slide

14. 14
    CI/CDを通じたテスト自動化の重要性の認知
    ▶ 様々な著書でCI/CDパイプラインによる再現可能なプロセスの自動化と
    ソフトウェア開発のパフォーマンスの因果関係が説かれている
    (引用: “Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations”, pp. 77-78,2018)
    

    View Slide

15. 15
    CI/CDを通じたテスト自動化の重要性の認知
    ▶ インダストリーレポートによるとサイズによらずDevOps、CI/CD を
    適用している企業が増えていることがわかる
    

    View Slide

16. テスト生成技術の進化
    16
    ▶ ローコード・ノーコードによるE2Eテスト生成技術の進化
    ▶ On-premise: Selenium, Cypress
    ▶ SaaS: mabl, MagicPod, Autify
    ▶ New!! 機械学習によるテストコード生成技術の進化
    ▶ Pair-programming: GitHub Copilot, AWS CodeWhisperer
    ▶ General purpose: ChatGPT
    

    View Slide

17. テスト実装・自動化の容易性と実行数の相関
    17
    テストの実装
    ノウハウの普及
    実装・自動化が難しい 実装・自動化が簡単
    Today
    テスト生成技術の進化
    テスト実行環境の進化 テスト自動化の
    重要性の認知
    Future
    Past
    の大きさ = 自動テスト実行数の量
    

    View Slide

18. テスト自動化は良いことしかない・・・？
    18
    ▶ CI/CDパイプラインでテスト実行数が増えると別の課題が見えてくる
    

    View Slide

19. テスト自動化が抱える新たな課題
    19
    

    View Slide

20. テスト自動化が抱える新たな課題
    20
    ▶ 時代の潮流としてテスト自動化が進みテストの数は今後ますます増えていく
    ▶ 環境や技術の進化がそれを後押しする
    ▶ 現在テストがないソフトウェアにもテストは追加されていく
    ▶ コードレビューでテストを追加することに反対する人は少ない
    

    View Slide

21. テスト自動化が抱える新たな課題
    21
    ▶ 以下の問題がソフトウェア開発で現れる
    ▶ テスト実行時間の増加
    ▶ 時折失敗する不安定なテストの出現
    ▶ テストのメンテナンスコストが増加
    

    View Slide

22. テスト実行時間の増加の弊害
    22
    ▶ CI/CDパイプラインのリードタイムとMTTRが増加する
    ▶ 例) コードを少し変更しただけなのに全てのテストが通るまで待つ必要がある
    ▶ CI/CDパイプラインがタイムアウトで失敗するようになる
    ▶ テスト実行のための計算コスト(=サーバ代)が増加する
    ▶ テスト実行時間を減らすためにテスト並列化が必要になる
    ▶ 全ての開発者が並列処理を熟知しているわけではないため不安定になる要因になりうる
    

    View Slide

23. 不安定なテストの弊害
    23
    ▶ 一部の不安定なテストが原因でテスト全体の信頼度が低下する
    ▶ 例)新しく開発に参画したメンバーはどのテストが Flakyか知らないため不安になる
    ▶ コード変更がない時に成功、失敗の両方の結果を返すテストを Flakyなテストと言います
    ▶ CI/CDパイプラインのリードタイムとMTTRが増加する
    ▶ 例)自分が書いたコードと全く関係ないテストが Flakyでテストのリトライが必要
    ▶ 理想はFlakyテストがないことだが、現実の開発でFlakyテストを根絶やすのは
    困難
    

    View Slide

24. メンテナンスコスト増加の弊害
    24
    ▶ テストは足すのは簡単だが、メンテナンスは大変という特徴がある
    ▶ 開発者の精神的なストレスになる
    ▶ 例)既に退職した人が書いたよくわからないテストが大量にあるが断捨離の判断が出来ない
    ▶ 例)冗長なテストがレポジトリの至る所にあるが緊急度やリファクタリングのインパクトを他者に説
    明するのが難しい
    ▶ 例)誰にも評価されない孤高の職人になりうる = キャリアの停滞に繋がる
    

    View Slide

25. 25
    Code
    Code Review
    Unit Tests
    Nightly Smoke Tests
    UI Testing
    Integration Tests
    Pre-merge
    Post-merge
    Push to production
    テストのCI/CDのボトルネック化
    ▶ 自動化されたテストがCI/CDパイプラインのボトルネック
    になる
    

    View Slide

26. 26
    Test Time Test Cadence
    Impact of failures found
    at each stage
    Impact of failures on
    developers
    24+ hours Run weekly
    Release impacted. Hot fix
    or delay release.
    Code not top of mind.
    Heavy context switch
    6-24 hours Run nightly
    Requires triage to pin
    source of issues. Likely
    delays other features Fix flows into multiple days
    at the cost of other work for
    the release
    1-6 hours Run continuously
    Main branch is red. Impact
    others on the team.
    1-30 minutes Run pre-merge
    Same day fix. Impacts dev
    who wrote the code.
    Need “coffee-break” level
    context switch
    Quick iterative
    development. No context
    switch.
    Flag issues
    earlier
    

    View Slide

27. 27
    ▶ テストを書くことで長期的な開発速度と品質にプラスの効果がある(?)
    ▶ テストを書くことでコード (あるいは機能)に対して品質を保証できる
    ▶ 不安定なテストがあるため 信頼できない
    ▶ テストに対象のコードの使い方が書かれるため 設計書として使える
    ▶ テストがあれば積極的な機能追加やリファクタリングによる 改善ができる
    ▶ テストの待ち時間が増え、不安定なテストがあるので 変更が億劫になる
    ▶ テストを書くことで開発中のコードに対して早いフィードバックを得られる
    ▶ テストの待ち時間が増えるので フィードバックが遅い ,あるいは無視する
    (再考)なぜテストを書くのか？
    

    View Slide

28. テストは書いて終わりではない
    28
    ▶ テスト自動化で本来やりたかったことが達成できなくなってしまう
    ▶ 他のコードと一緒で運用していく必要がある
    ▶ 開発者の努力の積算値がテスト運用効率に現れる
    

    View Slide

29. 次世代のテスト運用
    29
    ▶ 努力するにしても効率的な打ち手を選択したい
    ▶ 理想的なテストの運用方法(QAOps)を模索する必要がある
    ▶ 機械学習による次世代のテスト運用
    ▶ データサイエンスによる次世代のテスト運用
    

    View Slide

30. 機械学習による次世代のテスト運用
    30
    

    View Slide

31. 機械学習を使ったテスト運用の事例
    31
    (引用: 本資料末尾の参考 /機械学習・データサイエンスを使ったテスト運用戦略関連を参照 )
    

    View Slide

32. 32
    32
    何をしているのか？
    一般的なソフトウェア開発で使えるのか？
    機械学習を使ったテスト運用の事例
    (引用: 本資料末尾の参考 /機械学習・データサイエンスを使ったテスト運用戦略関連を参照 )
    

    View Slide

33. 33
    ▶ テストの数が多すぎて変更に関連する全てのテストを実行するのは不可能
    ▶ 実行時間的制約
    ▶ コンピューティングリソース的制約
    ▶ 開発者へのフィードバック速度の期待値
    ▶ 機械学習を用いて実行するテストの取捨選択をしている
    ▶ 全テスト実行で発見できるバグを見落とすリスクを受け入れる
    大規模なソフトウェア開発では既知の課題
    

    View Slide

34. Predictive Test Selection (PTS)とは
    34
    ▶ Meta社の提案手法ではモデルの学習に以下の特徴量を利用
    ▶ ファイルの変更履歴
    ▶ ファイル変更数
    ▶ 変更により実行されるテスト数
    ▶ ファイルの拡張子
    ▶ ファイルの編集者数
    ▶ テストの失敗率の履歴
    ▶ etc…
    (引用: https://engineering.fb.com/2018/11/21/developer-tools/predictive-test-selection/)
    

    View Slide

35. Predictive Test Selection (PTS)とは
    35
    ▶ モデルはテストが失敗する確率を予測する
    ▶ 失敗しないであろうテストはあえて実行しないという選択が可能
    ▶ リスク許容度に応じてテスト実行数を減らすことが可能
    (引用: https://engineering.fb.com/2018/11/21/developer-tools/predictive-test-selection/)
    

    View Slide

36. 36
    ▶ テストとメタデータを入力として機械学習でテストの結果を予測する
    ▶ 失敗する確率が低い(実行する価値が低い)テストを実行対象から除くことでテ
    ストの総数を減らす
    ▶ CI/CDに組み込むことで人の手を介さずテストの取捨選択を行う
    Predictive Test Selection (PTS)とは
    Test A
    Test B
    Test C
    PTS
    実行したいテスト郡
    （+メタデータ)
    PTSで選択されたテスト郡
    Test A
    Test B
    入力 出力
    (推論結果)
    

    View Slide

37. PTS導入のケーススタディ
    37
    ▶ ケース1: テスト数は大規模ではなくコミットごとに全てのテストの自動実行が可
    能な場合
    ▶ CI/CDパイプラインを通じて Pull Requestとmain ブランチで全てのテストを自動実行
    ▶ PTS導入後の変化: ???
    ▶ ケース2: テスト数が大規模なのでコミットごとに全てのテストを実行したくない
    場合
    ▶ CI/CDパイプラインを通じて mainブランチでのみ全てのテストを自動実行
    ▶ PTS導入後の変化: ???
    

    View Slide

38. 機能開発の単位
    Te
    (p
    リリースまでのリードタイムに差が出る
    開発者へのフィードバック速度に差が出る
    ケース1でのPTSの導入例
    38
    Test A
    (fail)
    Test B
    (pass)
    Test C
    (pass)
    Test A
    (pass)
    Test B
    (pass)
    Test C
    (pass)
    Test A
    (fail)
    Test A
    (pass)
    Test B
    (pass)
    Test C
    (pass)
    Test A
    (pass)
    Test A
    (pass)
    Test B
    (pass)
    Test C
    (pass)
    Test B
    (pass)
    Test A
    (pass)
    Test B
    (pass)
    Test C
    (pass)
    Test A
    (pass)
    Test B
    (pass)
    Test C
    (pass)
    git push git push git push
    git push git push git merge git merge
    git merge
    git push
    time
    PRブランチで実行するテスト main ブランチで実行するテスト
    PullReqでPTSなし
    PullReqでPTSあり
    Test C
    (pass)
    git push
    

    View Slide

39. 機能開発の単位
    リリースまでのリードタイムに差が出る
    開発者へのフィードバック速度に差が出る
    ケース2でのPTSの導入例
    39
    Test A
    (fail)
    Test A
    (pass)
    Test A
    (pass)
    Test B
    (pass)
    Test C
    (pass)
    Test B
    (pass)
    Test A
    (pass)
    Test B
    (pass)
    Test C
    (pass)
    git push git push git merge git merge
    git push
    time
    PRブランチで実行するテスト main ブランチで実行するテスト
    Test C
    (pass)
    git push
    PullReqでPTSあり(Shift Left)
    Test A
    (fail)
    Test B
    (pass)
    Test C
    (pass)
    Test A
    (pass)
    Test B
    (pass)
    Test C
    (pass)
    git push git merge git merge
    PullReqでPTSなし
    git push
    Test A
    (pass)
    Test C
    (pass)
    git merge
    Test B
    (pass)
    git push
    

    View Slide

40. PTS導入のケーススタディ
    40
    ▶ ケース1: チームのサイズもテスト数も大規模ではなく全てのテストの自動実行
    は可能
    ▶ CI/CDパイプラインを通じて Pull Requestとmain ブランチで全てのテストを自動実行
    ▶ PTS導入後の変化: リリース前の全テスト実行という セーフティーネットを維持しつつ、開
    発時に早いフィードバックとリリースのリードタイムの削減 が期待できる
    ▶ ケース2: チームのサイズもテスト数もそれなりに大規模なのでコミットごとに全
    てのテストを回したくない
    ▶ CI/CDパイプラインを通じて mainブランチでのみ全てのテストを自動実行
    ▶ PTS導入後の変化: Shift Leftにより開発時に早いフィードバック が得られ、結果的に リ
    リースのリードタイムの削減 が期待できる
    

    View Slide

41. PTSの汎用性に関する議論
    41
    ▶ PTSはBig Techのようにテストが多すぎて全て実行することが出来ないという
    課題を解決するために生まれた
    ▶ 多くのソフトウェア開発においてそこまで大規模なテストは存在しない
    

    View Slide

42. PTSの汎用性に関する議論
    42
    ▶ 一方でテストを自動化している場合コード変更時はテストが通るまでリリース出
    来ない、テスト実行時間は少ない方がいいという事実は不変
    ▶ 規模が小さいソフトウェアでもPTSの恩恵はある
    ▶ 例) サーバコストの削減 : テスト実行時間 x 1時間あたりのCI利用料金
    ▶ 例) コンテキストスイッチ時間の短縮 : テスト実行時間分現在と違うタスクをする
    ▶ リスクを受け入れて価値の高いテストだけを実行するテスト運用戦略は新しい
    考え方だが汎用性は高いため一般化する可能性はある
    

    View Slide

43. PTSを小さなチームで使った例
    43
    ▶ Launchableの全エンジニア(8人)の１ヶ月あたりのテスト実行時間
    ▶ テスト実行時間が約 1/2になっている(Pull Requestのテスト待ち時間が 10->5分になる)
    ▶ 2022年12月年の実績をベースにすると年間 1,296時間のテスト実行時間が削減可能
    PTSなし PTSあり 削減時間
    

    View Slide

44. データサイエンスによる
    次世代のテスト運用
    44
    

    View Slide

45. Developer Productivity(DP)のメトリクストレンド
    45
    ▶ DevOpsの4つのメトリクス
    ▶ デプロイ頻度
    ▶ 変更のリードタイム
    ▶ 変更時障害率
    ▶ サービス復元時間
    ▶ 著書Accelerateで提唱
    ▶ GoogleのDevOps Research and Assessmentチームが引き続き研究を続
    けている。DORAメトリクスやFour Keysと呼ばれている
    

    View Slide

46. 46
    ▶ 他にもSPACEと呼ばれる生産性測定の
    フレームワークが提案されている
    ▶ 開発者個人やチームのパフォーマンスの計
    測と可視化に大きな需要がある
    Developer Productivity(DP)のメトリクストレンド
    

    View Slide

47. Site Reliablity Engineeringのメトリクストレンド
    47
    ▶ MTTRやMTTDなどインシデントマネジメントのパフォーマンスを測定す
    るメトリクスの再認知
    (引用:https://speakerdeck.com/takanabe/sre-next-2022-sensible-incident-management-for-software-startups?slide=49)
    

    View Slide

48. 48
    ▶ SLO, SLI, SLA, Error Budget, Toil 等の概念の普及
    Site Reliablity Engineeringのメトリクストレンド
    (引用: https://sre.google/sre-book)
    

    View Slide

49. 49
    ▶ 現場レベルでのSREのプラクティスの活用
    Site Reliablity Engineeringのメトリクストレンド
    (引用: https://speakerdeck.com/takanabe/sre-next-2020-c6-designing-fault-tolerant-microservices-with-sre-and-circuit-breaker-centric-architecture,
    https://speakerdeck.com/takanabe/challenges-for-global-service-from-a-perspective-of-sre)
    

    View Slide

50. CI/CDから見たDP/SREメトリクスのスコープ
    50
    SREのメトリクスのスコープ
    DPのメトリクスのスコープ
    

    View Slide

51. 51
    SREのメトリクスのスコープ
    DPのメトリクスのスコープ
    CI/CDから見たDP/SREメトリクスのスコープ
    

    View Slide

52. テストのプロセス改善に使えるのか
    52
    ▶ DPのメトリクスはCI/CDパイプライン全体のパフォーマンスに着目
    ▶ なんとなくの傾向はわかるがそれ自体を見て次のアクションを決めることは出来ない
    ▶ テスト実行時間や安定性が悪化すれば、 DPのメトリクスも悪化する関係にある
    ▶ SREのメトリクスのサービス運用特化で利用者は次のアクション決めやすい
    ▶ 一方でテストのプロセス改善で利用できるものではない
    

    View Slide

53. テスト(QA)のプロセス改善に使えるのか
    53
    ▶ QA特化の決定的なメトリクスはない (もしあったらこっそり教えて下さい)
    QAのメトリクスのスコープ
    

    View Slide

54. QAのメトリクスの考察
    54
    ▶ Symptomaticメトリクス
    ▶ 何かが起きている事を検知する
    ▶ Causalメトリクス
    ▶ なぜ起きているかを検知する
    ▶ QAのメトリクスとしては集計方法を変えるだけ同じものが使える
    ▶ Symptomaticメトリクスは全てのテストの集計値
    ▶ CaucalメトリクスはTest caseごとの集計値
    

    View Slide

55. データサイエンスによるQAメトリクスの算出
    55
    ▶ データサイエンスのアプローチを利用してQAのメトリクスを算出する
    ▶ ベイズ推定
    ▶ 統計
    ▶ クラスタ分析
    ▶ etc…
    ▶ 算出したメトリクスを可視化し運用に利用する
    

    View Slide

56. QAのメトリクスの考察
    56
    ▶ 使えそうなQAのメトリクス
    ▶ Flakiness score
    ▶ Test durations
    ▶ Failure rate
    ▶ Auto-healing failure count
    ▶ Never failing test ratio
    

    View Slide

57. QAのメトリクス: Flakiness score
    ▶ そのテストがflakyな確率をスコアで表現する
    ▶ テストがどの程度信頼できるかを表現するメトリクス
    ▶ 単純な２値分類(flaky or not flaky)ではなく0 ~ 1 のスコアで表現する
    ▶ 対象のテスト結果の確率がわかれば算出可能
    ▶ それらの確率がわかっていたら苦労しない
    ▶ ただし、そのテストの過去の実行結果はわかる
    57
    

    View Slide

58. QAのメトリクス: Flakiness score
    58
    ▶ 過去のテスト結果に対して最尤推定やベイズ推定を使うことで算出可能
    (引用: https://engineering.fb.com/2020/12/10/developer-tools/probabilistic-flakiness/)
    Count
    Count
    過去のテスト結果
    過去のテスト結果
    Pass Fail
    Pass Fail
    求めたい確率の分布
    

    View Slide

59. QAのメトリクスの活用法の考察
    59
    ▶ SymptomaticメトリクスとCausalメトリクスをどのように使うか？
    ▶ Symptomaticメトリクスに閾値を設定して、閾値を超えたらチケットを作成して改善に取り組む
    ▶ e.g. Pre-mergeのaverage Durationが1時間を超えたので原因を調査するためのチ
    ケットを発行する
    ▶ CausalメトリクスはSymptomaticメトリクスと合わせて改善するべきテストの特定に使う
    ▶ e.g. Pre-mergeのaverage Durationが長くなった原因を調査する
    ▶ Symptomatic メトリクス -> Causalメトリクスの順でドリルダウンする
    ▶ ダッシューボードなどで可視化すると調査しやすい
    

    View Slide

60. Symptomaticメトリクス(Overview)
    60
    Duration Failure rate Flakiness score
    Post-Merge Test Metrics (average)
    Pass Fail Flaky Infra outage
    Durationの時系列データ
    Failure rateの時系列データ
    Flakiness scoreの時系列データ
    Duration Failure rate Flakiness score
    Pre-Merge Test Metrics (average)
    Test result history
    

    View Slide

61. Symptomaticメトリクス(Test run ID and case )
    Test case
    Test run ID
    Test case 1
    Test case 2
    Test case 3
    Test case 4
    Test case 5
    Test case 6
    Test case 7
    Test case 8
    Test case 9
    Test case 10
    Test case 11
    Test case 12
    ID1
    ID2
    ID3
    ID4
    ID5
    ID95
    ID96
    ID97
    ID98
    ID99
    … …
    Pass Fail Flaky Infra outage
    61
    

    View Slide

62. Causalメトリクス(ランキングテーブル)
    Test case 1
    Test case 2
    Test case 3
    Test case 4
    Test case 5
    Test case 1
    Test case 2
    Test case 3
    Test case 4
    Test case 5
    Flakiness score のランキングテーブル Duration のランキングテーブル
    ▶ Test run ID or 指定期間でランキングテーブルを表示
    62
    

    View Slide

63. Causalメトリクスの(テストケース詳細)
    How to improve? Flakiness score が高いのでテストを修正するか、リトライの仕組みを入れてください
    Test case 1
    Pass Fail Flaky Infra outage
    Durationの時系列データ
    Failure rateの時系列データ
    Flakiness scoreの時系列データ
    Test result history
    63
    

    View Slide

64. まとめ
    64
    

    View Slide

65. まとめ
    65
    ▶ ソフトウェア開発においてテスト自動化は重要な役割を担うが課題はある
    ▶ 自動実行されるテスト数は今後も増えていく
    ▶ テスト実行数の増加に伴い実行時間や安定性にまつわる課題が顕著になる
    ▶ 機械学習とデータサイエンスを利用したテスト運用の高度化が一般的なソフトウェ
    ア開発のプロセスに組み込まれる未来は近い
    ▶ Predictive Test Selection によるテストの選択
    ▶ QAのメトリクスをデータサイエンスを用いて算出しテストの運用に利用
    

    View Slide

66. プレゼンに関するご質問は以下で回答します
    ● Twitter: @takanabe_w
    ● E-mail: twatanabe@launchableinc.com
    66
    

    View Slide

67. 参考
    67
    ● “martinFowler.com: The Practical Test Pyramid”,
    https://martinfowler.com/articles/practical-test-pyramid.html
    ● “Google Testing Blog: Just Say No to More End-to-End Tests”,
    https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html
    ● “Continuous Testing in DevOps”,
    https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
    ● “V-Model (software development)”,
    https://en.wikipedia.org/wiki/V-Model_%28software_development%29
    ● “ウォーターフォール・
    V字開発の教科書的情報
    ”,
    https://zenn.dev/karaage0703/articles/3435f5da0d1739
    ● “ソフトウェアテストの歴史と近年の動向
    ”,
    https://www.slideshare.net/Bugler/ss-139696080
    テスト・QA関連
    

    View Slide

68. 参考
    68
    ● “Software Engineering at Google”, Titus Winters, Tom Manshreck, Hyrum Wright, Chapter 11 - 14, 2020
    ● “LINE Engineering: Shift-leftとShift-rightアプローチによってQAがより良い品質を確保する方
    法”,https://engineering.linecorp.com/ja/blog/quality-advocator-shift-left-shift-right
    ● “freee Developers Hub: 自動テスト速度改善 - 自動テストが品質のボトルネックとならないために
    ”,
    https://developers.freee.co.jp/entry/improving-ci-testing-for-next-quality
    ● “freee Developers Hub: freeeの自動テストの全体構成
    ”,
    https://developers.freee.co.jp/entry/automated-test-structure-2022
    ● “mercari engineering:不具合データの可視化と分析
    ”,
    https://engineering.mercari.com/blog/entry/20211222-6d545e2c99/
    ● “mercari engineering: なぜメルペイQAはDevOpsに取り組むのか？”,
    https://engineering.mercari.com/blog/entry/20201217-94588a41b9/
    ● “Tests Under the Magnifying Lens”,
    https://developers.soundcloud.com/blog/tests-under-the-magnifying-lens
    テスト・QA(エンジニア視点)関連
    

    View Slide

69. 参考
    69
    ● “Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations”,
    ,Nicole Forsgren, Jez Humble, Gene Kim,2018.
    ● “The SPACE of Developer Productivity”,
    https://queue.acm.org/detail.cfm?id=3454124
    ● "Introducing Developer Velocity Lab to improve developers’ work and well-being”,
    https://www.youtube.com/watch?v=t7SXM7njKXw
    ● “エリート DevOps チームであることを Four Keys プロジェクトで確認する
    ”,
    https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
    ● “2022 年の Accelerate State of DevOps Report を発表: セキュリティに焦
    点”,https://cloud.google.com/blog/ja/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now-out
    Developer Productivity関連
    

    View Slide

70. 参考
    70
    ● “Site Reliability Engineering: How Google Runs Production Systems”, https://sre.google/sre-book/table-of-contents/
    ● “SRE NEXT 2020 [C6] Designing fault-tolerant microservices with SRE and circuit breaker centric architecture”,
    https://speakerdeck.com/takanabe/sre-next-2020-c6-designing-fault-tolerant-microservices-with-sre-and-circuit-breaker-c
    entric-architecture?slide=105
    ● “Challenges for Global Service from a Perspective of SRE”,
    https://speakerdeck.com/takanabe/challenges-for-global-service-from-a-perspective-of-sre?slide=109
    Site Reliability Engineering関連
    

    View Slide

71. 参考
    71
    ● "Predictive test selection: A more efficient way to ensure reliability of code changes”,
    https://engineering.fb.com/2018/11/21/developer-tools/predictive-test-selection/
    ● “Taming Google-Scale Continuous Testing”, Atif Memon Bao Nguyen Eric Nickell John Micco Sanjeev Dhanda Rob Siemborski
    Zebao Gao, Proceedings of the 39th International Conference on Software Engineering, 2017.
    ● “Predictive Test Selection”, Mateusz Machalica, Alex Samylkin, Meredith Porth, Satish Chandra, International Conference on
    Software Engineering, 2019.
    ● “Assessing Transition-based Test Selection Algorithms at Google”, Claire Leong Abhayendra Singh John Micco Mike Papadakis
    Yves le traon, International Conference on Software Engineering, 2019.
    ● “A Survey on Regression Test-Case Prioritization”, Yiling Lou, Junjie Chen, Lingming Zhang, Dan Hao, Advances in Computers,
    Volume 113, 2019.
    機械学習・データサイエンスを使ったテスト運用戦略関連
    

    View Slide

72. 参考
    72
    ● “GitHub Blog: Reducing flaky builds by 18x”,
    https://github.blog/2020-12-16-reducing-flaky-builds-by-18x/
    ● "The state of the art in tackling Flaky Tests”,
    https://www.youtube.com/watch?v=PjYIcCnkLhg
    ● “Spotify R&D | Engineering Blog :Test Flakiness – Methods for identifying and dealing with flaky tests”,
    https://engineering.atspotify.com/2019/11/test-flakiness-methods-for-identifying-and-dealing-with-flaky-tests/
    ● “Engineering at Meta: How do you test your tests?”, https://engineering.fb.com/2020/12/10/developer-tools/probabilistic-flakiness/
    ● “Google Testing Blog: Flaky Tests at Google and How We Mitigate Them”,
    https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html
    ● “Dropbox: Athena: Our automated build health management system”,
    https://dropbox.tech/infrastructure/athena-our-automated-build-health-management-system
    ● “Cybozu Inside Out: Flaky Testとの戦い”,
    https://blog.cybozu.io/entry/2020/12/23/100000
    Flaky test 関連
    

    View Slide

73. 参考
    73
    ● “The GitLab 2022 Global DevSecOps Survey Thriving in an insecure world”,
    https://about.gitlab.com/developer-survey/
    ● “Announcing the 2022 Accelerate State of DevOps Report: A deep dive into security”,
    https://cloud.google.com/blog/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now-out
    ● “2021 State of DevOps Report presented by Puppet”,
    https://www.puppet.com/success/resources/state-of-devops-report
    ● “State of DevOps Report 2023: Platform Engineering Edition”,
    https://www.puppet.com/success/resources/state-of-platform-engineering
    インダストリーレポート
    

    View Slide

74. Thank you!
    74
    

    View Slide