自動テストをCIで”実行”させるだけでは不十分な理由

自動テストをCIで”実行” させるだけでは不十分な理由 根本 征 シニアソリューションズエンジニア 1

自己紹介 ● 名前：根本 征 / Tadashi Nemoto ● ポジション：Senior Solutions Engineer ● Japan / APAC 担当として、様々な企業様のCI/CD(Web/イン フラ/モバイル/ゲーム)の導入・技術支援をリード ● 経歴 ○ フリマアプリ企業で Software Engineer in Test ○ AI スタートアップ企業で DevOps エンジニア tadashi0713 tadashi-nemoto 2

アジェンダ ● 自動テストをCIで”実行”させるだけでは不十分な理由 ● CircleCI が提供する自動テストをCIで最大限活用させる機能 ○ 自動テスト分割・並列実行 ○ 失敗したテストのみ再実行 ○ テストインサイトダッシュボード ● まとめ 3

自動テストをCIで”実行” させるだけでは不十分な理由 4

皆様の自動テストの導入状況は？ ● まだ導入の検討中 ○ 文化がない、費用対効果など ● 自動テストのスクリプト・ツールを評価している ● 自動テストを運用している ○ 一部の人が手動で動作させている、定期実行(1日に1回) ● CI/CDパイプラインの中に組み込まれている ○ リリース前、Pull Request毎に自動的に実行される 5

皆様の自動テストの導入状況は？ ● まだ導入の検討中 ○ 文化がない、費用対効果など ● 自動テストのスクリプト・ツールを評価している ● 自動テストを運用している ○ 一部の人が手動で動作させている、定期実行(1日に1回) ● CI/CDパイプラインの中に組み込まれている ○ リリース前、Pull Request毎に自動的に実行される 6

自動テストをCI/CDパイプラインに組み込むべき理由は？ https://www.spec-india.com/blog/from-waterfall-to-agile-to-devops-a-cultu ral-and-technological-shift 7

• https://www.spec-india.com/blog/from-waterfall-to-agile-to-devops-a-cultural-and-technological-shift

自動テストをCI/CDパイプラインに組み込むべき理由は？ https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ あらゆるフェーズで自動テストを実行することによって、 より早くフィードバックを得ることができる 結果として継続的に品質とスピードを向上させることができる 8

• https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/

ほとんどのCI/CDツールで”実行”することは可能 ● CI/CD専門ツール ○ CircleCI ● ソースコード管理に付属しているCI/CD ○ GitHub Actions, GitLab CI など ● パブリッククラウドが提供しているCI/CD ○ AWS CodeBuild, Azure DevOps など 9

本当に”実行”することがゴールだった？ ● 自動テストの実行時間が長い ○ ○ テストが増えた、開発規模が大きくなった ■ あらゆるフェーズで実行できるよう、実行時間の短縮が必要 ■ スケールできるプラットフォーム性能が必要 結果が不安定なテスト(Flaky Test)、不要に実行時間が長い テストが紛れている ■ ● これらのテストを定期的に検出・改善する必要がある フィードバックを得る = 失敗した自動テストの調査が必要 ○ 正常な失敗だったか ○ 結果が不安定なテスト(Flaky Test)だったか ■ 再実行、原因調査をする必要がある 10

本当に”実行”することがゴールだった？ ● ● フィードバックを得る = 失敗した自動テストの調査が必要 自動テストをCIで”実行”することがゴールではなく、 ○ 正常な失敗だったか ○ 結果が不安定なテスト(Flaky Test)だったか 自動テストをCI上で ■ 再実行、原因調査をする必要がある あらゆるフェーズで実行できるよう速く実行する 自動テストの実行時間が長い ○ そして、継続的に信頼性の高いフィードバックにする テストが増えた、開発規模が大きくなった ■ ■ あらゆるフェーズで実行できるよう、実行時間の短縮が必要 それによって本来達成したかった スケールできるプラットフォーム性能が必要 継続的な品質とスピードの両立の実現に近づけることができる ○ 結果が不安定なテスト(Flaky Test)、不要に実行時間が長い テストが紛れている ■ これらのテストを定期的に検出・改善する必要がある 11

CircleCIが提供する 自動テストをCIで最大限活用さ せる機能 12

ツールチェインにおけるCircleCIのポジション ソースコード管理 コードコミット コラボレーション オーケストレーション デリバリ ビルド • テスト • デリバリ 本番環境へのリリース 開発 運用 実行 モニタリング • 運用 + さまざまなパートナーとの インテグレーション VCS非依存を今後サポート予定 13

ツールチェインにおけるCircleCIのポジション 本番環境へのリリース VCS(ソースコード管理)系のCI/CDツールは 開発 オーケストレーション 運用 コラボレーション コードコミット どうしても一般的な機能提供で終わってしまう デリバリ 実行 クラウドプロバイダー系のCI/CDツールは ソースコード管理 ビルド • テスト • デリバリ モニタリング • 運用 どうしてもデプロイ(CD)にフォーカスされがち CircleCI(CI/CD専門ツール)はCI/CD、 特にCI(自動テスト)にフォーカスして機能提供・開発 + さまざまなパートナーとの インテグレーション VCS非依存を今後サポート予定 14

