E2Eテストを導入しようとして失敗した話

これは 検索エンジンプロダクトを一緒に開発してた同窓会 Advent Calendar 2023 の15日目の記事です。

当プロダクトのQAエンジニアとして私が参加していたのは2019年7月〜2020年3月までの期間でした。
（既に記憶が曖昧な部分はありますが）在籍中にE2Eテストを書こうという機運が高まったは良いものの、結果的に大失敗した経験を語ろうと思います。

QA文化がなかった現場で数ヶ月後にE2ETestを！

そもそも私がjoinしたきっかけは、POのこんなお悩み相談からはじまったのでした。
「リリースしたら毎回切り戻してるんですよね〜」
そ、それはたいへんですね。

いろいろ話は省略しますが、QA文化がなかった現場でどうにか毎回きちんとしたテストフローに乗せるまでの体制をつくり、9〜10月頃には開発チーム自らE2Eテストを書くようになったのです！

テストは書いたが、粒度がバラバラだった

割と物量もあがってきたところで、テスト/QA界隈ではよくある悩みが持ち上がります。

• テストがなかなか終わらない（20〜30分かかる）

• よく見たら同じようなテストがいっぱいある気がする

• 他にどんなテストが書かれているのかよくわからない

私に相談があったのはこの辺からだったと思います（ここまで自律的に動けたことはすごいです！）。
そこで「テスト自動化改善委員会」が発足しました。

全員サンクコスト効果に囚われていた

ここまでに費やした時間。大量のテスト。それらをどうにか使えるものにしたい。
私の性格では、（自分自身がテストを書いた主体ではないこともあって）「パーッとイチから書き換えましょう！」と言いたかったところですがw
「どうすれば今ある資産を有益なものにできるか？」
という議論を長く続けたような気がします。
ちなみに「サンクコスト」とは「もう支払ってしまった代償がもったいなく撤退できない気持ち」を指します。
しかし、やはり一度ひっくり返してこう言うべきでした。

「テスト自動化を検討する前にテスト設計をしっかりしましょう」

---

テスト自動化の8原則

以下は　STAR（Software Testing Automation Research Group Jp）　という研究会が提唱している「テスト自動化の8原則」です。

有名なやつなのであちこちで引用されていますが、知らない人は知らないので何度でも引用しようと思います。1つずつ見ていきましょう。

1. 手動テストはなくならない

ユーザビリティテストなど、そもそも自動化できないテストタイプが存在する。システムに対してはじめて実行されるテストはテストケース自体の成熟度の観点から、手動で実施したほうがテスト実行の品質が高いケースが多い。また、自動化がうまく進行している機能テストの残り数％など、テストを自動化するコストとベネフィットが釣り合わないケースもある。これらの事情によって、手動で実施されるテストが無くなることはない。

なおグーグルでは「毎日40万件の自動テストを行っている」そうです（※2017年ICST基調講演情報）。

2. 手動でおこなって効果のないテストを自動化しても無駄である

そもそも、テストプロセス（e.g.テスト分析、テスト設計、テスト実装、報告）、特にテスト分析、テスト設計が適切に行われていないテストは、優秀なテスターが手動でテストを実施したところで、テストに期待される動作の保証やバグの検出といった効果を発揮しない。いわんや、自動テストにおいておや、である。

いきなりテスト自動化をしようとすることは、「仕様検討も設計もせずにコーディングする」ことと同等です。

ちなみに「おいておや」→「おいてをや」ね。

3. 自動テストは書いたことしかテストしない

人間による手動テストは、テストケースの記述に対して驚くほど広範な要素を暗黙的にテストしている。これに対し、操作、合否判定を厳密に記述する必要がある自動テストにおいては、おのずと視野は「記述された様に」限定される。ユーザ名とパスワードを入力してログインする、といったテストが自動化されていたとして、その自動テストは仮にログイン画面に表示されているロゴが競合他社のものであったとしても、それに気づくことはない。

機械が機械的にテストするのは「チェッキング」という領域です。

人間は「テスティング」に集中したい。

4. テスト自動化の効用はコスト削減だけではない

