テスト自動化から、開発を支える継続的テストへ

by Autify

Slide 1

Slide 1 text

テスト自動化から、開発を支える継続的テストへ Nov 2, 2023

Slide 2

Slide 2 text

Takuya Suemura 末村拓也 ●Autify, Inc ●Technical Support Engineer / Test Automation Specialist ●倉庫内軽作業→PHP開発→QAエンジニア→現職 ●JaSST Online 実行委員 ●趣味: テトリス、音ゲー、メカニカルキーボード

Slide 3

Slide 3 text

2020年: テストを自動化するのをやめ、自動テストを作ろう　手動でやってきたテストをただ自動化するだけじゃなく、ソフトウェアの一部として開発を支える自動テストをやっていきましょう、という話。　今日の発表の原点となっています。

Slide 4

Slide 4 text

2023年: リファクタリングが先か、テストが先か　一つのテストレベルで全部をまかなおうとせず、徐々にテストレベルを落としていくことで、自動テストをもっと効果的にしていこうという話。　直接今日の発表に関わるわけではないですが、少し関連しています。

Slide 5

Slide 5 text

今日話すことある開発チームのテストが継続的テストに進化するまでの道筋

Slide 6

Slide 6 text

よくある開発の流れ実装バックログチケットチケットチケット実装実装テストリリースバグ報告

Slide 7

Slide 7 text

自動化してみた実装バックログチケットチケットチケット実装実装リリースバグ報告 E2E 自動テスト

Slide 8

Slide 8 text

壁

Slide 9

Slide 9 text

DevOps https://wsmintl.com/blog/increase-efficiency-using-devops-manufacturing/

Slide 10

Slide 10 text

継続的テスト https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/

Slide 11

Slide 11 text

どうやって変わればいいのだろう壁

Slide 12

Slide 12 text

今日話すことある開発チームのテストが継続的テストに進化するまでの道筋を順を追って説明しますクライマックステストテスト自動化シフトレフトテストリアーキテクティング継続的テスト

Slide 13

Slide 13 text

01. クライマックステストクライマックステストテスト自動化シフトレフトテストリアーキテクティング継続的テスト

Slide 14

Slide 14 text

ある開発チーム ● Webアプリケーション開発 ● 開発者10人 + PO1人 + QA1人 ● スクラム開発 / 1スプリント2週間 ● スプリントの終わりにリリース PO QA 開発者

Slide 15

Slide 15 text

クライマックステスト実装バックログチケットチケットチケット実装実装テストリリースバグ報告 UT UT UT ・開発者はユニットテストを書くが、 E2Eは書かない・リリースの直前にQAが手動テスト・リリース3日前にコードフリーズ（リリース範囲の確定）

Slide 16

Slide 16 text

課題一度にリリースする量が多い ● 不具合が起きた時、原因を突き止めるのに時間がかかる ● 不具合が起きた時、ロールバックが難しい ● ライブラリのアップデートやセキュリティアップデートが入れづらい

Slide 17

Slide 17 text

課題駆け込みマージが多い ● リリースを逃すと、次のリリースは2週間後 ● 充分テストせずマージされる

Slide 18

Slide 18 text

課題手戻りが多い ● QAテストで不具合が見つかる→修正→再テスト ● テストがリリースまでに間に合わないことも

Slide 19

Slide 19 text

ソリューション: テスト自動化？手動テストを自動化すれば ● リリース頻度を増やせる ○ →リリーススコープが小さくなる ○ →駆け込みマージが減る ○ →高速な再テスト

Slide 20

Slide 20 text

02. テスト自動化クライマックステストテスト自動化シフトレフトテストリアーキテクティング継続的テスト

Slide 21

Slide 21 text

とにかく自動化してみよう ● テスト実行だけを自動化する ● テストする環境や項目は変えない ● QAチームの手動テスト工数削減が目的

Slide 22

Slide 22 text

クライマックステスト実装バックログチケットチケットチケット実装実装テストリリースバグ報告 UT UT UT

Slide 23

Slide 23 text

自動化する実装バックログチケットチケットチケット実装実装リリースバグ報告 UT UT UT E2E 自動テスト手動テスト

Slide 24

