自動テスト（E2Eテスト）は初期開発工数だけでなく、仕様変更に伴う修正工数が継続的に発生します。そして、闇雲に全てのテストを自動化すると自動テストの修正工数が膨大となり、やがて自動テストのメンテナンスが追いつかなくなります。そのため、自動テストのテスト内容は費用対効果を考えながら厳選していく必要があります。
そこで、本記事では私の考えた自動テストの目的に応じた自動テストのテスト内容の選び方をご紹介致します。自動テストの目的は複数持っても構いません。セキュリティや性能のテストは本記事のスコープ外です。
なお、本記事では触れませんが、手動テストにとって効率的なテスト手順は自動テストにとって非効率な場合が多いのでご注意下さい。*1*2
目次
自動テストの目的
手動テストの工数削減、リリース頻度の増加
自動テストとして最初に思い浮かぶ目的が手動テストの工数削減です。手動テストの工数削減の効果は、今までのプロセスにおける工数を削減できるだけではありません。手動テスト工数を気にせず沢山実行できるというメリットがあります。
例えば、リリース前に必ず実施するリグレッションテストがあったとします。手動でリグレッションテストを行う場合は、リリース頻度を増やすとリグレッションテストの工数も増加してリソース不足になるため、リリース頻度を抑えて複数のチケットをまとめてリリースすることになります。
リグレッションテストを自動化した場合は、リリース頻度を増やしても手動テストの工数が増加しないため*3、リリース頻度を増やすことができます。リリース頻度を増やせると、テストが完了したチケットは他チケットのテスト完了を待たずにリリースできます。その結果、他チケットのテスト完了待ちによる機会損失が減ります。
なお、手動テスト工数削減の対象はリグレッションテストに限った話ではありません。
テスト漏れをカバーする保険
こちらは自動テストに限らず、手動のリグレッションテストにも当てはまる話です。
修正の影響範囲の考慮漏れなどによって、実装時やテスト設計時に考慮していなかった既存機能に欠陥が混入する場合があります。 そういった考慮漏れがあることを前提に、念の為重要な既存機能を毎回テストします。 そうすることで、実装やテスト設計時の考慮漏れによる欠陥を検出できたり、欠陥が検出されなかったとしても安心してリリースができるようになります。
欠陥混入時に生じる工数やリードタイムの削減
上記のテスト漏れをカバーする保険としてのリグレッションテストは、考慮漏れが生じない限り欠陥を検出しません。そのため、上記リグレッションテストを手動で実施する場合は、欠陥を検出する可能性が高いテストよりも後に実施することになりがちです。*4
仮に開発者とテスト担当者が別の場合で、後半で実施されるリグレッションテストで欠陥を検出した場合、以下のような作業が必要になります。
- 他の作業から欠陥の修正作業にタスクを切り替えることによるスイッチングコスト
- 欠陥を混入したチケットの内容を思い出す時間
- テスト担当者から開発者への欠陥の再現方法の伝達といったコミュニケーション
- 欠陥を修正した後のコードレビュー
- テスト担当者の修正確認、および、修正後のリグレッションテスト
- 欠陥の修正に起因するリリース日の調整
もし、リグレッションテストが自動化され、開発者自身が実装直後（コードレビューやテスト担当者にテストを依頼する前）に自分でリグレッションテストを自動で実行できれば、上記作業が不要になる可能性があります。
自動テストの目的に応じたテスト内容
手動テストの工数削減
削減工数（テスト実施工数 × テスト実施頻度）が大きくなるテスト
手動テストの工数削減を目的とする場合は、
削減工数 = テスト実施工数 × テスト実施頻度 *5
で計算した削減工数の大きいテストを優先して自動化します。
ただし、E2Eテストの中には自動化しにくいものも多々あるため、自動テストの開発工数も考慮に入れます。
自動テスト以外の手動テスト工数削減方法も検討する
手動テスト工数の削減方法は自動化だけではありません。 例えば、以下のようなものがあります。
これらの施策は自動テストの開発・運用効率も向上しますので、自動テストを開発する前にぜひ検討しましょう。
テスト漏れをカバーする保険
テスト漏れがよく発生するテスト
過去の不具合分析、テスト対象の仕様の複雑さなどからテスト漏れがよく発生するテストを洗い出します。
重大な損失をもたらす欠陥を検出するテスト
過去にテスト漏れが発生していない機能でも、将来テスト漏れが発生する可能性があります。 そのため、欠陥が生じると重大な損失をもたらすような機能については、テスト対象とすることを検討します。
テスト対象やテストの手厚さについては
リスクの大きさ = 欠陥混入時の損失 × 欠陥混入の確率
に応じて検討します。
欠陥混入時に生じる工数の削減
欠陥を多く検出できるテスト
過去の不具合の傾向、コミットが多い機能、仕様の複雑さ、他機能との依存関係、今後改修が見込まれる機能など分析し、将来的に欠陥が多く混入しそうな機能を洗い出します。
テストレベル（E2Eテスト, APIテスト, ユニットテスト）の選択
テストピラミッドは有名になってきたので詳細は説明しませんが、基本的に同じ内容のテストができるならば、開発に必要なコストは
と言われています。*7
可能ならば、金額の計算といったロジックはユニットテストに任せて、E2Eテストではシステム間連携やブラウザ上の操作といったE2Eテストでしか確認できないテストを行いましょう。
おわりに
自動テスト（E2Eテスト）を拡充すると近い将来メンテナンス工数不足に陥ります。そのため、上記の中で優先順位の高いものから順番に自動テストを拡充していき、自動テストの費用対効果を見極めながら最低限の自動テストを運用していくと良いと思います。
また、目的に沿った効果測定方法を準備しておき、自動テストが期待する効果を出しているかも測定すると良いと思います。
本記事では、自動テストの目的に応じたテスト内容の選び方を紹介しました。 自動テストの目的やテスト内容の選び方はこれで全てではありませんので、以下の記事なども参考にしながら皆さんも検討してみて下さい。
参考記事
ISTQBテスト技術者資格制度 Advanced Level Specialist シラバス テスト自動化エンジニア 日本語版 Version 2016.J01
