2020/06/30 Rakuten Commerce QA Night #2

# Outline

<IMG SRC="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/300f0cc7-c28d-67e0-0088-38a275e855ca.png">

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


<A HREF="https://www.slideshare.net/SadaakiEmura/20200630-rakuten-qa-meetup-2-improve-test-automation-operation"><IMG SRC="https://image.slidesharecdn.com/20200630-qameetup-200630041347/95/slide-1-1024.jpg"></A>



# Organization

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

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

<IMG SRC="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/636bf9ac-efb4-7d77-6a54-a563a4f79e4c.png">


# Test automation operation struggling

### Test automation benefits

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

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

### Test automation struggle

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

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

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

### Classify failure report

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

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

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

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

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

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

<IMG SRC="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/dc764f36-626a-a00a-9832-73138d0f092e.png">



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

<IMG SRC="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/d048170e-8a07-0a8d-98b8-c75c747f4e5d.png">


### Operation for Temporary unstable

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

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

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


# Improve test automation operation

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

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


<IMG SRC="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/3b40c2e5-f1f2-525b-d7b9-8a5a16bbcd74.png">



### Step1. Test Result is failure

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

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

### Step2. Predict reason

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

- Tesseract OCR
- Deep Neural Network 

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

### Step3. Classify and Run again 

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

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

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


# Summary

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



# これまでの発表

- <A href="https://qiita.com/emurin/items/e5f4f1552cab203f777f">2019/10/28 ソフトウェアテスト・QA勉強会【（仮）テスト自動化の光と闇（1年間の苦労話）】</A>
- <A HREF="https://qiita.com/emurin/items/9bd0c5871a05186da9aa">2019/06/13 自動テスト喋り足りNight #1</A>
- <A HREF="https://qiita.com/emurin/items/49c01da835e6df0555ee">2019/05/31 JaSST'19 Tohoku
test</A>
- <A HREF="https://qiita.com/emurin/items/5259442630580f1d968e">2019/05/17 Ques No.13</A>
- <A HREF="https://qiita.com/emurin/items/425de096c6af444a26ba">2019/04/24 Rakuten Commerce QA Night#1</A>
- <A HREF="https://qiita.com/emurin/items/0b4763175cfb86c97106">2018/12/01 JaSST'18 Hokkaidoで登壇してきました。テスト自動化の改善</A>