正直私自身「こうするとよい」という具体的かつ再現性のあるテクニックは持ち合わせていないのですが、いくつか思いつくものや実際やっていたものを書いてみます。
きっかけ:失敗したE2Eテストの原因調査をしていたら、意味のないAssertがあった
E2Eテストが失敗したときには、その原因を調査する必要があります。その際には直接失敗になったステップだけでなく前後のステップも見ることになるわけですが、ここで「絶対失敗にならないAssert」をたまたま発見した、ということがありました。(仕事の話なので具体的な説明は避けます)
この手の話はE2Eテストを作って運用していると出てくるものだと思っていて、実際過去にテスト自動化関連の発表をした際にも「作成したE2Eテスト自体が問題なく動作していることはどのように担保しますか?」と聞かれたことがありました。
意味のないAssertを書いているということは、仮にそこでバグがあっても見逃してしまうということ。つまりテストに問題がある、といえます。これはそのテストケースだけでなくE2Eテスト全体の信頼性に関わるところなので、できる限り無くすべきです。
E2Eテスト自体をどのように担保するか
ここが本題ですが、私自身は以下のような方法があるかなと考えています。
1. 自動テストコード・シナリオ自体のレビューを行う
自動化する前の(ハイレベル・ローレベル問わず)テストケースのレビューは行う場合が多いと思いますが、今回話の対象にしたいのは「テストケースには問題がないが、テストの実装とテストケースの間にズレがある」という場合です。
これはプロダクトコードと同様、作成したテストコードや(ノーコードツールの場合は)テストステップ・シナリオのレビューを行う必要があると考えます。
レビューを行うことで、テストケースで意図した内容との差分を見つけることができますし、また特にAssertのブレを発見しチーム内ですり合わせる機会にもなります。
Assertのブレとは、たとえば「**画面に遷移すること」という確認項目があった際に、「**画面に遷移した」という事実を何をもって確認するかが、テストを実装する人によって異なってしまうことを言っています。
2. Passした自動テストの結果を精査する
もう一つは、Passした自動テストのうちのいくつかを選択し、その実行ログやエビデンスから「本当に意図した通りに動いているか」を確認するという方法です。
自動テストを運用していると、基本的にはPassしているときは全体の結果だけを把握して、Failしたケースがあったらその結果を精査する、ということが多いと思います。そうではなく、Passしているときにも一定のタイミングで結果の確認を行う、という方法です。
抜き打ち検査、のようなイメージですね。
これまた私のパターンですが、E2E自動テストのステップごとの所要時間を見て「想定以上に時間がかかっているステップはないかな?」と探す、というのをたまにやっています。このとき、ついでにステップごとの結果も精査して、想定どおりに動作しているかどうかもチェックしています。
テストが想定どおり動いているかを確かめるためだけに精査しようと思うと、面倒になって結局やらなかったりするので、なにかのついでに確認くらいが良いように思います。
その他
過去それほどやってはこなかったですが、他にも
- あえて自動テストが失敗する状況を作り、正しく失敗することを確認する
などもあります。ミューテーションテスト的なアプローチです。個人的には運用中の自動テストに対して行うことはほぼなく、むしろ自動テストを実装しているときに、確認のためわざと失敗させてみてAssertの正しさを検証する、ということをやっていました。
ただこれをルール化などはしたことがなかったので、自動テストを書く個人によって、やっていたりやっていなかったり、が分かれるかもしれません。