2020/06/30 Rakuten Commerce QA Night #2


Outline

第2回目の楽天コマースカンパニーのQA Nightがオンラインで行われました。
自分はここでLTセッションで「Improve test automation operation」を発表を行いました。
その発表した内容に関してまとめました。
https://connpass.com/event/176899/

Organization

最初に、自分の所属している部署、及びstakeholderとの関係です

  • 複数のサービス開発グループと、1つのQAのグループがある
  • 我々QAが担当するサービスは5つある(ゴルフ、競馬、TOTO、ビューティー、プロスポーツ)
  • QAは第三者品質保証と同じ立ち位置
  • QAの中でもマニュアルテストとテスト自動化のチームに分かれている
  • 自分は、テスト自動化のチームに所属

Test automation operation struggling

Test automation benefits

テスト自動化でテストカバレッジを増やせば、いろいろなメリットがある。
大きく3つのメリットは以下の通り。

1. リグレッションテストのトータルコストが大幅に削減される
2. テストのフィードバックが早くなり、バグの早期検出に役に立つ
3. テストを勝手にやってくれるので、QAエンジニアは楽ができ、もっと知的な作業に集中できる

Test automation struggle

ただ、現実問題テスト自動化には様々な困難を伴う。
大きく3つの困難は以下の通り。

1.  多くのテスト失敗レポートがやってくる
2.  最新のアプリケーションにテストスクリプトが常に追従していかないと、陳腐化してしまう
3.  テスト自動化エンジニアが意外に少ない

今回はその中でも1番目の”多くのテスト失敗レポート”に関してブレイクダウンする

Classify failure report

テスト自動化の失敗の原因を分析し、大きく4つに分類した

1. バグを検出
2. テスト自動化のスクリプトに問題
3. 環境問題
4. 一時的に不安定で失敗した

「1. バグを検出」は、リグレッションテストとして、素晴らしい結果である。
喜んで、落ちた原因を調べて、エンジニアにレポートしましょう。

「2.テスト自動化のスクリプトに問題」は、テストエンジニア側の不備。
テストスクリプトにバグ、もしくはアプリケーションの仕様が変わってしまった。
あとは、スクリプトの実行順序の問題などが考えられ、この問題をテスト自動化エンジニアは解決しないといけない。

「3.環境問題」は、テストデータに不備があったり、そもそもテスト対象のアプリケーションが準備できてない時に起きる問題。
担当者と連携して、発生しないようにしないといけない。

最後の「4.一時的に不安定で失敗」は、一時的に発生する、ネットワーク断や500システムエラーなどである。
これはQAとしては如何ともし難い。

実際の分析結果のウェイトを調べたところ、「4.一時的に不安定で失敗」が約75%占めていた。

Operation for Temporary unstable

「4.一時的に不安定で失敗」の時にオペレーションは以下の通りである。

  1. バグレポートの原因調査
  2. テストスクリプトを再実行
  3. テスト結果を確認

レポートを調べ、再実行するだけの作業だが、これが1日100個発生すると仮定すると、月間75時間の作業工数が発生してしまう。

Improve test automation operation

上記の通り、"Temporary unstable"の失敗に関するオペレーションを削減することで、大きな作業改善に繋がる。
そこで、この改善するシステムを模索した

1. テスト失敗レポートの分類分けを自動で行う
2. 分類の結果、"Temporary unstable"に分類された場合、テスト自動化を再実行する

Step1. Test Result is failure

我々は、テスト自動化のツールとして、Ranorexを使用しています。
失敗したときの情報源として、以下のものがある

  • 実行コンソールのエラーメッセージ
  • エラー発生時のスクリーンショット

Step2. Predict reason

上記、エラーの情報源+過去の分類情報を元に、エラー原因を予測します。
使用した技術として主に以下のものがある。

  • Tesseract OCR
  • Deep Neural Network

これらにより、エラー結果のメッセージやスクリーンショットを学習させ、エラー原因を予測します

Step3. Classify and Run again

エラー原因を予測後、"Temporary unstable"の時、単にテストを再実行させる。
これにより、以下の効果が得られる

  • 人間の無駄なオペレーション作業工数を減らす
  • 一律全部を再実行するわけではないので、テストリソースの無駄も省ける

仮に月間100時間オペレーションが発生するような時でも、月65時間のオペレーション時間削減ができた。

Summary

  • テスト自動化のオペレーションは、多くの時間を要し、そしてつまらない作業が多い
  • テスト自動化のオペレーションも、自動化をしていきましょう
  • 今回紹介したシステムは、理想形から一部しかできてません。もっと改善していきたいのが今後の展望

これまでの発表