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

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

Transcript

1. ソフトウェアテスト新時代の幕開け 機械学習とデータサイエンスで実現するテスト運用の高度化 2023.02.09 渡辺 喬之 Developers Summit 2023
2. 発表者のプロフィール ▶ 渡辺 喬之 (Takayuki Watanabe) ▶ ソフトウェアエンジニア (Launchable, Inc.) ▶ SNS ▶ ブログ: https://blog.takanabe.tokyo ▶ GitHub: takanabe ▶ Twitter: @takanabe_w ▶ 専門分野 ▶ Developer Productivity ▶ Site Reliability 2
3. 3 本プレゼンは個人の意見・経験に基づく見解が多分に 含まれています(その方が面白いと思うので)。 発表者の所属組織の考えを丸ごと反映しているわけで はありません。 Caution!!
4. 今日伝えたいこと 近い将来ソフトウェア開発におけるテストの運用に機械学習とデータサイエンスを取 り入れたアプローチが一般に広く普及するかもしれないということ 4
5. 今日の話の流れ 5 ▶ ソフトウェア開発におけるテストの位置付け ▶ テストを取り巻く環境の変化 ▶ テストが抱える新たな課題 ▶ 機械学習とデータサイエンスを用いた次世代のテスト運用
6. ソフトウェア開発における テストの位置付け 6
7. ソフトウェア開発におけるテストの位置付け 7 E2E Test Integration Test Unit Test (referenced from Wikipedia) ▶ ウォーターフォール(V字モデル)、アジャイル開発どちらもテストは必要 Costが高く開発者へのフィードバックが遅い Costが低く開発者へのフィードバックが早い
8. 8 ▶ テストを書くことで長期的な開発速度と品質にプラスの効果がある ▶ テストを書くことでコード (あるいは機能)に対して品質を保証できる ▶ テストに対象のコードの使い方が書かれるため 設計書として使える ▶ テストがあれば積極的な機能追加やリファクタリングによる 改善ができる ▶ テストを書くことで開発中のコードに対して早いフィードバックを得られる ▶ 特別なケースを除けばテストを書かない理由はもはやない ▶ 近代のソフトウェア開発ではテストを書くのが標準 ▶ 書けない場合はその理由が明らかになっていることが重要 なぜテストを書くのか？
9. テストを取り巻く環境の変化 9
10. テストを取り巻く環境の変化 10 ▶ テストの設計や実装に関するノウハウの普及 ▶ テスト実行環境の進化 ▶ CI/CDを通じたテスト自動化の重要性の認知 ▶ テスト生成技術の進化 ▶ テスト実装・自動化の容易性と実行数の相関
11. テストの設計や実装に関するノウハウの普及 11 (引用: “ソフトウェアテストの歴史と近年の動向 ”, https://www.slideshare.net/Bugler/ss-139696080)
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
13. CI/CDを通じたテスト自動化の重要性の認知 13 ▶ 構築コストの低下とその重要性から近年のソフトウェア開発では CI/CDパイプラインは開発の初めから導入されることも多い
14. 14 CI/CDを通じたテスト自動化の重要性の認知 ▶ 様々な著書でCI/CDパイプラインによる再現可能なプロセスの自動化と ソフトウェア開発のパフォーマンスの因果関係が説かれている (引用: “Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations”, pp. 77-78,2018)
15. 15 CI/CDを通じたテスト自動化の重要性の認知 ▶ インダストリーレポートによるとサイズによらずDevOps、CI/CD を 適用している企業が増えていることがわかる
16. テスト生成技術の進化 16 ▶ ローコード・ノーコードによるE2Eテスト生成技術の進化 ▶ On-premise: Selenium, Cypress ▶ SaaS: mabl, MagicPod, Autify ▶ New!! 機械学習によるテストコード生成技術の進化 ▶ Pair-programming: GitHub Copilot, AWS CodeWhisperer ▶ General purpose: ChatGPT
17. テスト実装・自動化の容易性と実行数の相関 17 テストの実装 ノウハウの普及 実装・自動化が難しい 実装・自動化が簡単 Today テスト生成技術の進化 テスト実行環境の進化 テスト自動化の 重要性の認知 Future Past の大きさ = 自動テスト実行数の量
18. テスト自動化は良いことしかない・・・？ 18 ▶ CI/CDパイプラインでテスト実行数が増えると別の課題が見えてくる
19. テスト自動化が抱える新たな課題 19
20. テスト自動化が抱える新たな課題 20 ▶ 時代の潮流としてテスト自動化が進みテストの数は今後ますます増えていく ▶ 環境や技術の進化がそれを後押しする ▶ 現在テストがないソフトウェアにもテストは追加されていく ▶ コードレビューでテストを追加することに反対する人は少ない
21. テスト自動化が抱える新たな課題 21 ▶ 以下の問題がソフトウェア開発で現れる ▶ テスト実行時間の増加 ▶ 時折失敗する不安定なテストの出現 ▶ テストのメンテナンスコストが増加
22. テスト実行時間の増加の弊害 22 ▶ CI/CDパイプラインのリードタイムとMTTRが増加する ▶ 例) コードを少し変更しただけなのに全てのテストが通るまで待つ必要がある ▶ CI/CDパイプラインがタイムアウトで失敗するようになる ▶ テスト実行のための計算コスト(=サーバ代)が増加する ▶ テスト実行時間を減らすためにテスト並列化が必要になる ▶ 全ての開発者が並列処理を熟知しているわけではないため不安定になる要因になりうる
23. 不安定なテストの弊害 23 ▶ 一部の不安定なテストが原因でテスト全体の信頼度が低下する ▶ 例)新しく開発に参画したメンバーはどのテストが Flakyか知らないため不安になる ▶ コード変更がない時に成功、失敗の両方の結果を返すテストを Flakyなテストと言います ▶ CI/CDパイプラインのリードタイムとMTTRが増加する ▶ 例)自分が書いたコードと全く関係ないテストが Flakyでテストのリトライが必要 ▶ 理想はFlakyテストがないことだが、現実の開発でFlakyテストを根絶やすのは 困難
24. メンテナンスコスト増加の弊害 24 ▶ テストは足すのは簡単だが、メンテナンスは大変という特徴がある ▶ 開発者の精神的なストレスになる ▶ 例)既に退職した人が書いたよくわからないテストが大量にあるが断捨離の判断が出来ない ▶ 例)冗長なテストがレポジトリの至る所にあるが緊急度やリファクタリングのインパクトを他者に説 明するのが難しい ▶ 例)誰にも評価されない孤高の職人になりうる = キャリアの停滞に繋がる
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パイプラインのボトルネック になる
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
27. 27 ▶ テストを書くことで長期的な開発速度と品質にプラスの効果がある(?) ▶ テストを書くことでコード (あるいは機能)に対して品質を保証できる ▶ 不安定なテストがあるため 信頼できない ▶ テストに対象のコードの使い方が書かれるため 設計書として使える ▶ テストがあれば積極的な機能追加やリファクタリングによる 改善ができる ▶ テストの待ち時間が増え、不安定なテストがあるので 変更が億劫になる ▶ テストを書くことで開発中のコードに対して早いフィードバックを得られる ▶ テストの待ち時間が増えるので フィードバックが遅い ,あるいは無視する (再考)なぜテストを書くのか？
28. テストは書いて終わりではない 28 ▶ テスト自動化で本来やりたかったことが達成できなくなってしまう ▶ 他のコードと一緒で運用していく必要がある ▶ 開発者の努力の積算値がテスト運用効率に現れる
29. 次世代のテスト運用 29 ▶ 努力するにしても効率的な打ち手を選択したい ▶ 理想的なテストの運用方法(QAOps)を模索する必要がある ▶ 機械学習による次世代のテスト運用 ▶ データサイエンスによる次世代のテスト運用
30. 機械学習による次世代のテスト運用 30
31. 機械学習を使ったテスト運用の事例 31 (引用: 本資料末尾の参考 /機械学習・データサイエンスを使ったテスト運用戦略関連を参照 )
32. 32 32 何をしているのか？ 一般的なソフトウェア開発で使えるのか？ 機械学習を使ったテスト運用の事例 (引用: 本資料末尾の参考 /機械学習・データサイエンスを使ったテスト運用戦略関連を参照 )
33. 33 ▶ テストの数が多すぎて変更に関連する全てのテストを実行するのは不可能 ▶ 実行時間的制約 ▶ コンピューティングリソース的制約 ▶ 開発者へのフィードバック速度の期待値 ▶ 機械学習を用いて実行するテストの取捨選択をしている ▶ 全テスト実行で発見できるバグを見落とすリスクを受け入れる 大規模なソフトウェア開発では既知の課題
34. Predictive Test Selection (PTS)とは 34 ▶ Meta社の提案手法ではモデルの学習に以下の特徴量を利用 ▶ ファイルの変更履歴 ▶ ファイル変更数 ▶ 変更により実行されるテスト数 ▶ ファイルの拡張子 ▶ ファイルの編集者数 ▶ テストの失敗率の履歴 ▶ etc… (引用: https://engineering.fb.com/2018/11/21/developer-tools/predictive-test-selection/)
35. Predictive Test Selection (PTS)とは 35 ▶ モデルはテストが失敗する確率を予測する ▶ 失敗しないであろうテストはあえて実行しないという選択が可能 ▶ リスク許容度に応じてテスト実行数を減らすことが可能 (引用: https://engineering.fb.com/2018/11/21/developer-tools/predictive-test-selection/)
36. 36 ▶ テストとメタデータを入力として機械学習でテストの結果を予測する ▶ 失敗する確率が低い(実行する価値が低い)テストを実行対象から除くことでテ ストの総数を減らす ▶ CI/CDに組み込むことで人の手を介さずテストの取捨選択を行う Predictive Test Selection (PTS)とは Test A Test B Test C PTS 実行したいテスト郡 （+メタデータ) PTSで選択されたテスト郡 Test A Test B 入力 出力 (推論結果)
37. PTS導入のケーススタディ 37 ▶ ケース1: テスト数は大規模ではなくコミットごとに全てのテストの自動実行が可 能な場合 ▶ CI/CDパイプラインを通じて Pull Requestとmain ブランチで全てのテストを自動実行 ▶ PTS導入後の変化: ??? ▶ ケース2: テスト数が大規模なのでコミットごとに全てのテストを実行したくない 場合 ▶ CI/CDパイプラインを通じて mainブランチでのみ全てのテストを自動実行 ▶ PTS導入後の変化: ???
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
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
40. PTS導入のケーススタディ 40 ▶ ケース1: チームのサイズもテスト数も大規模ではなく全てのテストの自動実行 は可能 ▶ CI/CDパイプラインを通じて Pull Requestとmain ブランチで全てのテストを自動実行 ▶ PTS導入後の変化: リリース前の全テスト実行という セーフティーネットを維持しつつ、開 発時に早いフィードバックとリリースのリードタイムの削減 が期待できる ▶ ケース2: チームのサイズもテスト数もそれなりに大規模なのでコミットごとに全 てのテストを回したくない ▶ CI/CDパイプラインを通じて mainブランチでのみ全てのテストを自動実行 ▶ PTS導入後の変化: Shift Leftにより開発時に早いフィードバック が得られ、結果的に リ リースのリードタイムの削減 が期待できる
41. PTSの汎用性に関する議論 41 ▶ PTSはBig Techのようにテストが多すぎて全て実行することが出来ないという 課題を解決するために生まれた ▶ 多くのソフトウェア開発においてそこまで大規模なテストは存在しない
42. PTSの汎用性に関する議論 42 ▶ 一方でテストを自動化している場合コード変更時はテストが通るまでリリース出 来ない、テスト実行時間は少ない方がいいという事実は不変 ▶ 規模が小さいソフトウェアでもPTSの恩恵はある ▶ 例) サーバコストの削減 : テスト実行時間 x 1時間あたりのCI利用料金 ▶ 例) コンテキストスイッチ時間の短縮 : テスト実行時間分現在と違うタスクをする ▶ リスクを受け入れて価値の高いテストだけを実行するテスト運用戦略は新しい 考え方だが汎用性は高いため一般化する可能性はある
43. PTSを小さなチームで使った例 43 ▶ Launchableの全エンジニア(8人)の１ヶ月あたりのテスト実行時間 ▶ テスト実行時間が約 1/2になっている(Pull Requestのテスト待ち時間が 10->5分になる) ▶ 2022年12月年の実績をベースにすると年間 1,296時間のテスト実行時間が削減可能 PTSなし PTSあり 削減時間
44. データサイエンスによる 次世代のテスト運用 44
45. Developer Productivity(DP)のメトリクストレンド 45 ▶ DevOpsの4つのメトリクス ▶ デプロイ頻度 ▶ 変更のリードタイム ▶ 変更時障害率 ▶ サービス復元時間 ▶ 著書Accelerateで提唱 ▶ GoogleのDevOps Research and Assessmentチームが引き続き研究を続 けている。DORAメトリクスやFour Keysと呼ばれている
46. 46 ▶ 他にもSPACEと呼ばれる生産性測定の フレームワークが提案されている ▶ 開発者個人やチームのパフォーマンスの計 測と可視化に大きな需要がある Developer Productivity(DP)のメトリクストレンド
47. Site Reliablity Engineeringのメトリクストレンド 47 ▶ MTTRやMTTDなどインシデントマネジメントのパフォーマンスを測定す るメトリクスの再認知 (引用:https://speakerdeck.com/takanabe/sre-next-2022-sensible-incident-management-for-software-startups?slide=49)
48. 48 ▶ SLO, SLI, SLA, Error Budget, Toil 等の概念の普及 Site Reliablity Engineeringのメトリクストレンド (引用: https://sre.google/sre-book)
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)
50. CI/CDから見たDP/SREメトリクスのスコープ 50 SREのメトリクスのスコープ DPのメトリクスのスコープ
51. 51 SREのメトリクスのスコープ DPのメトリクスのスコープ CI/CDから見たDP/SREメトリクスのスコープ
52. テストのプロセス改善に使えるのか 52 ▶ DPのメトリクスはCI/CDパイプライン全体のパフォーマンスに着目 ▶ なんとなくの傾向はわかるがそれ自体を見て次のアクションを決めることは出来ない ▶ テスト実行時間や安定性が悪化すれば、 DPのメトリクスも悪化する関係にある ▶ SREのメトリクスのサービス運用特化で利用者は次のアクション決めやすい ▶ 一方でテストのプロセス改善で利用できるものではない
53. テスト(QA)のプロセス改善に使えるのか 53 ▶ QA特化の決定的なメトリクスはない (もしあったらこっそり教えて下さい) QAのメトリクスのスコープ
54. QAのメトリクスの考察 54 ▶ Symptomaticメトリクス ▶ 何かが起きている事を検知する ▶ Causalメトリクス ▶ なぜ起きているかを検知する ▶ QAのメトリクスとしては集計方法を変えるだけ同じものが使える ▶ Symptomaticメトリクスは全てのテストの集計値 ▶ CaucalメトリクスはTest caseごとの集計値
55. データサイエンスによるQAメトリクスの算出 55 ▶ データサイエンスのアプローチを利用してQAのメトリクスを算出する ▶ ベイズ推定 ▶ 統計 ▶ クラスタ分析 ▶ etc… ▶ 算出したメトリクスを可視化し運用に利用する
56. QAのメトリクスの考察 56 ▶ 使えそうなQAのメトリクス ▶ Flakiness score ▶ Test durations ▶ Failure rate ▶ Auto-healing failure count ▶ Never failing test ratio
57. QAのメトリクス: Flakiness score ▶ そのテストがflakyな確率をスコアで表現する ▶ テストがどの程度信頼できるかを表現するメトリクス ▶ 単純な２値分類(flaky or not flaky)ではなく0 ~ 1 のスコアで表現する ▶ 対象のテスト結果の確率がわかれば算出可能 ▶ それらの確率がわかっていたら苦労しない ▶ ただし、そのテストの過去の実行結果はわかる 57
58. QAのメトリクス: Flakiness score 58 ▶ 過去のテスト結果に対して最尤推定やベイズ推定を使うことで算出可能 (引用: https://engineering.fb.com/2020/12/10/developer-tools/probabilistic-flakiness/) Count Count 過去のテスト結果 過去のテスト結果 Pass Fail Pass Fail 求めたい確率の分布
59. QAのメトリクスの活用法の考察 59 ▶ SymptomaticメトリクスとCausalメトリクスをどのように使うか？ ▶ Symptomaticメトリクスに閾値を設定して、閾値を超えたらチケットを作成して改善に取り組む ▶ e.g. Pre-mergeのaverage Durationが1時間を超えたので原因を調査するためのチ ケットを発行する ▶ CausalメトリクスはSymptomaticメトリクスと合わせて改善するべきテストの特定に使う ▶ e.g. Pre-mergeのaverage Durationが長くなった原因を調査する ▶ Symptomatic メトリクス -> Causalメトリクスの順でドリルダウンする ▶ ダッシューボードなどで可視化すると調査しやすい
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
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
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
63. Causalメトリクスの(テストケース詳細) How to improve? Flakiness score が高いのでテストを修正するか、リトライの仕組みを入れてください Test case 1 Pass Fail Flaky Infra outage Durationの時系列データ Failure rateの時系列データ Flakiness scoreの時系列データ Test result history 63
64. まとめ 64
65. まとめ 65 ▶ ソフトウェア開発においてテスト自動化は重要な役割を担うが課題はある ▶ 自動実行されるテスト数は今後も増えていく ▶ テスト実行数の増加に伴い実行時間や安定性にまつわる課題が顕著になる ▶ 機械学習とデータサイエンスを利用したテスト運用の高度化が一般的なソフトウェ ア開発のプロセスに組み込まれる未来は近い ▶ Predictive Test Selection によるテストの選択 ▶ QAのメトリクスをデータサイエンスを用いて算出しテストの運用に利用
66. プレゼンに関するご質問は以下で回答します • Twitter: @takanabe_w • E-mail: twatanabe@launchableinc.com 66
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関連
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(エンジニア視点)関連
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関連
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関連
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. 機械学習・データサイエンスを使ったテスト運用戦略関連
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 関連
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 インダストリーレポート
74. Thank you! 74