Slide 24 text

成果 - テスト実行時間の短縮 ● 今まで4時間程度かけていたテスト実行が 1〜2時間程度で完了するようになった

Slide 25

Slide 25 text

E2E 自動テスト手動テスト課題 - 問題に気づくのが遅いバックログチケットチケットチケットリリースバグ報告ここでようやく問題に気づくこのテストコード古いみたいだよ実装実装実装 UT UT UT

Slide 26

Slide 26 text

課題 - 問題に気づくのが遅い ● アプリケーションの内部構造の変化による失敗 ● 仕様の変更による失敗 ● 不具合による失敗これらの確認や修正はリリースの直前に発生するテストコードのメンテナンスという新たな作業

Slide 27

Slide 27 text

成果 - テスト実行時間の短縮 ● 今まで4時間程度かけていたテスト実行が 1〜2時間程度で完了するようになった ● しかし、テストコードのメンテナンスが障壁となり QAの作業負荷はあまり減らなかった

Slide 28

Slide 28 text

次のチャレンジ開発の「後」にテスト工程が集中しているのが悪い開発の「途中」に動かしたらどうなるだろう？

Slide 29

Slide 29 text

03. シフトレフトクライマックステストテスト自動化シフトレフトテストリアーキテクティング継続的テスト

Slide 30

Slide 30 text

開発の「後」に集中しているテストをバックログチケットチケットチケットリリースバグ報告実装実装実装 UT UT UT E2E 自動テスト手動テスト

Slide 31

Slide 31 text

開発の「途中」に持ってくるバックログチケットチケットチケットリリース E2E E2E E2E 実装実装実装 UT UT UT 手動テスト

Slide 32

Slide 32 text

開発中に問題に気づけるバックログチケットチケットチケット E2E E2E E2E 実装実装実装 UT UT UT バックログテストコードが古いバグがあるリリース手動テスト

Slide 33

Slide 33 text

開発の途中でテストする開発中からE2Eテストを書く/実行する → 開発中にテストの失敗に気づく → 開発中にテストコードがメンテナンスされる

Slide 34

Slide 34 text

テストの独立性を高める

Slide 35

Slide 35 text

日常的に実行されるようにする E2E UT

Slide 36

Slide 36 text

成果 ● 問題に気づくタイミングが早くなった ● リリース直前の仕事が減ったコードフリーズが短縮されリリースサイクルを 2週に1回 → 毎週に短縮できた

Slide 37

Slide 37 text

課題 - 開発者たちのフラストレーション CI実行時間が長くなったユニットテストで充分なのに E2Eテスト書かないとだめなの？

Slide 38

Slide 38 text

次のチャレンジ ● テストコードを最適化して実行時間を短くしよう ● テストの役割を整理して無駄なテストを減らそう

Slide 39

Slide 39 text

04. テストリアーキテクティングクライマックステストテスト自動化シフトレフトテストリアーキテクティング継続的テスト

Slide 40

Slide 40 text

テストを最適化する実装バックログチケットチケットチケット実装リリース実装自動テスト自動テスト自動テスト手動テスト

Slide 41

Slide 41 text

テストケースのバランスを考える E2E Integration Unit E2E Integration Unit

Slide 42

Slide 42 text

テストの役割分担を考えるテストレベルテストベース E2Eテストユーザーストーリー、ビジネス要求など結合テスト APIや大きなコンポーネントユニットテストメソッドや関数などの小さなモジュールテストレベルごとに見つけたいバグが違うんですなるほどね

Slide 43

Slide 43 text

E2Eテストしすぎを減らす例: メールアドレスのバリデーション ● ユニットテストでバリデーションルールをチェックする ● 結合テストで正常系/異常系をテストする ● E2Eテストで正常系をテストする

Slide 44

Slide 44 text

E2Eテストしすぎを減らす ✅ 正しいメールアドレス [email protected] ✅ エイリアスの入ったアドレス [email protected] ❌ ローカルパートがない @example.com ❌ ドメインパートがない foo123 ❌ ピリオドが連続している [email protected] ❌ スペースが入っている foo [email protected] 結合テストユニットテスト E2Eテスト

Slide 45

Slide 45 text

