なかなか踏み出せないWeb画面の自動テストを導入する。

概要

既に稼働が始まってしまっているサービスで、Web画面の自動テストを導入するのに躊躇しているあなたにお届けします。

目的

自動テストを導入してみようかなと思って貰えること。

はじめに

既に稼働してしまっているサービスに対して自動テストを導入するのって、途方もない膨大な仕様や機能がわかっているだけに躊躇してしまいますよね？
確かに完璧なテストを目指すとそれだけテストコードを準備しなければならないし、テストコードのメンテナンスも大変です。
私もそんな風に悩んでいたうちの一人でしたが、ミニマルから導入して結局は良いことが多かったので皆さんにもオススメしたいと思います。
今回は、LV 1 〜 6 まで順番に私が導入した自動テストケースを記載するので、明日からのミニマルスタートの参考にしていただければ幸いです。

前提

レガシーな技術で作成されたWebサービスのプロジェクトに、途中参画したときのお話です。

自動テストケース

LV 1

導入したテストケース

1. 指定した URL へのアクセスで、正常なステータスコードが返ること。
2. 指定した URL へのアクセスで、想定されるタイトルが返ること。
3. フッタやヘッダなど共通部品が表示されていること。

導入について

仕様変更が多く、納期も短いこともあり、サーバの共通ロジックに変更があった時に結合テストで修正対象でない画面で不具合が発見されることが多々発生していたため、最低限の自動テストを導入しました。
この自動テストの導入のおかげで、結合テストでの発覚はほぼ０となりました。

費用対効果 : 高

LV 2

導入したテストケース

1. 画面特有の項目のうち、静的でない項目が想定通り表示されていること。
2. 画面上の静的リンクが正常に機能していること。

導入について

自動テストの仕組みが整ったため、重要な画面から少しずつ自動テストを追加していきました。
1番は機能変更によるデグレを防ぐための自動テストで、この導入前後で結合テスト不具合発生頻度が目に見えて下がりました。
2番については機能削除などでリンク先がなくなったケースで見逃しやすい不具合だったため導入しました。

費用対効果 : 高

LV 3

導入したテストケース

1. スタイルが適用されていること。

導入について

デザインと機能を分業しているため、最終的に組み込んだあとに機能は問題がないがスタイルの適用に問題があるという不具合が何件か発生していたため導入しました。
スタイルシートが正しく読み込まれていることの確認だけをおこなっていますが、不具合となるケースが大幅に減りました。

費用対効果 : 中

LV 4

導入したテストケース

1. 正常な入力で画面遷移ができ、正常なステータスコードが返ること。
2. 異常な入力で画面遷移ができ、異常なステータスコードが返ること。
3. 異常な入力で画面遷移ができないこと。

導入について

デグレ防止のために導入しました。
導入することで不具合発生が減ったことはもちろんなのですが、特にテストに手間のかかる異常系の自動テストは、何故最初から導入していなかったのかと後悔するほどに工数の軽減を感じました。
ここからはテストコードを準備するのに結構なコストを要するため、ある程度割り切って正常・異常で各 １ パターンでも用意すれば良いという気持ちで望むほうが良いと思います。

費用対効果 : 高
※ 自動テストパターンを増やすと費用対効果は下がっていくが安心感は増える。

LV 5

導入したテストケース

1. 入力項目のバリデーションを確認する。
2. 入力項目のバリエーションを確認する。

導入について

入力項目のバリデーションの確認や、入力のバリエーション確認を一部画面にも導入しました。
効果は確かにありますが、テストコードが多くなりメンテナンスが大変という印象でした。

費用対効果 : 小

LV 6

導入したテストケース

1. 画面入力と、その結果の出力がサービスの仕様通りであるか確認する。

導入について

複数の画面に跨る、サービスの仕様確認を一部機能に導入しました。
プロジェクト特有の問題だったのかもしれませんが、サービスの仕様変更が入るたびにテストコードを大きく作り変える必要が多かったことから、サービスの仕様に直接関連するような自動テストはおこなわなくなりました。

費用対効果 : 小

まとめ

私のプロジェクトでは、全てが自動化とはならずコストも大きく削減できたわけではありませんが、結果として同じコストで出来上がるプログラムの品質は大きく向上しました。

LV 4　のバリエーションを増やしたり LV 5 以降をしっかりやろうと思うと テストコードが急激に増えていくことと、仕様変更のたびにそれをメンテナンスするコストとで費用に見合った効果は感じ難いと思います。
お金で安心を買える状況であればこちらも自動化を進めた方がよいと思いますが、個人的にはプロジェクト状況によりけりだと考えています。

ただ個人的な感想としては、LV 1 〜 4 まで比較的簡単に導入できる内容のため、どんなプロジェクトでも今スグにでも導入したほうが良いと思いますので、この記事が皆さんの導入のきっかけとなれば幸いです。

ご静聴ありがとうございました。