私は職種上、よく「自動テスト or E2Eテストはどうしてますか？」と聞かれることがあります（ここでいう自動テストはE2Eテストのことをさしており、E2Eテストは自動テストでおこなうことを暗黙的にさしています）。

E2Eテストにしろ、単体テストにしろ、人によってイメージするものは異なると思いますが、ここではE2Eテストはユーザが操作する相当のことをおこなうことをイメージしてもらえればよいです。

毎度書くのも大変なので、これ以降はE2Eテストと明記した場合は上述した内容の自動テストの話になります。

私は、過去にその手の話でよく登壇していましたし、本の執筆もしましたし、実際よく実装もしていました。

モバイル領域においては特にE2Eテストを「どうやって」がなかなかむずかしく注目されやすい時期でした。

コードの実装方法にしろ、コードを動かす実行環境にしろ技術的に難しい点がいくつもあったからというのもあります。

この「どうやって」を広めるためにも、試してもらうことにフォーカスしてアウトプットしていた側面もあります。

結果として「どこに」とか「なにを」という視点をメインとしたアウトプットはそこまで多くなかったようにも思えます。

しかし、あれから時間もたちいろいろと変化してきました。
今はE2Eテストを「どこに」とか「なにを」という視点での活用を考える必要性が高まっているように思えます。

ノーコードサービスの台頭や自動テストの一般化

E2Eテストの導入の難易度というのは以前と比べて下がってきています。

昨今、E2Eテストのためのサービスやツールはいろいろとあります。

モバイルサービス向けに目を向けるとノーコードサービスでいえば「Autify」「MagicPod」などがあります。

テストコードを実装するというやり方であれば、公式から提供されているTesting Frameworkを利用するだけでなく「Appium」や「Maestro」「Aritest」といったツールもあります。

Testing Frameworkを活用した事例も含め、上述したものを活用したブログ記事を目にしたこともあるでしょう。

ベースとなるTesting Frameworkの年月を重ねての変化やそれを用いた上述したサービスやツールによって、モバイルサービスにおいても以前と比べてE2Eテストの導入難易度は下がってきており、一部においては一般化してきているのではないかと思います。

また上述したE2Eテスト以外のテストレベル/テストサイズの自動テストにおいてはそれ以上に普通に実装されるようになってきているのではないかと思います。

自動テスト全般の「どうやって」の難易度が下がってきたからこそ「なにを？」「どこで？」「どこまで？」テストするのかにフォーカスした視点がより必要になってきていると思います。

E2Eテストの目的とは？

テストは開発ライフサイクルの中のいろいろなところでいろいろな手段でおこなうことが望ましいです。

E2Eテストはそのいろいろあるテストの１手段です。

したがってE2Eテストの「どこで守るか」ではなく、プロダクトを見たときに「なにを？」「どこで？」「どこまで？」「どうやって？」守るかといったように全体的な視点で考える必要があるはずです。

しかしE2Eテストを「出発点」として、そしてそれを主軸として考えているケースがよくあるように思えます。

出発点となりがちなのがE2Eテストに「手動テスト」の代替を期待するケースが一定あるからだと思います。

そこには暗黙的に手動テストを用いたテストが主軸になっているということもあるかと思います。

手動テストの工数削減というアプローチ

E2Eテストはよく手動テストの削減という意味でのアプローチとその効果が語られることがあります。

このアプローチは普段から触っているものの延長にあるため分かりやすいというのがあります。

このアプローチにおける導入事例には定量的な数字として「手動テストのx割を削減」といった文言が書かれているケースがしばしばあります。

手動テストの削減という効果があるのも事実ですし、結果として導入事例や運用事例といったノウハウが増えたのも事実だと思います。

一方、こういったアプローチは不要にE2Eテストのテストケースを増やすことにも繋がります。

E2Eテストを導入し、そのようなテスト基盤が用意されるとテストケースを増やしやすくもなり「設計があまい」テストケースが増えるのはよくある話です。

結果として運用コストが増えてしまい十分な価値を発揮できない、発揮できなくなるケースもあります。

全体で守ることを考える必要性と重要性

どういったアプローチをとるにせよ、全体で守るためにもE2Eテストはどこで活用するべきか？といったことを考えることは重要です。

テストピラミッドで言われるようなx割がE2Eテストであるというアプローチは最終的にたまたまそうなっていることもあるのであって、x割を目指すことが全体で守るという方法ではありません。

そのためには「どうしてそのテストを用意するのか」「用意する必要があるのか」「結果として何が守れるのか？」といった考えが重要です。

それを考えるには前提として「そのE2Eテストでなにができるのか」「対象プロダクト」について理解しておく必要があります。

さらには「開発者テスト」という言葉ゆえに断絶を作ってしまっているように思えますが、そう呼ばれるテストも含めて知ることで全体で守ることを考えることが重要です。

知るべきことは多く大変かと思います。

これらのいろいろな手段を通して「どこで守れるか、守るか？」といったことを考えることが大事です。

さらに「対象プロダクト、対象機能の特性」というものに応じつつ考える必要があります。

これを進めていく根底には「テスト設計」が重要になってくる認識です。

これらを駆使することで「全体で守るにはどうすることができるか」といった考えができる一歩になるであろうと思います。

これをすすめようとする際の難易度は守るべきプロダクト、そして機能の特性にも依存するはずです。

とはいえ、なにか1つの手段に頼るのではなくて、より深く対象とその周辺を理解した上で、全体を守れるように考えていくスキルをより磨いていきたいと私自身も思う日々です。

（蛇足） 全体という事を考えたときの広さ

蛇足になってしまいますが、ここまでに話した内容はあくまで全体で守るを考えたときの1局面でしかないです。

E2Eテストを起点としてブログ記事を書いたので、自動テストよりの話を書いたわけですが、全体で守るということを考えると別に自動テストの手段以外もいろいろとあります。

われわれは「プロダクトをより良く」しようとするわけですが、自動テスト以外の手段も日々活用してるでしょうし、他のまだ活用できていない手段も多くあると思います。

今以上の広さを扱えるように日々なにをするべきか、できるかを考える必要があるなとつくづく思うのです。