E2Eテスト以外の選択肢を学ぶ https://www.shoeisha.co.jp/book/detail/9784798178639 https://leanpub.com/everydayrailsrspec-jp

Slide 46

Slide 46 text

カバレッジの考え方ユースケースカバレッジ: E2Eテストがカバーしているユースケースの割合コードカバレッジ: 自動テスト全体でカバーしているコードの割合

Slide 47

Slide 47 text

成果 ● E2Eテストの量が減った ● 自動テストの実行時間が短くなり、カバレッジは増えた開発のテンポが良くなり、リリース頻度を週1回 → 週4回に増やせた

Slide 48

Slide 48 text

課題ちょっとした修正だ。 QAも忙しそうだし、手動テストせずに出そう相談してほしかった …… 障害

Slide 49

Slide 49 text

課題 E2Eテスト書いたしバッチリだよね障害テストケースが足りなかった……

Slide 50

Slide 50 text

課題一切のバグがない完璧なプロダクトだ利用性もテストしたい…… 使いにくい

Slide 51

Slide 51 text

課題 ● どんなテストが必要か、チームで議論する機会がない ● 機能性しかテストしていない ● 結局QAの手動テストはボトルネックのまま

Slide 52

Slide 52 text

次のチャレンジ ● 開発の「前」にテストについて議論しよう ● 開発の「後」にもたくさんテストしよう ● アンブロッキングなプロセスを作ろう

Slide 53

Slide 53 text

05. 継続的テストクライマックステストテスト自動化シフトレフトテストリアーキテクティング継続的テスト

Slide 54

Slide 54 text

課題感が変わった ● ✅ 一度にリリースする量が多い ● ✅ 駆け込みマージが多い ● ✅ 手戻りが多い ● どんなテストが必要か、チームで議論する機会がない ● 機能性以外のテストがない ● QAの手動テストがボトルネックになっている

Slide 55

Slide 55 text

課題感が変わった ● どんなテストが必要か、チームで議論する機会がない ● 機能性以外のテストがない ● QAの手動テストがボトルネックになっている ● 必要なテストについて議論する ● 非機能性もテストする ● QAの手動テストに頼らず様々な方法を使う ● QAの手動テストを挟まずどんどんデプロイする

Slide 56

Slide 56 text

作る前からリリースの後までずっとテストする ● 開発前: 仕様を理解する、仕様の抜け漏れを減らす ● リリース前: 未知の不具合を探る ● 段階的ロールアウト: ユーザーの反応を見る ● GA (General Availability): 監視

Slide 57

Slide 57 text

いろんなところでテストする実装バックログチケットチケットチケット実装デプロイ実装自動テスト自動テスト自動テストデプロイデプロイ β GA

Slide 58

Slide 58 text

開発の前実装バックログチケットチケットチケット実装デプロイ実装自動テスト自動テスト自動テストデプロイデプロイ β GA

Slide 59

Slide 59 text

実例マッピングでビジネスルールを発見する https://speakerdeck.com/nihonbuson/example-mapping

Slide 60

Slide 60 text

リファインメントでテスト計画を立てる 💡 SMSでの多要素認証 E2Eテスト: ● ユーザーは電話番号にSMSを送信できる。 ● ユーザーが不正な電話番号を指定すると、エラーが表示される。 ● 多要素認証を有効にしていないユーザーには、SMS認証画面が表示されない。結合テスト: ● Twilioのテスト用番号を使って正常系/異常系のテストをする。探索的テスト: ● 30分 3~5人出来るだけ幅広いモバイルキャリア、OSを準備する ● 目的: モバイルキャリアや端末に依存する問題を見つける。ロールアウト: ● 日本国内の1%のユーザーに対して有効にし、段階的に範囲を広げる。

Slide 61

Slide 61 text

リファインメントでテスト計画を立てる 💡 バグ修正: 検索結果表示数に 100 を指定しても表示数が変わらない E2Eテスト: ● ユーザーは “50” を指定すると検索結果が50件になる。（既存）結合テスト: ● APIパラメーターとして 25/50/75/100 が渡されたとき、レスポンスに含まれるアイテムの数はそれらに準じた数になる。 ● 検索結果の数が指定された数より少ない場合は、すべての検索結果がレスポンスに含まれる。探索的テスト: 実施しない。

