Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

More Decks by Takayuki WATANABE (渡辺 喬之)

Other Decks in Programming

Transcript

  1. 発表者のプロフィール ▶ 渡辺 喬之 (Takayuki Watanabe) ▶ ソフトウェアエンジニア (Launchable, Inc.)

    ▶ SNS ▶ ブログ: https://blog.takanabe.tokyo ▶ GitHub: takanabe ▶ Twitter: @takanabe_w ▶ 専門分野 ▶ Developer Productivity ▶ Site Reliability 2
  2. ソフトウェア開発におけるテストの位置付け 7 E2E Test Integration Test Unit Test (referenced from

    Wikipedia) ▶ ウォーターフォール(V字モデル)、アジャイル開発どちらもテストは必要 Costが高く開発者へのフィードバックが遅い Costが低く開発者へのフィードバックが早い
  3. 8 ▶ テストを書くことで長期的な開発速度と品質にプラスの効果がある ▶ テストを書くことでコード (あるいは機能)に対して品質を保証できる ▶ テストに対象のコードの使い方が書かれるため 設計書として使える ▶

    テストがあれば積極的な機能追加やリファクタリングによる 改善ができる ▶ テストを書くことで開発中のコードに対して早いフィードバックを得られる ▶ 特別なケースを除けばテストを書かない理由はもはやない ▶ 近代のソフトウェア開発ではテストを書くのが標準 ▶ 書けない場合はその理由が明らかになっていることが重要 なぜテストを書くのか?
  4. テスト実行環境の進化 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
  5. テスト生成技術の進化 16 ▶ ローコード・ノーコードによるE2Eテスト生成技術の進化 ▶ On-premise: Selenium, Cypress ▶ SaaS:

    mabl, MagicPod, Autify ▶ New!! 機械学習によるテストコード生成技術の進化 ▶ Pair-programming: GitHub Copilot, AWS CodeWhisperer ▶ General purpose: ChatGPT
  6. テスト実行時間の増加の弊害 22 ▶ CI/CDパイプラインのリードタイムとMTTRが増加する ▶ 例) コードを少し変更しただけなのに全てのテストが通るまで待つ必要がある ▶ CI/CDパイプラインがタイムアウトで失敗するようになる ▶

    テスト実行のための計算コスト(=サーバ代)が増加する ▶ テスト実行時間を減らすためにテスト並列化が必要になる ▶ 全ての開発者が並列処理を熟知しているわけではないため不安定になる要因になりうる
  7. 不安定なテストの弊害 23 ▶ 一部の不安定なテストが原因でテスト全体の信頼度が低下する ▶ 例)新しく開発に参画したメンバーはどのテストが Flakyか知らないため不安になる ▶ コード変更がない時に成功、失敗の両方の結果を返すテストを Flakyなテストと言います

    ▶ CI/CDパイプラインのリードタイムとMTTRが増加する ▶ 例)自分が書いたコードと全く関係ないテストが Flakyでテストのリトライが必要 ▶ 理想はFlakyテストがないことだが、現実の開発でFlakyテストを根絶やすのは 困難
  8. 25 Code Code Review Unit Tests Nightly Smoke Tests UI

    Testing Integration Tests Pre-merge Post-merge Push to production テストのCI/CDのボトルネック化 ▶ 自動化されたテストがCI/CDパイプラインのボトルネック になる
  9. 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
  10. 27 ▶ テストを書くことで長期的な開発速度と品質にプラスの効果がある(?) ▶ テストを書くことでコード (あるいは機能)に対して品質を保証できる ▶ 不安定なテストがあるため 信頼できない ▶

    テストに対象のコードの使い方が書かれるため 設計書として使える ▶ テストがあれば積極的な機能追加やリファクタリングによる 改善ができる ▶ テストの待ち時間が増え、不安定なテストがあるので 変更が億劫になる ▶ テストを書くことで開発中のコードに対して早いフィードバックを得られる ▶ テストの待ち時間が増えるので フィードバックが遅い ,あるいは無視する (再考)なぜテストを書くのか?
  11. 33 ▶ テストの数が多すぎて変更に関連する全てのテストを実行するのは不可能 ▶ 実行時間的制約 ▶ コンピューティングリソース的制約 ▶ 開発者へのフィードバック速度の期待値 ▶

    機械学習を用いて実行するテストの取捨選択をしている ▶ 全テスト実行で発見できるバグを見落とすリスクを受け入れる 大規模なソフトウェア開発では既知の課題
  12. Predictive Test Selection (PTS)とは 34 ▶ Meta社の提案手法ではモデルの学習に以下の特徴量を利用 ▶ ファイルの変更履歴 ▶

    ファイル変更数 ▶ 変更により実行されるテスト数 ▶ ファイルの拡張子 ▶ ファイルの編集者数 ▶ テストの失敗率の履歴 ▶ etc… (引用: https://engineering.fb.com/2018/11/21/developer-tools/predictive-test-selection/)
  13. Predictive Test Selection (PTS)とは 35 ▶ モデルはテストが失敗する確率を予測する ▶ 失敗しないであろうテストはあえて実行しないという選択が可能 ▶

    リスク許容度に応じてテスト実行数を減らすことが可能 (引用: https://engineering.fb.com/2018/11/21/developer-tools/predictive-test-selection/)
  14. PTS導入のケーススタディ 37 ▶ ケース1: テスト数は大規模ではなくコミットごとに全てのテストの自動実行が可 能な場合 ▶ CI/CDパイプラインを通じて Pull Requestとmain

    ブランチで全てのテストを自動実行 ▶ PTS導入後の変化: ??? ▶ ケース2: テスト数が大規模なのでコミットごとに全てのテストを実行したくない 場合 ▶ CI/CDパイプラインを通じて mainブランチでのみ全てのテストを自動実行 ▶ PTS導入後の変化: ???
  15. 機能開発の単位 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
  16. 機能開発の単位 リリースまでのリードタイムに差が出る 開発者へのフィードバック速度に差が出る ケース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
  17. PTS導入のケーススタディ 40 ▶ ケース1: チームのサイズもテスト数も大規模ではなく全てのテストの自動実行 は可能 ▶ CI/CDパイプラインを通じて Pull Requestとmain

    ブランチで全てのテストを自動実行 ▶ PTS導入後の変化: リリース前の全テスト実行という セーフティーネットを維持しつつ、開 発時に早いフィードバックとリリースのリードタイムの削減 が期待できる ▶ ケース2: チームのサイズもテスト数もそれなりに大規模なのでコミットごとに全 てのテストを回したくない ▶ CI/CDパイプラインを通じて mainブランチでのみ全てのテストを自動実行 ▶ PTS導入後の変化: Shift Leftにより開発時に早いフィードバック が得られ、結果的に リ リースのリードタイムの削減 が期待できる
  18. PTSの汎用性に関する議論 42 ▶ 一方でテストを自動化している場合コード変更時はテストが通るまでリリース出 来ない、テスト実行時間は少ない方がいいという事実は不変 ▶ 規模が小さいソフトウェアでもPTSの恩恵はある ▶ 例) サーバコストの削減

    : テスト実行時間 x 1時間あたりのCI利用料金 ▶ 例) コンテキストスイッチ時間の短縮 : テスト実行時間分現在と違うタスクをする ▶ リスクを受け入れて価値の高いテストだけを実行するテスト運用戦略は新しい 考え方だが汎用性は高いため一般化する可能性はある
  19. Developer Productivity(DP)のメトリクストレンド 45 ▶ DevOpsの4つのメトリクス ▶ デプロイ頻度 ▶ 変更のリードタイム ▶

    変更時障害率 ▶ サービス復元時間 ▶ 著書Accelerateで提唱 ▶ GoogleのDevOps Research and Assessmentチームが引き続き研究を続 けている。DORAメトリクスやFour Keysと呼ばれている
  20. 48 ▶ SLO, SLI, SLA, Error Budget, Toil 等の概念の普及 Site

    Reliablity Engineeringのメトリクストレンド (引用: https://sre.google/sre-book)
  21. QAのメトリクスの考察 54 ▶ Symptomaticメトリクス ▶ 何かが起きている事を検知する ▶ Causalメトリクス ▶ なぜ起きているかを検知する

    ▶ QAのメトリクスとしては集計方法を変えるだけ同じものが使える ▶ Symptomaticメトリクスは全てのテストの集計値 ▶ CaucalメトリクスはTest caseごとの集計値
  22. QAのメトリクスの考察 56 ▶ 使えそうなQAのメトリクス ▶ Flakiness score ▶ Test durations

    ▶ Failure rate ▶ Auto-healing failure count ▶ Never failing test ratio
  23. QAのメトリクス: Flakiness score ▶ そのテストがflakyな確率をスコアで表現する ▶ テストがどの程度信頼できるかを表現するメトリクス ▶ 単純な2値分類(flaky or

    not flaky)ではなく0 ~ 1 のスコアで表現する ▶ 対象のテスト結果の確率がわかれば算出可能 ▶ それらの確率がわかっていたら苦労しない ▶ ただし、そのテストの過去の実行結果はわかる 57
  24. QAのメトリクスの活用法の考察 59 ▶ SymptomaticメトリクスとCausalメトリクスをどのように使うか? ▶ Symptomaticメトリクスに閾値を設定して、閾値を超えたらチケットを作成して改善に取り組む ▶ e.g. Pre-mergeのaverage Durationが1時間を超えたので原因を調査するためのチ

    ケットを発行する ▶ CausalメトリクスはSymptomaticメトリクスと合わせて改善するべきテストの特定に使う ▶ e.g. Pre-mergeのaverage Durationが長くなった原因を調査する ▶ Symptomatic メトリクス -> Causalメトリクスの順でドリルダウンする ▶ ダッシューボードなどで可視化すると調査しやすい
  25. 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
  26. 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
  27. 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
  28. Causalメトリクスの(テストケース詳細) How to improve? Flakiness score が高いのでテストを修正するか、リトライの仕組みを入れてください Test case 1

    Pass Fail Flaky Infra outage Durationの時系列データ Failure rateの時系列データ Flakiness scoreの時系列データ Test result history 63
  29. 参考 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関連
  30. 参考 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(エンジニア視点)関連
  31. 参考 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関連
  32. 参考 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関連
  33. 参考 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. 機械学習・データサイエンスを使ったテスト運用戦略関連
  34. 参考 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 関連
  35. 参考 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 インダストリーレポート