Rakuten Commerce QA Night#1
4/24 (水) 楽天クリムゾンハウスにてQA の meetupが行われました
今回は、楽天だけがプレゼンターのQA 勉強会として初めての開催でした
最終的に来場者は約８０名。
コンテンツは以下の通り
- 自分からは”Automation testing for Leisure Product”と題して、テスト自動化をチームにどのように導入したか
- TravelのClint, Sharon２名からは”Test Automation at Rakuten Travel”と題して、テストデータ等の作成自動化の仕組みの話
- Service and Project Management のMayurからは "Rakuten QA group and Automation team"と題して、テスト自動化の仕組みの話
- Nakamuraからは"Rakuten QA Group Introduction & Best Practices"と題して、多くのサービスのQAをする上での運営に関する話
以下、自分のプレゼンの資料になります
お話したこと
Engineerの時代に構築したテスト自動化の失敗
2013年ころ 以下の方針で自動化を取り組んでいた
- 目指せカバレッジ〇〇％！
- 流行りの技術でとにかく動かそう
この方針で進めたが故に、結果として以下のようになった
- 自動化設計の軽視により、テスト目的のないものになった
- 保守・運用設計の軽視により、活用されない負債が増えた
このため、せっかく作った自動化はお蔵入りになった
QAの時代でテスト自動化をどのように導入したか
Engineerで失敗したことを教材に、QAにキャリアチェンジしたときに、自動化を改めて導入するとき、以下を主に気を付けた
- テスト自動化設計でスコープ、目的を明確化
- テスト自動化の保守・運用設計
テスト自動化設計でスコープ、目的を明確化
- 何を自動化でテストするのか、テスト目的、観点を明確にする
- CIに使うことを想定として、テストに制約がかかることを明確にする
- 自動化でテストしないことを明確にする
テスト自動化の保守・運用設計
- ツール、コード、実行環境を保守できるツール選定
- 自動化で、毎日チェック、早く問題検知、解消確認できる運用設計
それによって以下の成果が得られました
- 自動化できるところを正しく品質担保
- 長期的に最大限の活用
今回、聴講しに来ていただいた方ありがとうございます。
次回は5月 Quesに登壇予定なので、ぜひ遊びに来てください
一部、英語になります