Slide 62

Slide 62 text

開発からデプロイまで実装バックログチケットチケットチケット実装デプロイ実装自動テスト自動テスト自動テストデプロイデプロイ β GA

Slide 63

Slide 63 text

継続的デプロイメント ● 必要なテストはリファインメントで合意している = QAの署名済み（サインオフ） ● 自動テストが全て通ったらそのソフトウェアはリリースできる (Production-Ready) ● QAの判断を待たずに開発者がどんどんデプロイする ● QAは開発者をブロックせずテストできる

Slide 64

Slide 64 text

フィーチャートグル ● 特定のユーザー、ワークスペースにのみ有効にする ● n%のユーザーに対して有効にする

Slide 65

Slide 65 text

継続的デプロイメントとテスト Janet Gregory, Lisa Crispin, and Yuya Kazama. Agile Testing Condensed Japanese Edition (Kindle Location 869). Kindle Edition. 図形とイラストの追加は発表者によるもの。

Slide 66

Slide 66 text

ユーザーに使ってもらう実装バックログチケットチケットチケット実装デプロイ実装自動テスト自動テスト自動テストデプロイデプロイ β GA

Slide 67

Slide 67 text

ユーザーにテストしてもらうカナリアリリース / パブリックベータリリース ● ユーザビリティーの改善 ● 互換性など、事前に見つけにくい不具合の発見 ○ 例: 特定のOS、特定の言語設定でのみ文字化けする ○ 例: 特定のファイアーウォール設定下でのみ画面の自動更新が不安定になる

Slide 68

Slide 68 text

リリース後実装バックログチケットチケットチケット実装デプロイ実装自動テスト自動テスト自動テストデプロイデプロイ β GA

Slide 69

Slide 69 text

全ユーザーに使ってもらう GA (General Availability) リリース ● 実稼働後中に起きたエラーの対処 ● パフォーマンス監視 ● UXモニタリング

Slide 70

Slide 70 text

エラーのチェック https://docs.sentry.io/product/issues/

Slide 71

Slide 71 text

Apdexスコア https://en.wikipedia.org/wiki/Apdex

Slide 72

Slide 72 text

Real User Monitoring https://newrelic.com/blog/best-practices/what-is-real-user-monitoring

Slide 73

Slide 73 text

成果 ● 今まで「手動テスト」で一括りにしていた活動がより明確になった ● 開発サイクルをブロックせずに手動テストできた ● 特定のフェーズに依存せず様々なところで問題をキャッチできるようになった週に4回 → 毎日数回のデプロイの達成 🎉🎉🎉

Slide 74

Slide 74 text

まとめ

Slide 75

Slide 75 text

今日話したこと ● 手動テストに依存したQAテストフェーズから開発サイクル全体を通した継続的テストに進化する道筋の例を話しました ● この例をたたき台にして自分たちのチームでも話してみてください ● 開発サイクルの要所要所で段階的にプロダクトを検証しリズミカルに品質を上げていきましょうクライマックステストテスト自動化シフトレフトテストリアーキテクティング継続的テスト

Slide 76

Slide 76 text

この通りにやれ、というわけではありませんリファインメントを試してみようフロントエンドのテストコードを書いてみようチームの形は様々今日の話を叩き台にしてできることを探してみよう

Slide 77

Slide 77 text

おまけ: 各種宣伝

Slide 78

Slide 78 text

Webアプリケーションの自動テスト Autify for Web 14日間無料トライアル受付中 https://autify.com/ja/trial アジャイル開発のための、ソフトウェアテスト自動化プラットフォーム「Autify」

Slide 79

Slide 79 text

一緒に働く仲間を募集しています https://autify.com/ja/careers

Slide 80

Slide 80 text

一緒に働く仲間を募集しています https://autify.com/ja/careers

Slide 81

Slide 81 text

Enjoy Testing! 本講演をベースにした内容を Autify Blog にて公開予定です 👉 https://blog.autify.com/ja 最新の情報はで！ https://x.com/tsueeemura https://x.com/autifyjapan