先日、社内で「自動End2Endテスト(以降E2Eテストと略します)を作成する基準ってありますか?」と質問されて、そう言えば明文化したことなかったし、自分以外の人がどんな基準を持っているの知りたいので久しぶりにブログとして、私が基本的に考えている基準を書いてみることにしました。(ブログ書くの2年ぶりくらいじゃなかろうか…)
皆さん、どんな基準でE2Eテストを作るようにしていますか?
前提
- ここでの基準は、ある確認したいことを手動で確認するか・自動テストで確認するか、どちらの方法で確認するかを判断する基準とします。自動テストを増やしていく際の話ではないです。
- ここではあくまで基本的な基準を考えます。実際のソフトウェア開発している中では、あるときにお客様にお渡しできないと意味がないなど様々な状況がありますが、それらは今回の基準を元に実際の状況を加味して考えるものとします。
- ここでのE2Eテストは、システムを利用するお客様の利用の流れの1つを、お客様が利用するシステムのインターフェースを利用し、システムの使い始めから利用終わりまで確認するものとします。つまり、利用の流れによってはクリティカルなものとそうではないものが存在する確認事項となります。
- ただし、お客様に確認を委ねても問題とならない確認事項はここでは対象外とします。
- テスト対象のシステムは、継続的に開発がおこなわれ日々お客様へ新しいバージョンがリリースされるもとのします。
- テスト対象のシステムは、ブラウザやモバイルアプリなど自分たちではコントロールしきれない不確定要因を含むシステムとします。そのため、E2Eテストは不安定性を含むものとします。
基準
- そのテストで確認している流れにエラーがあった場合、システムが利用できないまたは重大な不具合となる確認事項はE2Eテストで確認する。ただし、基準その2を満たした上で。
- 単体テストや結合テストで確認できるモノはE2Eテストでは確認しない。それら単体テストや結合テストで確認する。
それぞれの基準の背景
基準その1の背景
- 頻度が多かろうが少なかろうが高レベル障害はお客様にとっては困る事態なので、個々にE2Eテストを作るか否かの判断をする際には、頻度は考慮しません(起きたら困ることは自動テストだろうが手動テストだろうか確認されますよね?)。
- E2Eテストで難しいテストは、多くの場合手動でもめんどくさく、そのようなテストは実施されないことがあります。それは大きなリスクですので、テストの難しさもほぼ考慮しません。
- 継続して開発し、かつ高頻度でリリースされる中において、繰り返し実行する必要のないテストは存在しません(キャンペーンのような期間限定のモノでも、その期間中でも何回もリリースがあり、その影響がないことを確認したいですよね?)。
このような背景のため、システムが利用できないまたは重大な不具合となる確認事項はE2Eテストで確認することを考えます。
その中で、より安定的にかつ高速にE2Eテストを動かすために、すべての確認したいことをE2Eテストで確認するのではなく、重大な不具合を確認するテストのみ、E2Eテストとして作成すると良いと考えています。軽微な不具合となる多くの場合が重要な流れから派生した確認事項で、単体・結合テストで確認できるはずですし。
基準その2の背景
E2Eテストはその造り上、どうしても遅く不安定性を含みます。一方、テストによるフィードバックは早くおこなえると効果が高いです。そのため、極力、単体テストで確認することができないか検討するようにしています。単体テストで難しいことを確認したい場合は結合テストで確認できないか考える形で。
そのように、どこで確認すると良いかを考える際には、Katrina Clokieの著書”A Practical Guide to Testing in DevOps”中の図(下記の図)をイメージするようにしています。 すなわち、E2Eテストを独立として考えるのではなく、単体・結合・総合・E2E・手動テストなど全体でどう確認するかを設計すると良いを考えています。
まとめ
こんな感じに私はE2Eテスト作るか否かの判断基準を考えています。 この場合どうするの?とか、いやいやそうじゃないでしょ?などありましたら、コメント頂けると嬉しいですー!