CircleCI が提供する自動テストをCIで最大限活用させる機能 ● 自動テスト分割・並列実行 ● 失敗したテストのみ再実行 ● テストインサイトダッシュボード 15

これらの機能を使うために必要なステップ https://circleci.com/docs/ja/2.0/collect-test-data 16

• https://circleci.com/docs/ja/2.0/collect-test-data

CircleCI が提供する自動テストをCIで最大限活用させる機能 ● 自動テスト分割・並列実行 ● 失敗したテストのみ再実行 ● テストインサイトダッシュボード 17

テストの分割 CircleCI でビルド速度を高める最も簡単な方法として、テストの 分割があります。タイミング データを基準にしたテスト分割は特 に効果的です。CircleCI のテスト分割メカニズムでは、テスト リス トを受け取り、parallelism キーで定義された数のノードにテストを 振り分けます。 「開発者がテストの実行を待ちながら過ご している時間というのは、次のコードを書く 時間にはなりえません。言うまでもなく、こ うした時間には、ただ待っていたり、自分 の作業の状況を見失ったりすることでコス トが生じているのです。そのため、フィード バックを迅速に得られるようにすることが なによりも重要です」 - Rob Zuber 18

テストの分割・並列実行 19

テストの分割・並列実行 20

テストの並列処理 4並列で処理した場合 （テストファイルは名前で分割） 1並列で処理した場合 4並列で処理した場合 （テストファイルは過去の動作時間で分割） 21

テストの並列実行 ● ドキュメント ○ ● ブラウザテストの並列実行 ○ ● ● https://circleci.com/docs/ja/parallelism-faster-jobs https://github.com/tadashi0713/circleci-cloudrun-demo/blob/master/.circleci/config.yml#L9 Android のテスト並列実行 ○ https://github.com/tadashi0713/circleci-demo-android/blob/master/.circleci/config.yml#L33 ○ https://circleci.com/ja/blog/android-parallel-testing/ iOS のテスト並列実行(XCUITest) ○ https://github.com/tadashi0713/circleci-demo-ios/blob/master/.circleci/config.yml#L37 ○ https://circleci.com/ja/blog/ios-parallel-testing/ 22

• https://circleci.com/docs/ja/parallelism-faster-jobs
• https://github.com/tadashi0713/circleci-cloudrun-demo/blob/master/.circleci/config.yml#L9
• https://github.com/tadashi0713/circleci-demo-android/blob/master/.circleci/config.yml#L33
• https://circleci.com/ja/blog/android-parallel-testing/
• https://github.com/tadashi0713/circleci-demo-ios/blob/master/.circleci/config.yml#L37
• https://circleci.com/ja/blog/ios-parallel-testing/

テストの並列実行(株式会社SmartHR様) https://circleci.com/ja/case-studies/smarthr/ 23

• https://circleci.com/ja/case-studies/smarthr/

CircleCI が提供する自動テストをCIで最大限活用させる機能 ● 自動テスト分割・並列実行 ● 失敗したテストのみ再実行 ● テストインサイトダッシュボード 24

25

失敗したテストのみ再実行 結果が不安定なテスト(Flaky Test)など、失敗したテストのみを再実行 全てのテストを再実行する必要がないため、実行時間・コストを大幅に削減 26

失敗したテストのみ再実行 27

失敗したテストのみ再実行 28

CircleCI が提供する自動テストをCIで最大限活用させる機能 ● 自動テスト分割・並列実行 ● 失敗したテストのみ再実行 ● テストインサイトダッシュボード 29

インサイトダッシュボード 30

テストインサイトダッシュボード 31

テストインサイトダッシュボード 32

テストインサイトダッシュボード(株式会社カカクコム様) https://speakerdeck.com/hagevvashi/software-test-automation-patterns-at-tabelog-dot-com 33

• https://speakerdeck.com/hagevvashi/software-test-automation-patterns-at-tabelog-dot-com

CircleCI が提供する自動テストをCIで最大限活用させる機能 ● ● ● 自動テスト分割・並列実行 ○ 自動テスト・開発の規模が大きくなっても、より速く実行することができる ○ あらゆるフェーズ(Pull Requestなど)で自動テストを組み込むことができる 失敗したテストのみ再実行 ○ Flaky テストの問題を一時的に回避 ○ 全てのテストを再実行する必要がないため、実行時間・コストを大幅に削減 テストインサイトダッシュボード ○ 不安定なテスト、時間がかかるテストを機械的に検出 ○ 問題を速く見つけ、解決することで、継続的にテストの信頼性を高められる 34

まとめ 35

まとめ ● 自動テストをCI/CDパイプラインに組み込むことによって、より早く フィードバックを得ることができ、結果として継続的にスピードと品質を 向上することができる。 ● 自動テストをCIで”実行”させるだけでは不十分、より速く実行し、 より信頼性のあるフィードバックにしないと目的は達成できない。 ● CI/CD専門ツールのCircleCIではCI(自動テスト実行)にフォーカスした機能を継続 的に提供することが可能 ○ 自動テスト分割・並列実行 ○ 失敗したテストのみ再実行 ○ テストインサイトダッシュボード 36

Thank you!! 37