Outline
Jasst'21 Tokyoでプレゼンする機会をいただきました。
その発表内容のサマリをQiitaに載せました
Background
Test automation responsibility
われわれのテスト自動化チームのresponsibilityには以下の3つあります。
1. Test automation covers regression
2. Update regression script and create new script during project
3. Do regression test in test environment everyday
テスト自動化では、既存機能のテスト（regression)を担当しています。
新規機能の追加や、既存機能の修正等が発生した場合、
・既存機能の修正 → regressionテストが失敗するため、最新の仕様に合わせてscriptを修正する
・新規機能の追加 → 新規scriptの作成、あらたなregression testとして追加される
このregressionは毎日テスト環境で実行され、バグや環境問題等さまざまな問題を早期に発見する
これらresponsibilityを持つため、日々さまざまなoperationが発生する。
Test automation operation issue
What is test automation operation?
毎日、regression testを実行するにあたって、大きく以下のようなoperationが発生する。
1. Check test automation results
2. Investigate test result of test automation failed
3. Handle test automation results
テスト自動化は走らせておしまいではありません！
すべての結果が常にOKであれば問題ないですが、そうはなりません。
失敗した結果を取り扱う必要があります。
現在、2,000近くのjenkins jobs(regression test)があるため、すべてのjobsの情報をdashboardに集めます。
その中から、失敗したjobsをpickupして、なぜ失敗したかを分析する作業が発生します。
失敗したときのtest reportの例
分析の結果、大きく4つの失敗理由に分類します
| NG reason | operation | note |
|---|---|---|
| Application bug | Bug Reportでdevのfixを待つ | |
| Test automation script bug | 自身で自動化のscriptを修正する | |
| Environment issue | 環境が回復するまで待つ。jenkins scheduleを調整する | |
| Temporary unstable | test automationを再実行する |
4番目の”Temporary unstable”に該当する失敗例が以下の通りです
Investigate issue
実際に、テスト自動化が失敗した理由がどういう傾向であるかを調べてみた。
上記のsystemを構築した。
1. jenkinsのテスト結果をDBに自動集約する
2. テスト失敗を分析し、その結果（失敗理由が４つのうちどれに該当するか？）をラベリングする
その結果が以下の通りです
このように、バグによる自動化の失敗はわずか0.5%（そんだけアプリエンジニアが優秀ってことスカ？！）に対して
不安定な環境による失敗(Temporary unstable)が3/4を占めていることがわかる。
Improve operation
先ほどのように、”Temporary unstable”の時の率が高く、かつこの問題の解決が再実行だけという、つまんない作業を改善しないといけない。
失敗レポートを見る → Temporary unstableである → テスト再実行 → 成功になってることを確認
Auto Healing System
上記問題を解決する方法が、”Auto Healing System”である。
- 先ほど、テスト失敗をラベリングした膨大なデータがある。これをAIの教師データとして使う
- この教師データをもとに、テスト失敗したレポートを分析し、失敗理由を予測させる
- 予測結果に基づき、必要に応じてテスト自動化を再実行させる
以下、詳細なフローである
テスト失敗したとき、テスト結果として、コンソール等のエラーメッセージ、失敗時のスクショをこのシステムのINPUTとする
次に、このINPUTをもとに失敗理由を予測する
最初に、スクショを予想しやすくするため、画像からエラーメッセージのを文字として抽出する
これら、文字情報をもとに、失敗理由の予測をする
もし、文字情報で予測が困難だった場合、画像をもとに失敗理由の予測をする
予想処理の締めとして、この結果を教師データにフィードバックする
最後に、この予測の結果をもとに、テスト自動化の再実行の判断を自動で行う。
Results
1.Retry operation is dismissed, then human cost is ZERO
2.Test result keep stable
3.Make good use of test environment resources
この仕組みにより、一部失敗のテストを自動で再実施、成功に導くため、ヒューマンコストがゼロになる。
また、この仕組みが常に動くため、失敗しても成功になるように働くため、常時安定したテスト結果を保つことができる。
テスト再実施も、復旧の見込みのあるものしか行わない。そのため、テストリソースも必要以上に利用されない。
Q&A (Slido)
5つの質問をいただきました。
改めて、回答します。
Q1. How much time takes to update automation script after a new project?
基本的に、project内でテスト自動化のscript修正を完成させるのが、自動化チームのresponsibilityです。
われわれQAグループは、projectのQA完了とは、マニュアルテスト、テスト自動化両方がOKを出したときです。
修正時間は、projectの影響範囲によります。
修正規模が少ない案件であれば、当然少なくなります。
例として、2 weeksのテストの場合、おおむね1-2 daysのテスト自動化の修正工数が発生します
Q2. How many test automation script bug % you get daily basis?
発表にあった通り、全体の５％がテスト自動化のスクリプトによるバグです。
テスト自動化が安定化したスクリプトであれば（1-2 weeks run）、おおむねバグは発生しません。
あったとして、特殊な日付などといった、時系列に関する問題が5-6 個/week発生します
How do you analyze 'daily operation issue' to fix or not?
基本的に、すべてFIXしないといけません。
FAILを放置は、テスト自動化の信頼をなくします。
アプリバグや、環境問題など、テスト自動化エンジニアで解決できない問題以外は、すぐに解決するようにしています。
Is your approach based on the facebook's approach or similar ones?
もうしわけありません。facebookのaproachを知りません。
教えてください！！
Do you have to worry about missing a bug due to a false negative?
false negativeは心配しています。
たまに、テスト自動化の挙動を目視して確認します。
とはいえ、多くのjobがあるため、すべてではないです。
projectで気になったscriptをpickupして確認しています