自動化の罠 - 自動化してはいけないテスト

近年、多くの企業が手動テストケースを一斉に自動化する取り組みを進めています。この背景には、短いリリースサイクルと効率的なテスト実行の要求があります。しかし、すべてのテストケースを盲目的に自動化することは、肥大化したエンドツーエンド（E2E）テストを生み出す危険性があります。これらのテストは、保守が難しく、しばしば多くのリソースを消費します。このプレゼンテーションでは、自動化の過度な取り組みが引き起こす問題点と、保守性の高い自動テストの設計方法について解説します。適切な自動化のバランスを見つけるための実践的なアドバイスも提供いたします。

Transcript

1. 自動化の罠 自動化してはいけないテスト By Chris Ding (クリス)
2. 自己紹介 • 中国生まれ、ニュージーランド育ち、 2022年3月に日本に引っ越し、現在 札幌在住 • 主にCloudNativeアプリケーションの 品質管理 • TierIVという自動運転会社で、Web・Cloud 側（Web.Auto) のQAチームリードをしています
3. Business : Autonomous driving system / platform development Established : Dec 2015 # of employees : Approx. 300 Location : Japan - Tokyo, Nagoya USA - Palo Alto China - Shanghai Funding : Approx. US$230million Shareholders : 3
4. Fleet Management/Remote Operation Web.Auto Overview Build Test Deploy Collect Data Source AD SW Integration Review Map/Scenario Data Search Maps, Scenarios OTA releases Vehicle data Dataset, ML Models CI/CD Evaluation Testing この成果は、国立研究開発法人新エネルギー・産業技術総合開発機構（ＮＥＤＯ）の助成事業 (JPNP21027)の結果得られたものです。
5. 目次 • テスト自動化の罠 - ケーススタディ • 自動化してはいけないテスト ◦ その１、存在しないものを自動化しない ◦ その２、余計なテストステップを自動化しない ◦ その３、コスパの悪いテストを自動化しない • Q&A
6. テスト自動化　ー　ケーススタディ • Cloud Native Application • 頻繁的にリリース • バグがちょこちょこ出てくる
7. テスト自動化　ー　ケーススタディ • QAチームを採用 • QAチームがマニュアルテストを行う 🧪
8. テスト自動化　ー　ケーススタディ • プロダクトとインフラがだんだん複雑になってくる • QAリソースが足りなくなる • ふんわりしたイメージで、「自動化した方がいいじゃない？」と考え始める 🤔
9. • 自動化ツールを調査、自動化始める • 最初のいくつかの自動化テストが完成、行ける！ テスト自動化　ー　ケーススタディ
10. テスト自動化　ー　ケーススタディ • 全部自動化しよう！
11. だが。。。
12. • ある日、テストが不明の理由で失敗し始める（Flaky Test） テスト自動化　ー　ケーススタディ
13. 自動化しながら、既存テストを 修正〜
14. • いつの間にか不安定のテストが手に負えない 状況になった • 一つの問題が解決できたら、まだいくつ の問題が出てくる テスト自動化　ー　ケーススタディ
15. • テストが訳わからない原因で失敗 ◦ テスト環境？ ◦ テストデータ？ ◦ テストツール？ ◦ テスト実装？ ◦ 仕様変更？ • 失敗しているテストの調査と修正が手動 テストより時間がかかるようになった • 一つSprintの失敗を直そうとしたら、既に次のSprintになっちゃった テスト自動化　ー　ケーススタディ
16. • いつも失敗するテストをDisable/削除 • 結局手動で不安定なテストを実行 テスト自動化　ー　ケーススタディ
17. • Cloud Native だからこそ ◦ 頻繁なリリース ◦ 頻繁なテスト実行 ◦ テスト失敗の調査時間が短い テスト自動化　ー　ケーススタディ
18. 自動化のワナを避ける方法?
19. • 安定したテスト自動化ツールを使う？ • きれいなテストデータとテスト環境を保つ？ • テスト自動化のBest Practiceを参照しながらテストを書く？ 自動化のワナを避ける方法は?
20. • 安定したテスト自動化ツールを使う？ • きれいなテストデータとテスト環境を保つ？ • テスト自動化のBest Practiceを参照しながらテストを書く？ 全部大事ですが、テストを実装する前に、そもそも何を自動化すべきなのか？ テスト自動化対象を決めるのが大事！ 自動化のワナを避ける方法は?
21. テストを適当に書いてはいけない
22. その１、存在しないものを自動化しない
23. • よくあるパターン： ◦ 手動テストケースを書かずに、ふんわりした感じでテストを書き始める その１、存在しないものを自動化しない ☁
24. • よくあるパターン： ◦ 手動テストケースを書かずに、ふんわりした感じでテストを書き始める • 手動テストケース = 自然言語で書かれているテストケース その１、存在しないものを自動化しない ☁
25. • 問題点 ◦ カバレッジの洞察不足 その１、存在しないものを自動化しない
26. • 問題点 ◦ カバレッジの洞察不足 ◦ 故障理解が難しい その１、存在しないものを自動化しない
27. • 問題点 ◦ カバレッジの洞察不足 ◦ 故障理解が難しい ◦ テストを書いた人以外の人はテストが理解しにくい その１、存在しないものを自動化しない
28. • 問題点 ◦ カバレッジの洞察不足 ◦ 故障理解が難しい ◦ テストを書いた人以外の人はテストが理解しにくい ◦ 省略できるテストステップが分からない その１、存在しないものを自動化しない
29. • 問題点 ◦ カバレッジの洞察不足 ◦ 故障理解が難しい ◦ テストを書いた人以外の人はテストが理解しにくい ◦ 省略できるテストステップが分からない ◦ 等 その１、存在しないものを自動化しない
30. • 面倒くさい！ その１、存在しないものを自動化しない
31. • 面倒くさい！ ◦ E2Eテストでを書くべきなのか？ その１、存在しないものを自動化しない
32. • 面倒くさい！ ◦ E2Eテストを書くべきなのか？ ◦ 優先度低いテストを実装しようとしていないか、テストが雑すぎる？ ▪ 後でもっとお話します その１、存在しないものを自動化しない
33. 自動テストは常にドキュメント化された テストに基づいて書く
34. その２ 、余計なテストステップを自動 化しない
35. ログインを検証したい： 「ログイン」テスト： 1. UsernameとPasswordフィールドを入力 2. Confirmボタンを押す 3. Homepageに遷移することを確認 その２、余計なテストステップを自動化しない
36. 自動化テストコード： 「ログイン」テスト： 1. UsernameとPasswordフィールドを入力 2. Placeholderテキストが正しいを確認 3. Confirmボタンを押す 4. Homepageに遷移することを確認 その２、余計なテストステップを自動化しない
37. 別にいいんじゃない🤷
38. 想像してください： • Placeholderテキストが変化され、テストが失敗 • テスト通知は： 🚨🚨🚨ユーザーがログインできない 🚨🚨🚨 その２、余計なテストステップを自動化しない (||ﾟДﾟ)」ひぃぃぃ〜
39. • テスト失敗する時にFalse Alarmが出る • テスト内容が分からなくなる • 実行時間が長くなる • メンテしにくい その２、余計なテストステップを自動化しない
40. 決まったテストケースから離れない
41. その３、コスパの悪いテストを自動化し ない
42. • 「全てのテストを自動化したら楽になる！」 その３、コスパの悪いテストを自動化しない
43. • 「全てのテストを自動化したら楽になる！」 • テストを書こうと思えば、無限に書ける ◦ 優先度が低いテスト ◦ 再現手順が複雑なテスト ◦ 新機能 • 自動化したテストはただではない ◦ 実装コスト ◦ 実行コスト ◦ 失敗調査コスト ◦ メインテナンスコスト その３、コスパの悪いテストを自動化しない
44. 各テストのコスパを考えながら、 自動化対象を決めましょう
45. 自動化対象 ビジネスインパクト 実装コスト + メンテコスト ＝ 自動テストコスパ
46. • ビジネスインパクトの大きいテストケース 自動化対象 - ビジネスインパクト
47. • ビジネスインパクトの大きいテストケース ◦ 手順が簡単、再現しやすい、影響されるユーザーが多い 自動化対象 - ビジネスインパクト
48. • ビジネスインパクトの大きいテストケース ◦ 手順が簡単、再現しやすい、影響されるユーザーが多い ◦ 不具合が出たらビジネスに対する損が大きい 自動化対象 - ビジネスインパクト 💸
49. • ビジネスインパクトの大きいテストケース ◦ 手順が簡単、再現しやすい、影響されるユーザーが多い ◦ 不具合が出たらビジネスに対する損が大きい ◦ 不具合頻発の機能 自動化対象 - ビジネスインパクト ⚠
50. ビジネス側と相談して 決めましょう
51. • 不安定、メインテナンスコストが高いテストの実装は要注意！ 自動化対象 - 実装/メインテナンスコスト
52. • 不安定、メインテナンスコストが高いテストの実装は要注意！ ◦ Canvas上の操作 自動化対象 - 実装/メインテナンスコスト
53. • 不安定、メインテナンスコストが高いテストの実装は要注意！ ◦ Canvas上の操作 ◦ 新規機能 自動化対象 - 実装/メインテナンスコスト 🧪
54. • 不安定、メインテナンスコストが高いテストの実装は要注意！ ◦ Canvas上の操作 ◦ 新規機能 ◦ 色/レイアウト Visual系のテスト 自動化対象 - 実装/メインテナンスコスト
55. • 不安定、メインテナンスコストが高いテストの実装は要注意！ ◦ Canvas上の操作 ◦ 新規機能 ◦ 色/レイアウト Visual系のテスト ◦ 手順が複雑のテスト 自動化対象 - 実装/メインテナンスコスト
56. • 不安定、メインテナンスコストが高いテストの実装は要注意！ ◦ Canvas上の操作 ◦ 新規機能 ◦ 色/レイアウト Visual系のテスト ◦ 手順が複雑のテスト ◦ 等 自動化対象 - 実装/メインテナンスコスト
57. • 不安定、メインテナンスコストが高いテストの実装は要注意！ ◦ Canvas上の操作 ◦ 新規機能 ◦ 色/レイアウト Visual系のテスト ◦ 手順が複雑なテスト ◦ 等 • 既存のテストが不安定になったのもコストが高くなる！ 自動化対象 - 実装/メインテナンスコスト
58. • 安全関係のテストは別枠で優先度とリターンを考えます ◦ 車両走行に影響するテスト ◦ 等 自動化対象 - 安全関係
59. 自動化対象 自動化すべき🟢 マニュアル・探索的テスト🟡 慎重に自動化する🟡 自動化しない🔴 Business Impact 大きい Business Impact 小さい Cost 低い Cost 高い
60. • Unitテスト • Integrationテスト • 性能テスト • 等。。。 自動化対象 - E2Eテストだけではない
61. • ひたすら全てを自動化しないのが第一歩 • テストツール、実装、メンテナンス、テストプロセス、等も重要 自動化対象 - 追記
62. - 自動テストが大事ですが、盲目に自動化してはいけない - 特に頻繁的なリリースのあるようなCloudNativeアプリケーション - 自動化してはいけないテスト - 存在しないテストを自動化してはいけない - 余計なテストステップを自動化してはいけない - コスパの悪いテストを自動化してはいけない - ビジネスインパクトが低いテスト - コストが高いテスト まとめ
63. ビジネスに価値を提供できる自動化テ ストを書きましょう！
64. Questions （時間があれば）