E2Eテストをお手軽に評価する

こんにちは、アルプでQAエンジニアをやっているyokota(@katawara)です。
前回の記事ではアルプで行っているE2Eの話をしましたが、今回はその運用編です。

E2Eの自動テスト、今ではいろんな会社さんで行われてきていると思います。
自前でプログラミングするケースもあれば、Autify, mabl, MagicPodといったSaaSを利用するケースもあることでしょう。
いずれのケースにせよ、導入した後おそらく直面するであろうこと、それは評価（効果測定）じゃないでしょうか。

今回は、アルプでE2Eを運用・計測していく中で、約1年ちょっとかけて見てきた結果、「もうこれだけでわかるね」と集約させた2つの指標の話をしようと思います。2つだけと聞くと不安になるかもしれませんが、最後まで見ていってもらえたら嬉しいです。

2つの指標

まずは結論から。アルプで追いかけてきたのは以下の2つです。

• 安定度

• 信頼度

定義としてはこんな感じ。

安定度 = 全シナリオ一周したときノーミスである確率
信頼度 = 失敗したシナリオのうち、失敗理由に運要素が絡まない（いわゆるflakyテストではない）確率

数式にするとこうです。

安定度[%] = 全シナリオを実行するテストがノーミスで終わる回数 / 全シナリオを実行するテストを回した回数
信頼度[%] = flakyテストではない失敗シナリオ数 / 失敗した全シナリオ数

この2つの数値が程よいバランスにあることを月単位で見ています。

どうバランスさせるか

アルプでは、「E2Eがいい感じに動いている」ということを以下のように定義しました。

安定度 = 70%以上 かつ 信頼度 = 50%以上

体感的なところで言えば、「日次で動かしたら、週に2〜3回くらい失敗することはあるかもしれないけど、そのうちの1〜2回くらいはプロダクトの不具合 or 変更を見つけている」と言ったところでしょうか。

たとえば、安定度が高くても信頼度が低い場合、そのテストは「まあまあちゃんと動いているっぽいけど、落ちたらどうせ再実行でしょ、ハイハイ」と解釈できます。
逆に、安定度が低くても信頼度が高い場合、それは「え、ちょっとプロダクトやばない？ だいじょぶそ？」と読み解くことになります。

以下は社内向けにE2Eの状況を共有するときに使っている表になります。2つしか指標がないので、組み合わせも4通りです。

全部の組み合わせを分類するとこうなります

落ちすぎてもだめだけど、落ちなすぎてもだめだし、かつ、落ちるにしてもいい落ち方・悪い落ち方があるよね、という微妙に表現が難しい塩梅がE2Eには求められているんじゃないかなと思います。この2つの指標は、そのイメージを端的に表現できているのではないでしょうか。

そして、ほぼこれだけをずっと見てきた結果を以下にまとめます。

結果の変遷

記録を取り始めたときはこんな状態でした。

記録を取り始めた当初、2023年の6月はそこまで明確な指標には落とし込めていません。表現なども若干違い、

• 安定度 （100% pass率） = 51.7%

• 信頼度 = 未測定

って感じですね。ここから何回かの試行錯誤を経て、安定度と信頼度という表現へと変化していきます。

そして、だんだんスプレッドシート運用がこなれてきて、Looker Studioで記録を残せるようになりました。改善も少しずつ積み重ねていたのですが、2024年の1月頃に一回大きく崩れました。

flakyテストしかなかった

そこからまた持ち直し、今（2024年の8月終わり）はこんな感じです。

隔世の感がありますね

大体月5〜6件くらい不具合 or 変更を検知していて、flakyテストはなし、ですね。
初期に定義した数値目標はとっくに上回り、安心して見ていられるようになりました。

運用のコツ

約1年やってみた中でコツっぽいなと思ったことをまとめてみます。

1. 定期的に計測して考察をする
2. 原因の調査はわかるまで継続する
3. 原因がわかったもので、自力で対処できるものは一個一個きちんと潰す
4. 数字はハックしない = 目標にしすぎない

1, 2, 3 は当たり前と言われたらそのとおりかもしれません。が、今の数字をどうやって成し遂げたか振り返っても、答えになりそうなのは結局これくらいでした。

少し変わってるのは4でしょうか。意外と大事なことだと思っています。

指標を置くと、人は目標に置きたくなります。目標に置くと、「達成しなければならない」というバイアスがかかります。そうなると、結果を良く見せやすくするためのルールづくり = ハックをしたくなります。

この2つの指標、同時に高水準で成立させるのは地味に難しく、ハックはしにくいはず、とは思います。
しかし、テストが失敗しないタイミングを狙って何度もテストを回すと安定度を上げることができます。逆にリグレッションの失敗が起きているときに何度もテストを回すと信頼度を上げることができます。任意で実行したものまですべてカウントしてしまうと、実は都合のいい数字が作れてしまうのです。

そうすると指標自体の信用がなくなってしまうので、集計対象としては1日2回のスケジュール実行の初回（*1）の結果のみを参照する、という縛りを加えることにしました。

*1: 「初回」という断り書きを入れているのは、スケジュール実行も再実行すれば結果を上書きできてしまうので、それを防止しています。

最近はどうなのか

計測と考察は今も週次で続けています。計測を始めた初期はひたすら手で集計していましたが、今はGASなどを組んで半自動で集計ができるようになりました（それはまたいずれ別で紹介かな？）。
かつては毎週1〜2時間かけてやっていましたが、今では10分もあれば終わります。

また、この2つの指標に加えて、実行時間も気にするようになりました。上の結果の画像にもしれっと出てますね。
集計を半自動にしたときの副産物的なものだったのですが、これも参考記録として推移を見るのも一定悪くないなと感じています。

おわりに

ということで、E2Eで見ている2つの指標のご紹介でした。評価に関して似たような悩みを抱えているどなたかの参考になったら幸いです。

アルプでは 「安定度 = 70%以上 かつ 信頼度 = 50%以上」 としていますが、この数字はコンテキストによって変えていいと思っています。ここでは自前のE2E（社内通称harness）の事例でしたが、並行して使っているAutifyについては別の数字で定義を考えたりしています。概念だけキャリーして計算式を変えてしまうのもアリでしょう。

大事なのは、この数字をどれくらいと置いたら、自分たちにとってテストが上手く行っているという体感に近くなるか、です。なのでまずは計測して、そこから頑張れる目標を算出するとやりやすいかもしれません。

ただ、目標として強く打ち出しすぎると、ハックの余地を探しに行きたくなってしまうことは注意だと思います。きちんとあるがままを見るように設計できると改善も進むでしょう。

そして何より、この指標はQA単体の力ではなし得ません。困ったことがあったらチームを巻き込んでみんなで改善を積み重ねていきましょう。

それでは、よいE2Eライフを！