Recomendados
Más contenido relacionado
Similar a 20190531 jasst19 tohoku
Similar a 20190531 jasst19 tohoku (20)
Más de Sadaaki Emura
Más de Sadaaki Emura (14)
20190531 jasst19 tohoku
- 1. テスト自動化プロセスの改善 May 31, 2019 (令和元年) Sadaaki Emura Leisure Product Dept. Rakuten, Inc. ～「明日のテストを楽にする」ための改善ビフォー・アフター～
- 3. 3 Who am I Name : Sadaaki Emura (nickname M) Join in Rakuten : 2007 Career : Embedded engineer (2000-2002) Web engineer (2002-2015) Product manager (2015-2016) QA (2016~) Role: Test Automation Engineer Lead Birthplace : Kanazawa-city Hobby: jog , climbing , horse racing
- 4. 4 LPD organization Product Manager Engineer QA (Leisure Product Department)
- 5. 5 Our team (QA) Scope : 5 services Members : 10 + off site Skill : QA specialist (almost not programmer) Mission : Quality Assurance by manual & automation test
- 7. 7 This presentation scope 1. チームの変遷で直面したテスト自動化の課題 2. 課題を改善する活動
- 8. 8 This presentation scope ■Scope ■ Not Scope • テスト自動化のプロセス • End to End のテスト自動化 • リリースサイクルが約2週間の派生開発 • テスト自動化のスクリプティング技術 • テスト自動化の環境構築
- 10. 10 Small team in 2016 ~ • Test Management • Test Analysist • Test Automator • Test Designer • Tester
- 11. 11 Big organization in 2018 ~ • Test Management • Test Analysist • Test Designer • Tester • Test Automation Lead • Automation Designer • scripter Manual Test team / each service Automation Test team ロールベースで作業分離
- 12. 12 What’s happened? 1. テスト自動化の質を維持するための工数増加 2. Manual teamから見て、自動化で何を品質担保しているか不明 3. プロジェクトスピードに自動化が追い付かない
- 13. 13 Issue 1st テスト自動化の質を維持するための工数増加 From Illust AC • 担当者のテスト経験が低く、自動化が目的になりがち • レビュー工数、作り直し工数が増加
- 14. 14 Issue 2nd Manual teamから見て、自動化で何を品質担保しているか不明 • 自動化がブラックボックス化 • テスト自動化で何を品質担保しているか不明
- 15. 15 Issue 3rd プロジェクトスピードに自動化が追い付かない From Freepik.com • 頻繁な既存機能のUI改修対応 • テストサイクルが短い案件が多い • 自動化で期間内に全部担保するのは困難
- 17. 17 How to improve? 1. テスト自動化の設計見直し 2. テスト自動化のレスポンシビリティ定義
- 18. 18 Improvement point 1st テスト自動化の設計見直し • Issue 1st テスト自動化の質を維持するための工数増加 • Issue 2nd Manual teamから見て、自動化で何を品質担保しているか不明 テスト自動化設計書のテンプレート作成
- 19. 19 Improvement point 1st テスト自動化設計書のテンプレート before 大分類 機能 フロー 概要 条件・パラメータ 投票 通常投票 ログイン → 投票ページ → 馬選択 → 確認 → 完了 買い目、買い方、馬をえらん で投票する機能 式別（単勝、～三連単） 方式（通常、～フォー メーション） ： オッズ投票 オッズをソートして、そこか ら欲しい馬券を選んで投票す る機能 ： 例 楽天競馬
- 20. 20 Improvement point 1st 機能 テスト観点 テスト目的 テスト前提 条件・パラ メータ CI条件 自動化の処理概要 自動化しない こと 通常投票 • 正常購入処理 • 購入方法の網羅 • 馬券を正しく購入 できること • 競馬会員ユーザ • 十分な残高 式別（単勝、～ 三連単） 方式（通常、～ フォーメーショ ン）： 購入回数上限 1. ログイン 2. お金の入金 3. 買目、馬を選ぶ 4. 購入する 5. 照会で確認 買った馬券の妥当 性は確認しない 一定条件で購入不可 • 競馬会員以外 • 残高不足 • 発売締切り オッズ投票 1. ログイン 2. お金の入金 3. オッズから馬券を選ぶ 4. 購入する 5. 照会で確認 ： • 会員登録 • 正常に登録 • 一日一回 1. 楽天ID作成 2. 会員申し込み テスト自動化設計書のテンプレート after
- 21. 21 Improvement point 1st 機能 テスト観点 テスト目的 テスト前提 条件・パラ メータ CI条件 自動化の処理概要 自動化しない こと 通常投票 • 正常購入処理 • 購入方法の網羅 • 馬券を正しく購入 できること • 競馬会員ユーザ • 十分な残高 式別（単勝、～ 三連単） 方式（通常、～ フォーメーショ ン）： 購入回数上限 1. ログイン 2. お金の入金 3. 買目、馬を選ぶ 4. 購入する 5. 照会で確認 買った馬券の妥当 性は確認しない 一定条件で購入不可 • 競馬会員以外 • 残高不足 • 発売締切り オッズ投票 1. ログイン 2. お金の入金 3. オッズから馬券を選ぶ 4. 購入する 5. 照会で確認 ： • 会員登録 • 正常に登録 • 一日一回 1. 楽天ID作成 2. 会員申し込み テスト自動化設計書のテンプレート after • 自動化処理内容の可視化 • テスト観点を明示
- 22. 22 Improvement point 1st 機能 テスト観点 テスト目的 テスト前提 条件・パラ メータ CI条件 自動化の処理概要 自動化しない こと 通常投票 • 正常購入処理 • 購入方法の網羅 • 馬券を正しく購入 できること • 競馬会員ユーザ • 十分な残高 式別（単勝、～ 三連単） 方式（通常、～ フォーメーショ ン）： 購入回数上限 1. ログイン 2. お金の入金 3. 買目、馬を選ぶ 4. 購入する 5. 照会で確認 買った馬券の妥当 性は確認しない 一定条件で購入不可 • 競馬会員以外 • 残高不足 • 発売締切り オッズ投票 1. ログイン 2. お金の入金 3. オッズから馬券を選ぶ 4. 購入する 5. 照会で確認 ： • 会員登録 • 正常に登録 • 一日一回 1. 楽天ID作成 2. 会員申し込み テスト自動化設計書のテンプレート after • 実施条件の明示 • 網羅性の可視化
- 23. 23 Improvement point 1st 機能 テスト観点 テスト目的 テスト前提 条件・パラ メータ CI条件 自動化の処理概要 自動化しない こと 通常投票 • 正常購入処理 • 購入方法の網羅 • 馬券を正しく購入 できること • 競馬会員ユーザ • 十分な残高 式別（単勝、～ 三連単） 方式（通常、～ フォーメーショ ン）： 購入回数上限 1. ログイン 2. お金の入金 3. 買目、馬を選ぶ 4. 購入する 5. 照会で確認 買った馬券の妥当 性は確認しない 一定条件で購入不可 • 競馬会員以外 • 残高不足 • 発売締切り オッズ投票 1. ログイン 2. お金の入金 3. オッズから馬券を選ぶ 4. 購入する 5. 照会で確認 ： • 会員登録 • 正常に登録 • 一日一回 1. 楽天ID作成 2. 会員申し込み テスト自動化設計書のテンプレート after • 手動テストの必要性明確化
- 24. 24 Improvement point 1st 機能 テスト観点 テスト目的 テスト前提 条件・パラ メータ CI条件 自動化の処理概要 自動化しない こと 通常投票 • 正常購入処理 • 購入方法の網羅 • 馬券を正しく購入 できること • 競馬会員ユーザ • 十分な残高 式別（単勝、～ 三連単） 方式（通常、～ フォーメーショ ン）： 購入回数上限 1. ログイン 2. お金の入金 3. 買目、馬を選ぶ 4. 購入する 5. 照会で確認 買った馬券の妥当 性は確認しない 一定条件で購入不可 • 競馬会員以外 • 残高不足 • 発売締切り オッズ投票 1. ログイン 2. お金の入金 3. オッズから馬券を選ぶ 4. 購入する 5. 照会で確認 ： • 会員登録 • 正常に登録 • 一日一回 1. 楽天ID作成 2. 会員申し込み テスト自動化設計書のテンプレート after • CI運用に考慮する点記述
- 25. 25 Improvement point 1st テスト自動化設計書のテンプレートの効果 • テスト自動化がカバーしている箇所の可視化 • テスト目的、運用に必要な事を明確化し、自動化実装漏れ低減 • レビュー、実装等の自動化工数の削減
- 26. 26 Improvement point 1st 自動化のスクリプト時間の削減効果 Before After テスト自動化の設計 5 18 スクリプティング 120 120 スクリプティング レビュー 58 × 3 25 × 3 スクリプティング 修正 50 20 合計 599 509 ※単位 minute ※１機能テスト（約５分処理）の平均
- 27. 27 Improvement point 2nd テスト自動化のレスポンシビリティ定義 • Issue 3rd プロジェクトスピードに自動化が追い付かない プロジェクトでマニュアルと自動化テストのレスポンシビリティを定義 ※小規模のプロジェクトに適用
- 28. 28 Improvement point 2nd マニュアル、自動化のレスポンシビリティ 既存機能 新規機能 マニュアルテスト 自動化テスト ◎ ◎ △ 〇
- 29. 29 Improvement point 2nd 自動化の開発プラン t Project A Project B 新規機能 既存機能 改修 改修 新規機能A開発 新規機能B開発 App release App releaseTest ready Test ready
- 30. 30 Improvement point 2nd テスト自動化のレスポンシビリティ定義による効果 • 頻繁な既存機能の改修に対してレグレッションテスト追従 • 短いテストサイクルに対して追従
- 32. 32 Conclusion 1. テスト自動化の質を維持するための工数増加 2. Manual teamから見て、自動化で何を品質担保しているか不明 3. プロジェクトスピードに自動化が追い付かない ・Issue
- 33. 33 Conclusion 1. テスト自動化の質の向上、工数削減 2. Manual teamから見て、テスト自動化が明確化 3. 短期間プロジェクトに自動化が追従 ・Result 1. テスト自動化の設計見直し 2. テスト自動化のレスポンシビリティ定義 ・Improvement
Notas del editor
- これまでのキャリア 最初、組み込み系のソフトウェアエンジニア ２年間 その後、WEBエンジニア １３年間 次にプロダクトマネージャの経験を経る 2016年、いまのSQA部署の構築から携わり、テスト自動化を合わせて構築しました（３年目）
- 次に、組織の話をさせてください ・５つのサービスを持っている ・ロールでチームが分かれている
- QAの組織は ・ １０名 + offsite (増減します) ・ QAのスペシャリスト集団 ただ、ほとんどはエンジニア経験なし ・マニュアル、自動化で品質を担保する
- ３つのステップでおはなし 1. ２０１６年QA組織立ち上げ、自動化の取り組みを行う 徐々にメンバーが増え、それによって直面した課題 2. それに対して取り組んできた改善活動
- ２０１６年、QA構築当初の体制です ひとりが、ISTQBでいうTMとTA、およびテスト自動化を担当 ・テスト設計書のレビュー ・テスト自動化の設計 ・テスト自動化の構築、運用
- マニュアルと自動化のチームにわかれました ・マニュアル側は、自動化に関してのスキルがない ・自動化側は、プログラマーが主になり、かつドメインナレッジが少ない
- 自動化チームが拡大化したことで ・テストエンジニア経験の低いプログラマが増えてきた ・自動化のテストの質が低下し、品質担保が困難になってきた
- マニュアルと自動化がチーム分けされたことにより マニュアル側から都度、自動化のメンバーにどこを自動化している？ 今回のプロジェクトで自動化どこカバーしている？ って質問、応答のやりとりが多々発生
- 重要な機能でUIの変更がよく発生する。 → 自動化に向かないとはいえ対応が求められる １－２週間のテストサイクル案件が多く、それに自動化が追従困難
- これまで自動化の設計書を各担当者にまかせていた 主に、処理フローと自動化でよく使われるデータドリブンに必要な情報、条件、パラメータを記述 テストする観点が含まれてませんでした マニュアルチームから見ても、品質担保が不明
- これをこのように自動化のテスト設計書のテンプレートを作成しました
- 具体的なテスト手順とそれにおいてのテスト観点 自動化でどういったことをvalidateするか マニュアルチームへなにをやってるかを可視化 自動化担当には具体的なSTEPを記載することでテスト観点を実装にもれないようにさせた
- テストにあたっての前提条件 自動化で効果のある、DDのための要素、条件・パラメータ
- 自動化は銀の弾丸ではない マニュアルチームから見て、注意しないといけないことを記載
- 自動化は、 ・毎日実行させることが求めらる ・失敗した時、再実行可能が求められる これを満たすための制約をクリアにする ⇒実装時にこれを考慮しないと意外と作り直しが発生する
- 1 script 増えた時間 テスト設計には時間が増える レビュー ２人でレビューしている前提 before やり直しのレビューも含んでいる（自動化の設計自体を） after １回のレビューでおわるケースがおおい
- 既存機能 これまでに存在している機能 テスト自動化でリグレッションテストで基本カバーしている プロジェクトによって、リグレッションテストに影響あり 新規機能 これまでに存在しない機能 テスト自動化を新規に作る必要あり UIは十分なテストしないと安定しない場合あり
- 新規機能に関して、マニュアルテストで品質を守る 既存機能に関して、自動化テストで品質を守る