More Related Content
Similar to 20220527_JaSST'22 Tohoku
Similar to 20220527_JaSST'22 Tohoku (20)
More from Sadaaki Emura
More from Sadaaki Emura (14)
20220527_JaSST'22 Tohoku
- 1. テスト自動化導入後の課題の改善ビフォーアフター May 27th , 2022 Emura Sadaaki Leisure Product Dept. Rakuten Group, Inc. ～テスト自動化は導入後が大変～
- 2. 2 Target user & Goal 対象 ： これからテスト自動化を取り組む人 テスト自動化の運用に苦労している人 ゴール ： 長期にわたってテスト自動化を効率よく活用できる
- 3. 3 Out of scope • テスト自動化の実装方法
- 4. 4 Organization Developer group QA section Manual test group Test automation group Me : 8 services Product manager engineer https://www.irasutoya.com/
- 5. 5 Current test automation system DC center IaaS Remote monitor dashboard alert IIS Jenkins server
- 6. 6 Test automation usage situation • テスト自動化を毎日実行 • 各サービスは２～３週間の周期でアップデートされる • 各サービスに対して、数百のテストscript、複数のJenkinsで構成される
- 7. 7 Test automation motivation graph for 6 years Automation motivation Time 2016 2022 Process issue Script issue Operation issue Phase-1 Phase-2 Phase-3
- 9. 9 Agenda 1. Phase-1. process issue & solution 2. Phase-2. script issue & solution 3. Phase-3. operation issue & solution 4. Summary
- 10. 10 Agenda 1. Phase-1. process issue & solution 2. Phase-2. script issue & solution 3. Phase-3. operation issue & solution 4. Summary
- 11. 11 Small team is efficient One team manual automation • 密なコミュニケーション • １サービスに集中してScripting • テスト自動化のカバレッジは少ない https://www.irasutoya.com/
- 12. 12 Team size is expanding automation manual manual manual manual team automation team • 組織が大きくなる • 複数サービス並行してScripting • テスト自動化のカバレッジが大きくなる https://www.irasutoya.com/
- 13. 13 Team size is expanding automation manual manual manual manual team automation team • お互いのテストが不明確 • テスト自動化が仕様変更で失敗増える https://www.irasutoya.com/
- 15. 15 How to resolve 1st issue • お互いのテストが不明確 • テスト自動化が仕様変更で失敗増える ⇒ テストの責任範囲・役割を明確にする ⇒ 新規機能、既存機能の仕様変更の明確化と、自動化の優先順位
- 16. 16 Test automation responsibility ① ② Product New Project scope Regression Cover by manual test Cover by test automation Manual Automation Projectの影響範囲 Projectの影響外の既存機能 ＋ Projectにより修正が加わる既存機能 1) Regression affected by new project (spec change) 2) New function
- 17. 17 How to proceed (short term project) t Project A Project B ②新規機能 ① 既存機能 modify modify Create new Create new App release App release Test ready Test ready Test will be failed Test will be failed 1~2 weeks regression New function If have a time
- 18. 18 1st phase solution output • マニュアルチームからの信頼、効率的な品質保証 • 少人数でテスト自動化の責務を果たす
- 19. 19 Agenda 1. Phase-1. process issue & solution 2. Phase-2. script issue & solution 3. Phase-3. operation issue & solution 4. Summary
- 20. 20 Jenkins say green! But … • 仕様変更にテストが追従している！ • テスト成功が継続し、静観してた！ • 日に日にビルドキューが溜まる！？
- 21. 21 Regression speed 0 50 100 150 200 0 5 10 15 20 Time [second] 実行回数 [sec] 最初は、実行時間は短かった いつのまにか、時間がかかっている 全般的にテストが終わらない 成功が続く限り、気にしない
- 22. 22 Performance issue route cause • テストデータ肥大化 • Pipelineが肥大化、テストの高依存化 • いけてないテスト自動化の実装 https://www.irasutoya.com/
- 23. 23 Performance issue route cause • 問題が起きていることを気づかないのが問題
- 25. 25 How to resolve 2nd issue テスト実行結果の可視化と、問題可能性の早期検出の仕組化
- 26. 26 Store all test automation history • テスト実行時間、処理時間 • テスト結果 • Jenkinsステータス（処理待ちキュー） 全ての情報をDBに保存
- 27. 27 Pick up possible problem スクリプト単位の 実行時間の推移の可視化 問題のテストの絞り込み 問題のテストの修正 sample
- 28. 28 Pick up possible problem Jenkins単位の 実行時間の推移の可視化 問題のJenkinsの絞り込み 問題のJenkinsの設定見直し sample [min]
- 29. 29 2nd phase solution output • テスト自動化パフォーマンス問題の早期発見 • 安定したテスト自動化の結果提供
- 30. 30 Agenda 1. Phase-1. process issue & solution 2. Phase-2. script issue & solution 3. Phase-3. operation issue & solution 4. Summary
- 31. 31 Many tests are failed • テストは失敗する • 原因調査、対応（運用）が必要 • 運用工数はスクリプト数に比例する
- 32. 32 Additional task to investigate test result! manual automation 1. テストする 2. バグを見つける 3. バグチケットを上げる 1. Jenkins が失敗する 2. 失敗レポートで原因を分析する 3. Local で実行してみる 4. バグチケットを上げる V.S. Issueが起きたと きの対処に時間 がかかる！
- 33. 33 Summary failed reason category 0.5 4.9 20.4 74.1 Application Bug Test automation Bug Environment issue Temporary unstable 1. Application bug 2. Test automation script bug 3. Environment issue 4. Temporary unstable ※2020/1 ~ 2020/10 summary Unit = percentage Reason category Reason ratio JaSST’21 Tokyo 「Test Automation Improvement by Machine Learning」
- 34. 34 Temporary unstable example case Website is busy 一時的に、テスト環境が不安定 この作業は非生産性！かつ、多い 再実行すると、たいてい復旧する
- 36. 36 How to resolve 3rd issue 非生産性タスクの自動化により、運用工数削減
- 37. 37 Improve operation idea “Auto healing system” ・・・ Jenkins server ① ② Auto healing system Training data ③ 1. テスト失敗の原因をtraining dataとして使う 2. テスト失敗時、機械学習により原因を予測する 3. temporary unstable issueのとき、自動再実行する JaSST’21 Tokyo 「Test Automation Improvement by Machine Learning」 一部のテスト失敗 を自動に再実施す る • Error text • screenshot
- 38. 38 Auto healing system brings … 1. Application bug 2. Test automation script bug 3. Environment issue 4. Temporary unstable bug report、bug fix後にテスト再実行 自動化スクリプトの修正とテスト再実行 環境復旧とテスト再実行 自動でテスト再実行 Category Operation 非生産性作業は自動で処理される！
- 39. 39 Auto healing system brings … 0% 20% 40% 60% 80% 100% Jan-20 Feb-20 Mar-20 Apr-20 May-20 Jun-20 Jul-20 auto healing manual operation 78% Ratio of way to fix issue Example. 1 operation = 2 mins Daily operation = 300 Monthly operation = 112 hours In July 78% failed jobs is healed in auto Reduction = 88 hours All manual operation human cost Auto healing human cost
- 40. 40 3rd phase solution output • テスト自動化運用の効率化 • もっと知的な作業への集中
- 41. 41 Agenda 1. Phase-1. process issue & solution 2. Phase-2. script issue & solution 3. Phase-3. operation issue & solution 4.Summary
- 42. 42 Process Issue 組織が大きくなると、テスト自動化の役割がさまよう Script Issue テスト自動化が成功し続けても、自動化の内部品質に課題あり Operation Issue テスト自動化の運用工数が、スクリプト数に比例する
- 43. 43 Process Issue solution テスト自動化の責務・役割の明確化 Script Issue solution テスト実行結果の可視化と、問題可能性の早期検出の仕組化 Operation Issue solution 非生産性タスクの自動化により、運用工数削減
Editor's Notes
- 今回のお話ですが、 今回のJaSST Tohokuのテーマは「テスト自動化その前に」です。 テーマの通り、テスト自動化導入時に、その前段階が重要です。 ただ、それだけではなく、導入後の長期にわたっての運用が重要だと思います。 そこで、今回のプレゼンでは、 テスト自動化の取り組み前後、 … に対して
- 尚、本プレゼンでは、テスト自動化の実装方法に関しては触れません。
- まず、わたしの組織の説明 各サービスを担当する開発が８つあります。 QA sectionがあり、これらのサービスの品質担保をする そのQAのなかでも、マニュアルと自動化のグループに分かれいます。
- 今現在のテスト自動化プラットフォームです Ranorexをmainとして、PC WEB, SmartPhone WEB, mobile APP のE2Eテスト自動化を行っています。 また、適切な運用をおこなうための、テスト自動化のメトリックス可視化のためのdashboard等を構築しています
- では、そのテスト自動化の利用形態はこのようになっております。 ・毎日実行 → 開発への早いフィードバック ・２－３週間でリリース → 頻繁に仕様変更が行われます ・
- 自分がこのQA部署を立ち上げた2016年は、小さい部署でした。 ゴルフのサービスのQAを行い、自分ひとりでテスト自動化の構築を行った。 ・マニュアル、自動化双方密にコミュニケーション ・自分ひとりで1つのサービスに集中して実装 ・テスト自動化の対象は、ゴルフの予約といった超重要な機能に絞ってカバーしていた
- 時を経て、QA部署が成長し ・組織が徐々におおきくなります → 人が増え、対象サービスが増え、マニュアル・自動化のチームが分離 ・サービスがふえる → 自動化も追従する ・自動化エンジニアが増える → 自動化でのカバレッジが大きくなる ・
- しかし、この組織がおおきくなるにつれて問題が起きてきます。 ・人が多くなり、チーム分離することでマニュアル、自動化で連携が薄れてくる → お互いにテストが不明確になってきます。 マニュアルからすると「自動化なにやってんだ」 ・自動化のカバレッジが広くなるということは、サービスのリリースに伴う仕様変更が影響しやすくなる → 失敗が吹てくる
- As I said during project Regression include affected area by project should be supported That’s why we modify test automation script if regression script is affected during project But new function is low priority in this project. Depending on resource , we will cover it for future project
- このグラフは、。。。 ひとつのテストスクリプトのパフォーマンスです
- テスト自動化の8原則 「テスト結果分析という新たなタスクが生まれる」
- JaSST’21 Tokyo 「Test Automation Improvement by Machine Learning」で発表したときの資料
- Final 4th type “temporary unstable” This situation is test environment does not work “in short period”. For example. Network connection difficulty . Application cause timeout. Web server cause busy In this case, fixing solution is very simple only “retry test automation “ Although we take much time to investigate this type issue, final operation is “RETRY” So this temporary unstable issue is very non productive and take much time.
- 詳細は割愛しますが、
- Auto healing do “Prediction” and “RED AREA” - “Retry test automation” in auto.
- This is actual output This graph mean 100 % is all failed test automation. RED is fixed by manual . BLUE is fixed by auto healing, this fix operation is ZERO human operation Pick up July case. For example,monthly operation take about 112 hours. 78% is fixed by auto healing. So ,about 88 hours human cost is reduct! It’s very huge outcome.