Test Automation Metrics

# Background

テスト自動化は、いろんな情報が取れる宝庫である。
それを可視化して、品質（プロダクト、テスト自動化スクリプト自体）をWatchすることは
テスト自動化の運用には必要である。
今回、具体的なMetricsを上げる

# System mechanism example

まず、データを集める仕組みが必要である。
いろんな収集方法があり、ミドルウェアもいろいろある。
今回、一例を示す


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/d4b4d7bd-c834-4a7f-5604-e1ae35afd00e.png)

# Product Quality Trend

全てのテストスクリプトの実行結果（主に成功率）を可視化する。
これにより、プロダクト全体の品質の安定性がわかる。
昨対で品質が大きく変化したか、テスト実行数の総量の妥当性等が一目でわかる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/7d67bbd6-4571-e9d2-febb-36aa157092cc.png)


# Test Result History (check for Flaky)

テストシナリオ一つずつの実行結果を可視化する。
これより、テストのFlaky度がわかる。
Flakyとは、プロダクトの変更が入っていないのにテストが成功、失敗を交錯する状態である。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/8bf7ae8b-33da-66b1-a78f-cd6918577dcc.png)


# Duration (check for performance)

各テストシナリオの成功時の実行時間を可視化する。
これから2つのことが見える
- プロダクト側のパフォーマンス問題
- テスト自動化スクリプトのパフォーマンス問題

例えば、テストデータを繰り返し作成するようなテストシナリオ（買い物を繰り返し、購入履歴が蓄積する）では、プロダクト側のパフォーマンスに実際影響がでてくるときがある。
このとき、データが多くなった時のパフォーマンス劣化をキャッチすることができる。

ただ、プロダクト側のパフォーマンスに問題がないのに、遅くなってくる場合、自動化のスクリプトに問題がある可能性がある。
例えば、オブジェクトを特定する方法（Xpath等）。そのオブジェクトを見つける

Example 
```
# RobotFramework
Click Element  xpath=//XCUIElementTypeButton[@name="Login"]
```

このxpathの特定の仕方がわるいと、自動化がオブジェクトを探すのに時間がかかってしまう。
機能はかわらないが、UIが変わっていくサイトでは、この事象が起きうる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/164fa1cf-0cb8-9cd4-9fb1-72b88366d584.png)


# route cause

マニュアルのテストでバグ分析をやっているのと同じで、テスト自動化もバグ分析をするとよい。
原因ラベルを定義し、自動化が失敗したときの原因にラベル付けを行う。

マニュアルと異なるのは、一つずつのテストスクリプトの分析である。
繰り返し実行する中で、失敗の原因を追うことにより、スクリプト自体の問題（Flakyなど）が見える化される。

当然、全ての合計することにより、プロダクト全体のバグ分析にも使うことはできる。


ラベリングの仕組例
１回のテストシナリオが失敗したときに、ラベル付けする

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/e31f3fd0-5d58-1245-8074-b64860fc57c5.png)

原因分析
上記、１テストシナリオのすべてのバグのラベルを集計したもの。
これから、このテストシナリオのバグの傾向がわかる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/59910c68-e8b8-de96-5bd7-e5b7eda2c81c.png)


# resource usage

E2Eテストは、時間がかかる。
常にテスト自動化を実行するような環境の場合、テストリソース（テスト実行環境のPC、JENKINS、等）の使用率が重要になる。
偏ったスケジューリングをすると、テストが滞留する。
また、１テストの実行時間が長いため、一定期間に使用率か集中するなど問題が起こりうる。

以下はテストの実行時間を時系列で可視化したものである。
１時間あたりの実行合計時間が６０分を超えてるのは、処理しきれていないことを示している。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/ce2b41a5-cca2-b161-d0b2-456f5922175b.png)

# テスト自動化の成果

テスト自動化の構築理由の一つとして、ROIがある。
これを定量化しておくと、構築後のレビュー時に自動化を導入したことを改めて評価するための参考になる。

## 不具合検出数

テスト自動化関連でみつけた不具合件数である。
検出した件数だけではROIを算出することは難しいかもしれない。
ただ、手動テストだけで検出するより、効率よく不具合を多く検出していることを確認するための情報源にはなる。

- テスト行程でテスト自動化にて検出された不具合
- テスト行程前に定期実行などにより早期に発見された不具合（開発フェーズに早く不具合を見つけることで、開発の後戻りを小さくすることができる）
- 手動テストでは実行が困難なテストの不具合（手動テストだと、工数がかかったり、そもそも際限が難しいテストを自動化によって実現すると、重宝されるテストになる）
- 手動テストを自動テストに置き換えることにより、空いた時間で追加できたもっとレベルの高い手動テストで発見された不具合（手動テストと自動テストのすみわけで、カバレッジを広くとることができる）


## テストスピード＆サイクル

手動テストでプロダクト全体のリグレッションテストを行ったときの実行時間と、テスト自動化に置き換えたときの実行時間を算出してみるとよい。
数倍から数十倍の差が出てくるはずである。
手動テストを自動テストに置き換えた場合のコストは当然のことながら、実行時間短縮も大きなメリットである。

- テストサイクルを増やすことができ、開発期間を短縮、早くリリースすることができる
- テスト実行時間短縮で、開発へのフィードバックを早くすることができ、不具合改修に早く着手できる
- テスト実行時間短縮と、サイクルを増やすことで、些細な改修でも全体のテスト実行で品質を確認することができる

結果的に、テスト実行時間のメトリックスによって、品質やコストの定量化につながる。