Successfully reported this slideshow.
Your SlideShare is downloading. ×

20191029 automation struggle

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 17 Ad

20191029 automation struggle

Download to read offline

talk about my story when we start automation testing in our team.
we met many struggle to build automation testing environment

talk about my story when we start automation testing in our team.
we met many struggle to build automation testing environment

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to 20191029 automation struggle (20)

Advertisement
Advertisement

Recently uploaded (20)

20191029 automation struggle

  1. 1. Automation struggle Oct 29, 2019 Sadaaki Emura Leisure Product. Dept. Rakuten, Inc.
  2. 2. 2 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
  3. 3. 3 Organization Developer group QA group Manual test team automation test team @Illust AC ココ の人 :
  4. 4. 4 Organization
  5. 5. 5 Premise for today talk 前提 • E2E test自動化 • 開発とは独立したQA組織 • マニュアルテストとテスト自動化部隊 話さないこと • 技術的なこと • Best practice
  6. 6. 6 Story 1. 自動化を立ち上げするときの闇 2. 自動化が立ち上がった時の闇 3. 自動化が安定してきたときの闇 4. 現在の闇 5. 光はあるのか?
  7. 7. 7 1. 自動化を立ち上げするときの闇 課題 周りの理解者がいない • POCを実施 • 自動化導入のQCD効果説明 • マニュアルテストで十分 • コストイメージ 対策 @FREEIMAGES
  8. 8. 8 1. 自動化を立ち上げするときの闇 @photoAC 課題 周りに技術者がいない • 今の組織でできる仕組み検討 • QAプロセスの再定義 • アプリケーションエンジニア不足 • マニュアルとの使い分け不明 対策
  9. 9. 9 2. 自動化が立ち上がった時の闇 • テスト目的を明確化 • テスト自動化の基準設定 • 作業改善の自動化も検討 @photoAC 課題 自動化の目的がバラバラ • テストになっていない • カバレッジが目標 対策
  10. 10. 10 2. 自動化が立ち上がった時の闇 @FREEIMAGES • 自動化の仕組みの説明 • QCD含めた得手不得手を説明 課題 自動化は銀の弾丸と思われる • 自動化が全てをやってくれる • マニュアルテスト不要論 対策
  11. 11. 11 3. 自動化が安定してきたときの闇 @FREEIMAGES テスト環境 • 不安定性を可視化する • アプリエンジニアに協力求ム • 失敗しない工夫をする 課題 環境不安定でテストが失敗する • 様々な人がテスト環境を使用 • テストデータ不安定 対策
  12. 12. 12 3. 自動化が安定してきたときの闇 @photoAC • 既存機能の修正キャッチアップの仕組化 • テスト自動化の優先度を明確化 課題 プロダクトが常に更新、テスト失敗する • 短いサイクルで更新 • 重要な機能の更新頻度が高い 対策
  13. 13. 13 4. 現在の闇 @FREEIMAGES 課題 エンジニアが不足
  14. 14. 14 5. 光はあるのか? @FREEIMAGES
  15. 15. 15 5. 光はあるのか? https://www.practitest.com/resource/state-of-testing-report-2019/
  16. 16. 16 5. 光はあるのか? https://commerce-engineer.rakuten.careers/ 詳細はWebで

Editor's Notes


  • これまでのキャリア
     最初、組み込み系のソフトウェアエンジニア 2年間
     その後、WEBエンジニア 13年間
     次にプロダクトマネージャの経験を経る
     2016年、いまのSQA部署の構築から携わり、テスト自動化を合わせて構築しました(3年目)

  • 状況
    - テスト自動化をまだ導入していないフェーズ
    - マニュアルテストでなんとか品質は担保できている
    - テスト自動化はコストがかかるし、コストだけではなく初めて見ることに高い壁を感じていた
    このような状況のため、テスト自動化をやってみようという雰囲気ではない。
    机上でROIの議論は説明できない。

    作業効率化含めて自分でやってみれば?
    - 自動化で、テストや、それ以外の作業効率化を実数値で見える化、コストメリット(時間コスト含む)も試算

  • 状況
    - テスト自動化エンジニアが少ない
    - 現在のQAプロセスで自動化をどのように使うのかがわからない

    - いまのQAメンバでできるテスト自動化のプラットフォームを構築。 - QAプロセスでテスト自動化の活動をどのようにいれるかも、試行錯誤した。
  • チーム内の状況
    - 処理を自動化しているが、validationしてなく、テストになっていないものが多い
    - 自動化の作成数がメインとなり、マニュアルテストでもあまり価値のないテストの自動化までも行われる

    自動化の詳細な内容に関しては明確にしてこなかった。そのため起きた事象。
    そのため、自動化の定義を明確化。
    テストを自動化することが目的なので、マニュアルと同様に、なにをvalidateするのか 次に、自動化のする・しないの判断軸を明確にする。例としてアジャイルテストの4象限があります。 自分のチームに適した、自動化のする・しないの基準を設け、それをもとに自動化を取り組んだ。
    せっかくの自動化なので、テスト以外で自動化により作業改善できる事
  • - テスト自動化の過剰な期待が高まる
    - すべてが自動化に置き換わるのでは?説
    テスト自動化をよく理解していないステークホルダからは、銀の弾丸のように見えてくることがある。
    - 自動化の予算をとったこともあるため、自動化に関して消極的なことは言えない。 - これは地道に、テスト自動化に関して、例えばテスト自動化の8原則のようなことを説明するしかなかった。 - モブプロちっくに実際に自動化作成をやらせてみせて、体験してもらうこともした
  • - テスト環境のインフラ(ネットワーク、サーバー等)が全社共通で利用しているため、不安定
    - アプリケーションが頻繁に更新して、不安定
    - テストデータが、複数人利用して不安定

    それにより、自動化がよく落ちる。
    -最初にしたことが、失敗の可視化。 - 可視化ができれば、よく落ちる原因をもとにエンジニアと環境整備等をはたらきかけ、 - 自動化のスクリプトもその不安定さに耐えうる実装できないかの検討もしぼりこみができ、着手しやすくなった
  • -2週間サイクルでちいさな改修が発生する
    -重要な機能にも改修が入る
    -自動化の考え方として、頻繁に変更の入るところの自動化は不向きというが、そのスタンスは取っていない

    -プロダクトの更新と既存の自動化スクリプトの影響範囲の確認をするフロー
    -自動化のスクリプティングに優先度を決め、先にfailするであろう、既存scriptの改修から作業する。最悪新規機能の自動化はリリース後に対応

×