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

2023-11-02 JaSST'23 Kyushu 招待講演
https://www.jasst.jp/symposium/jasst23kyushu.html

実装完了後の手動テストに依存した開発サイクルに継続的テストのアプローチを適用し、段階的に品質を向上する方法について説明しています。

Transcript

1. テスト自動化から、 開発を支える継続的テストへ Nov 2, 2023
2. Takuya Suemura 末村 拓也 •Autify, Inc •Technical Support Engineer / Test Automation Specialist •倉庫内軽作業→PHP開発→QAエンジニア→現職 •JaSST Online 実行委員 •趣味: テトリス、音ゲー、メカニカルキーボード
3. 2020年: テストを自動化するのをやめ、自動テストを作ろう 　手動でやってきたテストをただ自動化する だけじゃなく、ソフトウェアの一部として開発 を支える自動テストをやっていきましょう、と いう話。 　今日の発表の原点となっています。
4. 2023年: リファクタリングが先か、テストが先か 　一つのテストレベルで全部をまかなおうと せず、徐々にテストレベルを落としていくこと で、自動テストをもっと効果的にしていこうと いう話。 　直接今日の発表に関わるわけではないで すが、少し関連しています。
5. 今日話すこと ある開発チームのテストが 継続的 テストに進化するまでの道筋
6. よくある開発の流れ 実装 バックログ チケット チケット チケット 実装 実装 テスト リリース バグ報告
7. 自動化してみた 実装 バックログ チケット チケット チケット 実装 実装 リリース バグ報告 E2E 自動テスト
8. 壁
9. DevOps https://wsmintl.com/blog/increase-efficiency-using-devops-manufacturing/
10. 継続的テスト https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
11. どうやって変わればいいのだろう 壁
12. 今日話すこと ある開発チームのテストが 継続的テスト に進化するまでの道筋を 順を追って説明します クライマックステスト テスト自動化 シフトレフト テスト リアーキテクティング 継続的テスト
13. 01. クライマックステスト クライマックステスト テスト自動化 シフトレフト テスト リアーキテクティング 継続的テスト
14. ある開発チーム • Webアプリケーション開発 • 開発者10人 + PO1人 + QA1人 • スクラム開発 / 1スプリント2週間 • スプリントの終わりにリリース PO QA 開発者
15. クライマックステスト 実装 バックログ チケット チケット チケット 実装 実装 テスト リリース バグ報告 UT UT UT ・開発者はユニットテストを書くが、 E2Eは 書かない ・リリースの直前にQAが手動テスト ・リリース3日前にコードフリーズ（リリース 範囲の確定）
16. 課題 一度にリリースする量が多い • 不具合が起きた時、原因を突き止めるのに時間がかかる • 不具合が起きた時、ロールバックが難しい • ライブラリのアップデートやセキュリティアップデートが入れづ らい
17. 課題 駆け込みマージが多い • リリースを逃すと、次のリリースは2週間後 • 充分テストせずマージされる
18. 課題 手戻りが多い • QAテストで不具合が見つかる→修正→再テスト • テストがリリースまでに間に合わないことも
19. ソリューション: テスト自動化？ 手動テストを自動化すれば • リリース頻度を増やせる ◦ →リリーススコープが小さくなる ◦ →駆け込みマージが減る ◦ →高速な再テスト
20. 02. テスト自動化 クライマックステスト テスト自動化 シフトレフト テスト リアーキテクティング 継続的テスト
21. とにかく自動化してみよう • テスト実行だけを自動化する • テストする環境や項目は変えない • QAチームの手動テスト工数削減が目的
22. クライマックステスト 実装 バックログ チケット チケット チケット 実装 実装 テスト リリース バグ報告 UT UT UT
23. 自動化する 実装 バックログ チケット チケット チケット 実装 実装 リリース バグ報告 UT UT UT E2E 自動テスト 手動テスト
24. 成果 - テスト実行時間の短縮 • 今まで4時間程度かけていたテスト実行が 1〜2時間程度で完了するようになった
25. E2E 自動テスト 手動テスト 課題 - 問題に気づくのが遅い バックログ チケット チケット チケット リリース バグ報告 ここでようやく問題に気づく このテストコード 古いみたいだよ 実装 実装 実装 UT UT UT
26. 課題 - 問題に気づくのが遅い • アプリケーションの内部構造の変化による失敗 • 仕様の変更による失敗 • 不具合による失敗 これらの確認や修正は リリースの直前 に発生する テストコードのメンテナンス という新たな作業
27. 成果 - テスト実行時間の短縮 • 今まで4時間程度かけていたテスト実行が 1〜2時間程度で完了するようになった • しかし、テストコードのメンテナンスが障壁となり QAの作業負荷はあまり減らなかった
28. 次のチャレンジ 開発の「後」にテスト工程が集中しているのが悪い 開発の「途中」に動かしたらどうなるだろう？
29. 03. シフトレフト クライマックステスト テスト自動化 シフトレフト テスト リアーキテクティング 継続的テスト
30. 開発の「後」に集中しているテストを バックログ チケット チケット チケット リリース バグ報告 実装 実装 実装 UT UT UT E2E 自動テスト 手動テスト
31. 開発の「途中」に持ってくる バックログ チケット チケット チケット リリース E2E E2E E2E 実装 実装 実装 UT UT UT 手動テスト
32. 開発中に問題に気づける バックログ チケット チケット チケット E2E E2E E2E 実装 実装 実装 UT UT UT バックログ テストコード が古い バグがある リリース 手動テスト
33. 開発の途中でテストする 開発中からE2Eテストを書く/実行する → 開発中にテストの失敗に気づく → 開発中にテストコードがメンテナンスされる
34. テストの独立性を高める
35. 日常的に実行されるようにする E2E UT
36. 成果 • 問題に気づくタイミングが早くなった • リリース直前の仕事が減った コードフリーズが短縮され リリースサイクルを 2週に1回 → 毎週 に短縮できた
37. 課題 - 開発者たちのフラストレーション CI実行時間が長くなった ユニットテストで充分なのに E2Eテスト書かないとだめなの？
38. 次のチャレンジ • テストコードを最適化して実行時間を短くしよう • テストの役割を整理して無駄なテストを減らそう
39. 04. テスト リアーキテクティング クライマックステスト テスト自動化 シフトレフト テスト リアーキテクティング 継続的テスト
40. テストを最適化する 実装 バックログ チケット チケット チケット 実装 リリース 実装 自動 テスト 自動 テスト 自動 テスト 手動テスト
41. テストケースのバランスを考える E2E Integration Unit E2E Integration Unit
42. テストの役割分担を考える テストレベル テストベース E2Eテスト ユーザーストーリー、ビジネス要求など 結合テスト APIや大きなコンポーネント ユニットテスト メソッドや関数などの小さなモジュール テストレベルごとに 見つけたいバグが違うんです なるほどね
43. E2Eテストしすぎを減らす 例: メールアドレスのバリデーション • ユニットテストでバリデーションルールをチェックする • 結合テストで正常系/異常系をテストする • E2Eテストで正常系をテストする
44. E2Eテストしすぎを減らす ✅ 正しいメールアドレス foo123@example.com ✅ エイリアスの入ったアドレス foo123+bar@example.com ❌ ローカルパートがない @example.com ❌ ドメインパートがない foo123 ❌ ピリオドが連続している foo123@example..com ❌ スペースが入っている foo 123@example.com 結合テスト ユニットテスト E2Eテスト
45. E2Eテスト以外の選択肢を学ぶ https://www.shoeisha.co.jp/book/detail/9784798178639 https://leanpub.com/everydayrailsrspec-jp
46. カバレッジの考え方 ユースケースカバレッジ: E2Eテストがカバーしているユースケースの割合 コードカバレッジ: 自動テスト全体でカバーしているコードの割合
47. 成果 • E2Eテストの量が減った • 自動テストの実行時間が短くなり、カバレッジは増えた 開発のテンポが良くなり、 リリース頻度を 週1回 → 週4回 に増やせた
48. 課題 ちょっとした修正だ。 QAも忙しそうだし、 手動テストせずに出そう 相談して ほしかった …… 障害
49. 課題 E2Eテスト書いたし バッチリだよね 障害 テストケースが 足りなかった……
50. 課題 一切のバグがない 完璧なプロダクトだ 利用性もテストし たい…… 使いにくい
51. 課題 • どんなテストが必要か、チームで議論する機会がない • 機能性しかテストしていない • 結局QAの手動テストはボトルネックのまま
52. 次のチャレンジ • 開発の「前」にテストについて議論しよう • 開発の「後」にもたくさんテストしよう • アンブロッキングなプロセスを作ろう
53. 05. 継続的テスト クライマックステスト テスト自動化 シフトレフト テスト リアーキテクティング 継続的テスト
54. 課題感が変わった • ✅ 一度にリリースする量が多い • ✅ 駆け込みマージが多い • ✅ 手戻りが多い • どんなテストが必要か、 チームで議論する機会がない • 機能性以外のテストがない • QAの手動テストが ボトルネックになっている
55. 課題感が変わった • どんなテストが必要か、 チームで議論する機会がない • 機能性以外のテストがない • QAの手動テストが ボトルネックになっている • 必要なテストについて議論する • 非機能性もテストする • QAの手動テストに頼らず 様々な方法を使う • QAの手動テストを挟まず どんどんデプロイする
56. 作る前からリリースの後までずっとテストする • 開発前: 仕様を理解する、仕様の抜け漏れを減らす • リリース前: 未知の不具合を探る • 段階的ロールアウト: ユーザーの反応を見る • GA (General Availability): 監視
57. いろんなところでテストする 実装 バックログ チケット チケット チケット 実装 デプロイ 実装 自動 テスト 自動 テスト 自動 テスト デプロイ デプロイ β GA
58. 開発の前 実装 バックログ チケット チケット チケット 実装 デプロイ 実装 自動 テスト 自動 テスト 自動 テスト デプロイ デプロイ β GA
59. 実例マッピングでビジネスルールを発見する https://speakerdeck.com/nihonbuson/example-mapping
60. リファインメントでテスト計画を立てる 💡 SMSでの多要素認証 E2Eテスト: • ユーザーは電話番号にSMSを送信できる。 • ユーザーが不正な電話番号を指定すると、エラーが表示される。 • 多要素認証を有効にしていないユーザーには、SMS認証画面が表示されない。 結合テスト: • Twilioのテスト用番号を使って正常系/異常系のテストをする。 探索的テスト: • 30分 3~5人 出来るだけ幅広いモバイルキャリア、OSを準備する • 目的: モバイルキャリアや端末に依存する問題を見つける。 ロールアウト: • 日本国内の1%のユーザーに対して有効にし、段階的に範囲を広げる。
61. リファインメントでテスト計画を立てる 💡 バグ修正: 検索結果表示数に 100 を指定しても表示数が変わらない E2Eテスト: • ユーザーは “50” を指定すると検索結果が50件になる。（既存） 結合テスト: • APIパラメーターとして 25/50/75/100 が渡されたとき、レスポンスに含まれるアイテムの 数はそれらに準じた数になる。 • 検索結果の数が指定された数より少ない場合は、すべての検索結果がレスポンスに含 まれる。 探索的テスト: 実施しない。
62. 開発からデプロイまで 実装 バックログ チケット チケット チケット 実装 デプロイ 実装 自動 テスト 自動 テスト 自動 テスト デプロイ デプロイ β GA
63. 継続的デプロイメント • 必要なテストはリファインメントで合意している = QAの署名済み（サインオフ） • 自動テストが全て通ったら そのソフトウェアはリリースできる (Production-Ready) • QAの判断を待たずに開発者がどんどんデプロイする • QAは開発者をブロックせずテストできる
64. フィーチャートグル • 特定のユーザー、ワークスペースにのみ有効にする • n%のユーザーに対して有効にする
65. 継続的デプロイメントとテスト Janet Gregory, Lisa Crispin, and Yuya Kazama. Agile Testing Condensed Japanese Edition (Kindle Location 869). Kindle Edition. 図形とイラストの追加は発表者によるもの。
66. ユーザーに使ってもらう 実装 バックログ チケット チケット チケット 実装 デプロイ 実装 自動 テスト 自動 テスト 自動 テスト デプロイ デプロイ β GA
67. ユーザーにテストしてもらう カナリアリリース / パブリックベータリリース • ユーザビリティーの改善 • 互換性など、事前に見つけにくい不具合の発見 ◦ 例: 特定のOS、特定の言語設定でのみ文字化けする ◦ 例: 特定のファイアーウォール設定下でのみ 画面の自動更新が不安定になる
68. リリース後 実装 バックログ チケット チケット チケット 実装 デプロイ 実装 自動 テスト 自動 テスト 自動 テスト デプロイ デプロイ β GA
69. 全ユーザーに使ってもらう GA (General Availability) リリース • 実稼働後中に起きたエラーの対処 • パフォーマンス監視 • UXモニタリング
70. エラーのチェック https://docs.sentry.io/product/issues/
71. Apdexスコア https://en.wikipedia.org/wiki/Apdex
72. Real User Monitoring https://newrelic.com/blog/best-practices/what-is-real-user-monitoring
73. 成果 • 今まで「手動テスト」で一括りにしていた活動が より明確になった • 開発サイクルをブロックせずに手動テストできた • 特定のフェーズに依存せず 様々なところで問題をキャッチできるようになった 週に4回 → 毎日数回 のデプロイの達成 🎉🎉🎉
74. まとめ
75. 今日話したこと • 手動テストに依存したQAテストフェーズから 開発サイクル全体を通した 継続的テスト に進化する 道筋の例を話しました • この例をたたき台にして 自分たちのチームでも話してみてください • 開発サイクルの要所要所で段階的にプロダクトを検証し リズミカルに品質を上げていきましょう クライマックステスト テスト自動化 シフトレフト テスト リアーキテクティング 継続的テスト
76. この通りにやれ、というわけではありません リファインメントを 試してみよう フロントエンドの テストコードを書いてみよう チームの形は様々 今日の話を叩き台にして できることを探してみよう
77. おまけ: 各種宣伝
78. Webアプリケーションの自動テスト Autify for Web 14日間無料トライアル受付中 https://autify.com/ja/trial アジャイル開発のための、 ソフトウェアテスト自動化プラットフォーム「Autify」
79. 一緒に働く仲間を募集しています https://autify.com/ja/careers
80. 一緒に働く仲間を募集しています https://autify.com/ja/careers
81. Enjoy Testing! 本講演をベースにした内容を Autify Blog にて公開予定です 👉 https://blog.autify.com/ja 最新の情報は で！ https://x.com/tsueeemura https://x.com/autifyjapan