踏み出せないWeb画面の自動テストを導入する。contentなかなか踏み出せないWeb画面の自動テストを導入する。稼働が始まってしまっているサービスで、Web画面の自動テストを導入するのに躊躇しているあなたにお届けします。自動テストを導入してみようかなと思って貰えること。はじめに既に稼働してしまっているサービスに対して自動テストを導入するのって、途方もない膨大な仕様や機能がわかっているだけに躊躇してしまいますよね?確かに完璧なテストを目指すとそれだけテストコードを準備しなければならないし、テストコードのメンテナンスも大変です。私もそんな風に悩んでいたうちの一人でしたが、ミニマルから導入して結局は良いことが多かったので皆さんにもオススメしたいと思います。まで順番に私が導入した自動テストケースを記載するので、明日からのミニマルスタートの参考にしていただければ幸いです。前提レガシーな技術で作成されたWebサービスのプロジェクトに、途中参画したときのお話です。アクセスで、正常なステータスコードが返ること。アクセスで、想定されるタイトルが返ること。フッタやヘッダなど共通部品が表示されていること。導入について仕様変更が多く、納期も短いこともあり、サーバの共通ロジックに変更があった時に結合テストで修正対象でない画面で不具合が発見されることが多々発生していたため、最低限の自動テストを導入しました。この自動テストの導入のおかげで、結合テストでの発覚はほぼ0となりました。2導入したテストケース画面特有の項目のうち、静的でない項目が想定通り表示されていること。画面上の静的リンクが正常に機能していること。導入について自動テストの仕組みが整ったため、重要な画面から少しずつ自動テストを追加していきました。1番は機能変更によるデグレを防ぐための自動テストで、この導入前後で結合テスト不具合発生頻度が目に見えて下がりました。2番については機能削除などでリンク先がなくなったケースで見逃しやすい不具合だったため導入しました。3導入したテストケーススタイルが適用されていること。導入についてデザインと機能を分業しているため、最終的に組み込んだあとに機能は問題がないがスタイルの適用に問題があるという不具合が何件か発生していたため導入しました。スタイルシートが正しく読み込まれていることの確認だけをおこなっていますが、不具合となるケースが大幅に減りました。4導入したテストケース正常な入力で画面遷移ができ、正常なステータスコードが返ること。異常な入力で画面遷移ができ、異常なステータスコードが返ること。異常な入力で画面遷移ができないこと。導入についてデグレ防止のために導入しました。導入することで不具合発生が減ったことはもちろんなのですが、特にテストに手間のかかる異常系の自動テストは、何故最初から導入していなかったのかと後悔するほどに工数の軽減を感じました。パターンでも用意すれば良いという気持ちで望むほうが良いと思います。自動テストパターンを増やすと費用対効果は下がっていくが安心感は増える。5導入したテストケース入力項目のバリデーションを確認する。入力項目のバリエーションを確認する。導入について入力項目のバリデーションの確認や、入力のバリエーション確認を一部画面にも導入しました。効果は確かにありますが、テストコードが多くなりメンテナンスが大変という印象でした。6導入したテストケース画面入力と、その結果の出力がサービスの仕様通りであるか確認する。導入について複数の画面に跨る、サービスの仕様確認を一部機能に導入しました。プロジェクト特有の問題だったのかもしれませんが、サービスの仕様変更が入るたびにテストコードを大きく作り変える必要が多かったことから、サービスの仕様に直接関連するような自動テストはおこなわなくなりました。小まとめ私のプロジェクトでは、全てが自動化とはならずコストも大きく削減できたわけではありませんが、結果として同じコストで出来上がるプログラムの品質は大きく向上しました。テストコードが急激に増えていくことと、仕様変更のたびにそれをメンテナンスするコストとで費用に見合った効果は感じ難いと思います。お金で安心を買える状況であればこちらも自動化を進めた方がよいと思いますが、個人的にはプロジェクト状況によりけりだと考えています。まで比較的簡単に導入できる内容のため、どんなプロジェクトでも今スグにでも導入したほうが良いと思いますので、この記事が皆さんの導入のきっかけとなれば幸いです。ご静聴ありがとうございました。requestStockLike47@t-toyotaプログラムをする人です。upLoginユーザーは見つかりませんでした。