もし、テスト自動化によってなんらかのコストが削減できるとしたら、十分に成熟しているテストケースが既に存在しており、そのテストは今後何度も実行される予定があり、自動テストの開発を円滑に進めるための準備が完了している場合と、テストの手順が同じで、テストすべきデータが膨大に存在する場合の「テスト実行」のコストである。テスト自動化には、繰り返し型開発におけるセーフティネットとしての役割や、バグ修正日数の低減、影響範囲レビュープロセスの代替、といった、開発アクティビティへの効用も存在するため、冒頭にあげたひどく限定された局面を狙うより勝ち目があるかもしれない。

一般的に「コスト削減」を期待される自動テストですが、実はメンテコストがわりとかかるので劇的なコスト削減ができる状況というのがけっこう限られたりします。

どこをどのくらい自動化するのか計画をしっかりたてることが重要です。

5. 自動テストシステムの開発は継続的におこなうものである

テスト自動化に関わる苦労を10とすると、自動テストシステムが完成するまでが3、残りの7は運用に関するコストである。テスト対象の変化への追従、テストケース、テストタイプ自体の追加、変更に対する適応、といった、今あるものが継続的に効果を発揮するための活動はもとより、自動テストのターンアラウンドタイムの向上、信頼性の向上、などなど、システムの価値を向上させていくための活動など、やるべきことは多岐に亘る。テスト自動化システムの提供はプロジェクトというよりサービスとしてとらえるべきである。

上述の通りメンテコストがばかになりません。メンテコストを織り込んだ上でテスト自動化を考えることが必要です。

6. 自動化検討はプロジェクト初期から

自動化を考慮せず「出来上がってしまった」システムに対して自動テストを書いていくことは、よくあるテスト自動化エンジニアの苦行のひとつである。自動テストシステムがシステムをよりよく操作、判定できるように、ひいてはセーフティネットを最適なコストで構築するためにはシステム側で最初から検討して設計に織り込んでおく必要がある。また、繰り返し実行されるテストが予めわかっているなら、自動化を前提として、テスト計画を策定すれば効果的である。

自動化のためのbreak pointを設定しないといけなかったりしますが、そのような点が考慮されていないプログラムに対して自動化をしていくのは骨が折れます。

長期利用されるシステムであれば、最初から「いずれテスト自動化する」という目的をもった上でシステム構築をした方が幸せになれます。

7. 自動テストで新種のバグが見つかることは稀である

運用に乗った自動テストは基本的に「枯れた」テストケースを対象とするため、ほとんどの種類のバグはテストケースを枯らす過程、あるいは自動テストを実装する過程で既に人間によって発見されているはずである。多くの運用に乗った自動テストの意義は「一度動いたはずの機能がうっかり壊れる」ことを最速で発見することにある。ただし、手順が同じでデータの種類が膨大なテストを自動化する場合、ファジング、テストパターンを有機的に生成できるAPIレイヤのテスト、ブラウザやRDBなどのバージョンアップの影響を受けていないことを確認するテストなど、いくつかの例外もある。

自動テストで「新しいバグの発見」は期待しないでください。言い換えると、「新しいバグの発見」は人間がやらないといけないです。

8. テスト結果分析という新たなタスクが生まれる

マニュアルテストでバグが発見された場合、その再現手順は明らかであるから人間はある程度の最適化ののち、即座にバグ登録を行う。しかし、自動テストがFAILEDを出してきた場合、何が起きたのかを改めて人間が確認する必要がある。これが1日数件ならまだかわいいものであるが、自動テストが無事？拡大した結果、数万件のテストケースに対して数千件のFAILEDが検出されたとしよう。それを種類ごとに仕分ける作業だけでも憂鬱である。自動テストが拡大した結果、テスト結果分析のコストがそれに伴ってリニアに伸びないような施策、例えばコールスタックやAPIコール履歴などから、ある程度自動的にFAILEDを仕分ける機構などを検討する必要がある。

「マニュアルテスト」＝「手でやるテスト」という意味です。何度も登場する「メンテコスト」には、「テスト結果がGreenにならない場合の原因調査」も含まれます。たいへんなんだこれが。

「Freaky（不安定なテスト結果）をどうするか」がテスト自動化担当者の永遠のテーマだったりします。

テスト自動化を検討する前にテスト設計をしっかりしましょう

ここまでお読みいただきありがとうございました。
「テスト設計をしっかりする」とはどういうことなのかは、また別のお話になるので他の記事に譲ります。

さて、当時のE2Eテストは最終的にどうなったのか…？
（あまり覚えてないけど）結局最初から必要なものだけ抜き出して書き直したような記憶です。
それではまた次の記事でお会いしましょう！