From Testing Automation to Continuous Testing

Transcript

1. From Testing Automation To Continuous Testing @ Tokyo Software Testing Meetup Mar 20th, 2024
2. Takuya Suemura 末村 拓也 󰏦 •QA Manager at •Forklift operator -> PHP developer -> QAE -> Support •Committee of JaSST Online •A serious TETRIS player
3. Agenda 1. The major problems on the Testing Automation 2. How do we solve them with Shift Left & Shift Right 3. How can we shift to the Continuous Testing model
4. 01. Testing automation problems
5. A product development team • Product Owner (PO) creates a backlog item • Developer (Dev) implements the backlog item • QA creates the test cases according to the backlog item PO QA Dev
6. Testing at the test phase Impleme nt Backlog Ticket Ticket Ticket Impleme nt Impleme nt QA Test Release Bug report UT UT UT
7. Automate manual QA test Impleme nt Backlog Ticket Ticket Ticket Impleme nt Impleme nt QA Test Release Bug report UT UT UT Automation Target
8. Automate manual QA test Impleme nt Backlog Ticket Ticket Ticket Impleme nt Impleme nt Release Bug report UT UT UT E2E Automated test
9. The major problems on testing automation Impleme nt Backlog Ticket Ticket Ticket Impleme nt Impleme nt Release Bug report UT UT UT E2E Automated test This test code is out of date When will I do exploratory test? What kind of test cases should we automate? I believe automated test verify our quality automatically
10. Test code does not follow changes of the app’s behavior 1) Out-of-date test codes Test script 1. Choose “Small” in “Size” 2. Type “1” into “Quantity” 3. Type tomorrow’s date into “Delivery date” 4. Click “Add to cart Old New Delivery date is removed in the new UI
11. Missing test cases We may miss some test cases due to ambiguous specs Let’s add “Order Now” button to allow users purchase item immediately Gotcha (And I will miss the test pattern when the user has not entry their shipping address)
12. No human eyes Automated tests are too strict to catch something weird • Site Performance is slightly decreased • It’s functional, but not so useful • What will happen if I click the button 100 times in a row? But I can find them!
13. The major problems on testing automation 1. Out-of-date test codes 2. Missing test cases 3. No human eyes
14. But why? QA did a lot of things in the QA test phase all at once • Test design • Regression test • Exploratory test • Usability test • Performance test
15. But why? It can’t be simply replaced by automated tests • Test design • Regression test • Exploratory test • Usability test • Performance test
16. What can we do? • Separate tests • And arrange them into appropriate phases
17. 02. Shift Left & Shift Right
18. What is the shift-left and shift-right? Shift Left: bringing forward things that are too late Shift Right: postponing things that are too early
19. 1. Why automated tests can be out of date? Because we run them AFTER changing the app behavior • Test code does not follow the app behaviour automatically • But human is capable to update manual test script dynamically
20. How can we keep automated test codes up to date? Maintain test code and app’s source code at the same time Test script 1. Choose “Small” in “Size” 2. Type “1” into “Quantity” 3. Type tomorrow’s date into “Delivery date” 4. Click “Add to cart Test script 1. Choose “Small” in “Size” 2. Type “1” into “Quantity” 3. Click “Add to cart
21. AD-TIME! Hard to shift left your test code? Here’s the AI-based self healing as the quickest solution! https://autify.com/
22. 2. Why we may miss test cases? Because we work separately • PO designs specs, Dev implements them, and QA implement the test cases ◦ PO may forget to write a part of spec ◦ Dev and QA implement without being aware of it
23. Let’s create specs and test cases TOGETHER • Brainstorm missing specs and edge cases during the ticket refinement • Create a concrete test cases and agree with them • Devs implement the feature and the automated tests according to the agreed test cases
24. E.g., ) Find business rules with the Feature Mapping https://autify.com/ja/blog/autifyatautify
25. 3. Things that will not be covered by the automated tests Human eyes are capable to catch something weird • Site Performance is slightly decreased • It’s functional, but not so useful • What will happen if I click the button 100 times in a row? But trying to catch them at the test phase all at once is not sustainable
26. Separate responsibility and re-design test architecture • Performance -> Monitoring • Usability -> Beta testing • Find issues flexibly -> Exploratory testing
27. Unblocking manual tests Agile Testing Condensed: A Brief Introduction by Janet Gregory and Lisa Crispin
28. 03. Continuous testing
29. Continuous testing https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
30. Continuous testing https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ Brainstorm specs and test cases Write and maintain automated tests Run automated tests Exploratory and beta testing Monitoring
31. How can we learn from the right side? https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ Brainstorm specs and test cases Write and maintain automated tests Run automated tests Exploratory and beta testing Monitoring
32. Get insights from the experiments • The performance tuning affect 80% of network request and reduce 30% of response time • The closed beta test gets feedback from the • It turned out that there is a potential risk of data duplication from the exploratory test
33. Then, we can improve our product CONTINUOUSLY https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ Brainstorm specs and test cases Write and maintain automated tests Run automated tests Exploratory and beta testing Monitoring
34. Thank you for your attention Let’s discuss at the networking time!
35. Make unknown to known Known Unknown Known Concrete knowledge Certain risks Unknown Untapped knowledge Uncertain risks 1) Test uncertainty and make them concrete knowledge 2) Then, we can automate them!
36. 2020年: テストを自動化するのをやめ、自動テストを作ろう 　手動でやってきたテストをただ自動化する だけじゃなく、ソフトウェアの一部として開発 を支える自動テストをやっていきましょう、と いう話。 　今日の発表の原点となっています。
37. 2023年: リファクタリングが先か、テストが先か 　一つのテストレベルで全部をまかなおうと せず、徐々にテストレベルを落としていくこと で、自動テストをもっと効果的にしていこうと いう話。 　直接今日の発表に関わるわけではないで すが、少し関連しています。
38. 今日話すこと ある開発チームのテストが 継続的 テストに進化するまでの道筋
39. よくある開発の流れ 実装 バックログ チケット チケット チケット 実装 実装 テスト リリース バグ報告
40. 自動化してみた 実装 バックログ チケット チケット チケット 実装 実装 リリース バグ報告 E2E 自動テスト
41. 壁
42. DevOps https://wsmintl.com/blog/increase-efficiency-using-devops-manufacturing/
43. 継続的テスト https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
44. どうやって変わればいいのだろう 壁
45. 今日話すこと ある開発チームのテストが 継続的テスト に進化するまでの道筋を 順を追って説明します クライマックステスト テスト自動化 シフトレフト テスト リアーキテクティング 継続的テスト
46. 01. クライマックステスト クライマックステスト テスト自動化 シフトレフト テスト リアーキテクティング 継続的テスト
47. ある開発チーム • Webアプリケーション開発 • 開発者10人 + PO1人 + QA1人 • スクラム開発 / 1スプリント2週間 • スプリントの終わりにリリース PO QA 開発者
48. クライマックステスト 実装 バックログ チケット チケット チケット 実装 実装 テスト リリース バグ報告 UT UT UT ・開発者はユニットテストを書くが、 E2Eは 書かない ・リリースの直前にQAが手動テスト ・リリース3日前にコードフリーズ（リリース 範囲の確定）
49. 課題 一度にリリースする量が多い • 不具合が起きた時、原因を突き止めるのに時間がかかる • 不具合が起きた時、ロールバックが難しい • ライブラリのアップデートやセキュリティアップデートが入れづ らい
50. 課題 駆け込みマージが多い • リリースを逃すと、次のリリースは2週間後 • 充分テストせずマージされる
51. 課題 手戻りが多い • QAテストで不具合が見つかる→修正→再テスト • テストがリリースまでに間に合わないことも
52. ソリューション: テスト自動化？ 手動テストを自動化すれば • リリース頻度を増やせる ◦ →リリーススコープが小さくなる ◦ →駆け込みマージが減る ◦ →高速な再テスト
53. 02. テスト自動化 クライマックステスト テスト自動化 シフトレフト テスト リアーキテクティング 継続的テスト
54. とにかく自動化してみよう • テスト実行だけを自動化する • テストする環境や項目は変えない • QAチームの手動テスト工数削減が目的
55. クライマックステスト 実装 バックログ チケット チケット チケット 実装 実装 テスト リリース バグ報告 UT UT UT
56. 自動化する 実装 バックログ チケット チケット チケット 実装 実装 リリース バグ報告 UT UT UT E2E 自動テスト 手動テスト
57. 成果 - テスト実行時間の短縮 • 今まで4時間程度かけていたテスト実行が 1〜2時間程度で完了するようになった
58. E2E 自動テスト 手動テスト 課題 - 問題に気づくのが遅い バックログ チケット チケット チケット リリース バグ報告 ここでようやく問題に気づく このテストコード 古いみたいだよ 実装 実装 実装 UT UT UT
59. 課題 - 問題に気づくのが遅い • アプリケーションの内部構造の変化による失敗 • 仕様の変更による失敗 • 不具合による失敗 これらの確認や修正は リリースの直前 に発生する テストコードのメンテナンス という新たな作業
60. 成果 - テスト実行時間の短縮 • 今まで4時間程度かけていたテスト実行が 1〜2時間程度で完了するようになった • しかし、テストコードのメンテナンスが障壁となり QAの作業負荷はあまり減らなかった
61. 次のチャレンジ 開発の「後」にテスト工程が集中しているのが悪い 開発の「途中」に動かしたらどうなるだろう？
62. 03. シフトレフト クライマックステスト テスト自動化 シフトレフト テスト リアーキテクティング 継続的テスト
63. 開発の「後」に集中しているテストを バックログ チケット チケット チケット リリース バグ報告 実装 実装 実装 UT UT UT E2E 自動テスト 手動テスト
64. 開発の「途中」に持ってくる バックログ チケット チケット チケット リリース E2E E2E E2E 実装 実装 実装 UT UT UT 手動テスト
65. 開発中に問題に気づける バックログ チケット チケット チケット E2E E2E E2E 実装 実装 実装 UT UT UT バックログ テストコード が古い バグがある リリース 手動テスト
66. 開発の途中でテストする 開発中からE2Eテストを書く/実行する → 開発中にテストの失敗に気づく → 開発中にテストコードがメンテナンスされる
67. テストの独立性を高める
68. 日常的に実行されるようにする E2E UT
69. 成果 • 問題に気づくタイミングが早くなった • リリース直前の仕事が減った コードフリーズが短縮され リリースサイクルを 2週に1回 → 毎週 に短縮できた
70. 課題 - 開発者たちのフラストレーション CI実行時間が長くなった ユニットテストで充分なのに E2Eテスト書かないとだめなの？
71. 次のチャレンジ • テストコードを最適化して実行時間を短くしよう • テストの役割を整理して無駄なテストを減らそう
72. 04. テスト リアーキテクティング クライマックステスト テスト自動化 シフトレフト テスト リアーキテクティング 継続的テスト
73. テストを最適化する 実装 バックログ チケット チケット チケット 実装 リリース 実装 自動 テスト 自動 テスト 自動 テスト 手動テスト
74. テストケースのバランスを考える E2E Integration Unit E2E Integration Unit
75. テストの役割分担を考える テストレベル テストベース E2Eテスト ユーザーストーリー、ビジネス要求など 結合テスト APIや大きなコンポーネント ユニットテスト メソッドや関数などの小さなモジュール テストレベルごとに 見つけたいバグが違うんです なるほどね
76. E2Eテストしすぎを減らす 例: メールアドレスのバリデーション • ユニットテストでバリデーションルールをチェックする • 結合テストで正常系/異常系をテストする • E2Eテストで正常系をテストする
77. E2Eテストしすぎを減らす ✅ 正しいメールアドレス foo123@example.com ✅ エイリアスの入ったアドレス foo123+bar@example.com ❌ ローカルパートがない @example.com ❌ ドメインパートがない foo123 ❌ ピリオドが連続している foo123@example..com ❌ スペースが入っている foo 123@example.com 結合テスト ユニットテスト E2Eテスト
78. E2Eテスト以外の選択肢を学ぶ https://www.shoeisha.co.jp/book/detail/9784798178639 https://leanpub.com/everydayrailsrspec-jp
79. カバレッジの考え方 ユースケースカバレッジ: E2Eテストがカバーしているユースケースの割合 コードカバレッジ: 自動テスト全体でカバーしているコードの割合
80. 成果 • E2Eテストの量が減った • 自動テストの実行時間が短くなり、カバレッジは増えた 開発のテンポが良くなり、 リリース頻度を 週1回 → 週4回 に増やせた
81. 課題 ちょっとした修正だ。 QAも忙しそうだし、 手動テストせずに出そう 相談して ほしかった …… 障害
82. 課題 E2Eテスト書いたし バッチリだよね 障害 テストケースが 足りなかった……
83. 課題 一切のバグがない 完璧なプロダクトだ 利用性もテストし たい…… 使いにくい
84. 課題 • どんなテストが必要か、チームで議論する機会がない • 機能性しかテストしていない • 結局QAの手動テストはボトルネックのまま
85. 次のチャレンジ • 開発の「前」にテストについて議論しよう • 開発の「後」にもたくさんテストしよう • アンブロッキングなプロセスを作ろう
86. 05. 継続的テスト クライマックステスト テスト自動化 シフトレフト テスト リアーキテクティング 継続的テスト
87. 課題感が変わった • ✅ 一度にリリースする量が多い • ✅ 駆け込みマージが多い • ✅ 手戻りが多い • どんなテストが必要か、 チームで議論する機会がない • 機能性以外のテストがない • QAの手動テストが ボトルネックになっている
88. 課題感が変わった • どんなテストが必要か、 チームで議論する機会がない • 機能性以外のテストがない • QAの手動テストが ボトルネックになっている • 必要なテストについて議論する • 非機能性もテストする • QAの手動テストに頼らず 様々な方法を使う • QAの手動テストを挟まず どんどんデプロイする
89. 作る前からリリースの後までずっとテストする • 開発前: 仕様を理解する、仕様の抜け漏れを減らす • リリース前: 未知の不具合を探る • 段階的ロールアウト: ユーザーの反応を見る • GA (General Availability): 監視
90. いろんなところでテストする 実装 バックログ チケット チケット チケット 実装 デプロイ 実装 自動 テスト 自動 テスト 自動 テスト デプロイ デプロイ β GA
91. 開発の前 実装 バックログ チケット チケット チケット 実装 デプロイ 実装 自動 テスト 自動 テスト 自動 テスト デプロイ デプロイ β GA
92. 実例マッピングでビジネスルールを発見する https://speakerdeck.com/nihonbuson/example-mapping
93. リファインメントでテスト計画を立てる 💡 SMSでの多要素認証 E2Eテスト: • ユーザーは電話番号にSMSを送信できる。 • ユーザーが不正な電話番号を指定すると、エラーが表示される。 • 多要素認証を有効にしていないユーザーには、SMS認証画面が表示されない。 結合テスト: • Twilioのテスト用番号を使って正常系/異常系のテストをする。 探索的テスト: • 30分 3~5人 出来るだけ幅広いモバイルキャリア、OSを準備する • 目的: モバイルキャリアや端末に依存する問題を見つける。 ロールアウト: • 日本国内の1%のユーザーに対して有効にし、段階的に範囲を広げる。
94. リファインメントでテスト計画を立てる 💡 バグ修正: 検索結果表示数に 100 を指定しても表示数が変わらない E2Eテスト: • ユーザーは “50” を指定すると検索結果が50件になる。（既存） 結合テスト: • APIパラメーターとして 25/50/75/100 が渡されたとき、レスポンスに含まれるアイテムの 数はそれらに準じた数になる。 • 検索結果の数が指定された数より少ない場合は、すべての検索結果がレスポンスに含 まれる。 探索的テスト: 実施しない。
95. 開発からデプロイまで 実装 バックログ チケット チケット チケット 実装 デプロイ 実装 自動 テスト 自動 テスト 自動 テスト デプロイ デプロイ β GA
96. 継続的デプロイメント • 必要なテストはリファインメントで合意している = QAの署名済み（サインオフ） • 自動テストが全て通ったら そのソフトウェアはリリースできる (Production-Ready) • QAの判断を待たずに開発者がどんどんデプロイする • QAは開発者をブロックせずテストできる
97. フィーチャートグル • 特定のユーザー、ワークスペースにのみ有効にする • n%のユーザーに対して有効にする
98. 継続的デプロイメントとテスト Janet Gregory, Lisa Crispin, and Yuya Kazama. Agile Testing Condensed Japanese Edition (Kindle Location 869). Kindle Edition. 図形とイラストの追加は発表者によるもの。
99. ユーザーに使ってもらう 実装 バックログ チケット チケット チケット 実装 デプロイ 実装 自動 テスト 自動 テスト 自動 テスト デプロイ デプロイ β GA
100. ユーザーにテストしてもらう カナリアリリース / パブリックベータリリース • ユーザビリティーの改善 • 互換性など、事前に見つけにくい不具合の発見 ◦ 例: 特定のOS、特定の言語設定でのみ文字化けする ◦ 例: 特定のファイアーウォール設定下でのみ 画面の自動更新が不安定になる
101. リリース後 実装 バックログ チケット チケット チケット 実装 デプロイ 実装 自動 テスト 自動 テスト 自動 テスト デプロイ デプロイ β GA
102. 全ユーザーに使ってもらう GA (General Availability) リリース • 実稼働後中に起きたエラーの対処 • パフォーマンス監視 • UXモニタリング
103. エラーのチェック https://docs.sentry.io/product/issues/
104. Apdexスコア https://en.wikipedia.org/wiki/Apdex
105. Real User Monitoring https://newrelic.com/blog/best-practices/what-is-real-user-monitoring
106. 成果 • 今まで「手動テスト」で一括りにしていた活動が より明確になった • 開発サイクルをブロックせずに手動テストできた • 特定のフェーズに依存せず 様々なところで問題をキャッチできるようになった 週に4回 → 毎日数回 のデプロイの達成 🎉🎉🎉
107. まとめ
108. 今日話したこと • 手動テストに依存したQAテストフェーズから 開発サイクル全体を通した 継続的テスト に進化する 道筋の例を話しました • この例をたたき台にして 自分たちのチームでも話してみてください • 開発サイクルの要所要所で段階的にプロダクトを検証し リズミカルに品質を上げていきましょう クライマックステスト テスト自動化 シフトレフト テスト リアーキテクティング 継続的テスト
109. この通りにやれ、というわけではありません リファインメントを 試してみよう フロントエンドの テストコードを書いてみよう チームの形は様々 今日の話を叩き台にして できることを探してみよう
110. おまけ: 各種宣伝
111. Webアプリケーションの自動テスト Autify for Web 14日間無料トライアル受付中 https://autify.com/ja/trial アジャイル開発のための、 ソフトウェアテスト自動化プラットフォーム「Autify」
112. 一緒に働く仲間を募集しています https://autify.com/ja/careers
113. 一緒に働く仲間を募集しています https://autify.com/ja/careers
114. Enjoy Testing! 本講演をベースにした内容を Autify Blog にて公開予定です 👉 https://blog.autify.com/ja 最新の情報は で！ https://x.com/tsueeemura https://x.com/autifyjapan