この記事では、複数のプロジェクトでE2Eテストの構築に関わった経験から、E2Eテストの「目的」と「粒度」はどうあるべきか。個人的な主観を書いていきます。これからE2Eテストに取り組む方や、テストの粒度を決めかねている方の参考になれば幸いです。
※この記事は、技術的な事実ではなく私の主観を述べているため、他の記事とは表現を変えています。
E2Eテストの目的の決め方
E2Eテストの目的は、開発チームがテストに対する共通認識を持つために大切なことです。
「何のためにテストをやるのか」
これを決めることがE2Eテストの第一歩です。
E2Eテストの目的は、大きく分けて以下の2つだと私は考えています。
- あるべき振る舞いの担保
- 検証効率の向上
1. あるべき振る舞いの担保
これは、ソフトウェアの品質とは少し違います。
アプリケーションの動作に焦点を当てたものです。
アプリケーションがどのように動作していると正解なのか。
これを担保するためにE2Eテストは必要です。
アプリケーションの正しいシナリオ、間違っているシナリオをE2Eテストとして実装していれば、新機能の開発、既存機能の改修時に、影響範囲を素早く検証することができます。
事例を挙げると、
特に既存機能の改修については、思わぬバグを引き起こすことがあります。アプリケーションのソースコードは膨大なので、開発期間が長くなると、「どこに何があるのか」を完璧に把握することは難しくなります。
その結果「機能を改修した時に、全く関係のない箇所でエラーが起きる」という現象が発生することがあります。手動の検証で影響範囲を検証するには膨大な時間がかかりますし、抜け漏れもあります。
しかし、自動テストであれば、人間の意図に関係なく全ての検証を行えるため、あるべき振る舞いを担保できるのです。
2. 検証効率の向上
上記で述べた「アプリケーションのあるべき振る舞い」を、毎回手動で確認するのは大変です。
しかし、多くのチームがテストを自動化していないので、毎回のリリースのたびに手動&目視検証に多くの時間を使っています。
「間違い探し」は人間が苦手な分野の一つです。特に、時間が長くなれば長くなるほど、検証の質は下がります。これが、手動でテストを行う際のリスクです。
自動テストであれば、プログラムでテストを走らせれば、すべての画面のあるべき動作を検証し、問題がある場合にのみエラーで通知してくれます。
時間に換算すると、1/100くらいの時間でテストが完了します。
これが、検証の効率化です。
アプリケーションのあるべき振る舞いを担保し、検証時間を最小化することが、E2Eテストの目的です。
E2Eテストの粒度の決め方
では、テストの粒度はどのように決めていけばいいのでしょうか？
以下のステップに沿えば、設定すべきテストの粒度が見えてきます。
- 発生している問題や課題を調査する
- 開発チームの問題
- アプリケーションの問題
- E2Eテストで何を解決するかを決める
- 問題を解決するためのテストを作る
それぞれ解説していきます。
1. 発生している問題や課題を調査する
大切なことは、テストありきでテストを作らないことです。
「テスト自動化、そろそろやらないとな」
というようなノリではいけません。
アプリケーションや組織で発生している問題に焦点を当て、
問題を解決するための手段としてE2Eテストを実装していきます。
例えば、リリースのたびにバグが出てしまう。
つまり、アプリケーションの品質に問題がある場合。
この場合、そもそもアプリケーションの正しい振る舞いを開発者が理解していないか、検証で見落としているかのどちらかです。
であれば、アプリケーションの正しい動作を細かくテストに落とし込む必要があるでしょう。
一方で、すでにアプリケーションは安定して稼働しており、
定期的なリリース時に、他の機能に問題がないことを確認したい場合。
この場合だと、アプリケーションの品質を細かくチェックする必要はありません。
Playwrightのスクリーンショットの機能を使って、
開発前と開発後のキャプチャに差異がないことを確認できればいいでしょう。
もしキャプチャに差異がある場合は、表示が変わっているということなので、
影響が出ていることがわかります。
このように、発生している問題や要望によって
E2Eテストの粒度は変わってきます。
まずは、組織やアプリケーションがどのような問題を抱えているかを知ることが、E2Eテストの粒度を決める第一歩です。
2. E2Eテストで何を解決するかを決める
E2Eテストは、すべての問題を解決できる魔法のツールではありません。
上記で、発生している問題を知ることが大切だと話しましたが、
「E2Eテストで何を解決するか」
をこのステップで見極めます。
具体的なイメージを持っていただくために、
ケースを用意しました。
以下のような２つの問題を抱えている組織の場合、
どのように優先度を決めていくべきでしょうか。
- アプリケーションの品質が悪い
- UI検証を効率化したい（デバックチームの人件費を削減したい）
判断基準は、
「他の手段で代替できないか」
です。
上記の場合、UI検証を効率化したいという要望に対しては、E2Eテストが最も効果的だと考えられます。
しかし、アプリケーションの品質についてはE2Eテストでカバーできない可能性が高いです。
アプリケーションがあるべき振る舞いをしていない原因は、フロントエンドの内部ロジックやAPIの処理に問題がある可能性が高いため、コンポーネントテストやユニットテストなどの、内部実装に焦点を当てたテストが必要かもしれません。
なので、アプリケーションの品質（内部ロジック）については、
E2Eテストで関与しないという判断ができます。
これにより、E2Eテストでアプリケーションの内部ロジックに関与するような厳しすぎるテストを書く必要もなくなり、「E2Eテストで何を解決するか」が明確になります。
3. 問題を解決するためのテストを作る
ここまで、テストの目的と粒度の決め方について解説しました。
最後に、テストを実装する際の注意点を説明して終わりにします。
それは、
「必要以上のことをやらない」
です。
開発者である以上、プログラミングをしていると
どんどん実装を詳細にしてしまいがちです。
例えば、以下のようなテストの粒度があった場合。
E2Eテストでは、最低限の表示検証とスクリンショットの撮影/比較を行う。
この場合、必要以上にアサーションを使ったり、
コンポーネントテストレベルの検証を行ってはいけません。
粒度に沿って、テストを実装するべきです。
テストの方向性や品質に一貫性を持たせるために「目的」と「粒度」を決めているので、その粒度を無視してしまうとテストをやる意味がなくなります。
テストを実装する際には、「どの粒度でやるのか」を常に意識し、テストの品質がバラバラにならないように注意すべきですね。
まとめ
この記事では、E2Eテストにおける「目的」と「粒度」の定め方について、実際のプロジェクト経験を踏まえて解説しました。E2Eテストは、アプリケーションの正しい動作を担保し、効率的な検証を実現するための重要な手段です。そのためには、テストの目的を明確にし、適切な粒度を設定することが不可欠です。また、E2Eテストが解決できる問題とそうでない問題を見極め、必要以上のテストを実施しないことも大切です。これらのポイントを意識して、テストの品質と効率を最大化していきましょう。参考になれば幸いです。
この記事は役に立ちましたか？
もし参考になりましたら、下記のボタンで教えてください。
コメント