特にGUI操作を行うテストの文脈において、自動テストは一度作ればずっと使い続けられる類のものではありません。日頃から保守のタスクが発生し、都度改修していく必要があるものです。

では、どういったタイミングで自動テストの改修作業が必要になるのでしょうか。

ツールのバージョンアップ時

テスト自動化に用いているツールや言語、ライブラリ等にアップデートがあれば、自動テストの改修が必要になる可能性があります。

私が経験したことがあるタイミングとしては、商用のテスト自動化ツールのメジャーバージョンアップのタイミング。ツール側に機能追加などがあると、過去に作成した自動テストの動作が一部（ツール開発元が予期していないものも含めて）変わってしまう場合があります。

また、テスト自動化ツールのバージョンが大きく変わった場合にはツールのUIも変わる場合があるため、コードの変更だけでなく操作方法の再学習や慣れといった、ある意味保守と言ってもいいようなタスクが発生し得ます。

他にはJUnit4からJUnit5への変更などもありました。こちらは関連する他のライブラリ（具体的にはHamcrest）なども細々と変更しなければいけなかったので、手間がかかりました。。

テスト対象・テストの変更時

テスト対象に変更があった場合や、テストそのものに変更があった場合も改修が必要です。こちらは自動化ツール関連の変更よりも頻度が高く、自動テストの保守作業としては一番割合の大きい作業となるでしょう。

画面の要素に変更が入った場合などは影響も大きいため、全体的な改修と再実行が必要になることもあります。

SeleniumであればPageObjectデザインパターンを取り入れたり、UFTやKatalonなどの商用ツールであればObjectRepositoryをうまく使うことで、画面要素の変更に対する改修コストを低めに抑えることができます。

低めに抑えることができる、と言ったのは、保守性を高める仕組みを取り入れたからといって、コストをゼロにはできない、という意味合い。また、これらの仕組みを取り入れた場合でも、テスト対象のもとの作りが複雑になってしまっていたら、自動テストも影響を受けて複雑になってしまいがちです。くれぐれも自動テスト側「だけ」の工夫でなんとかしようとせずに、テスト対象となるシステムそのものを綺麗にしていく努力をお忘れなく。

実行環境のバージョンアップ

OSやブラウザのバージョンが上がったとき、です。OSの場合、特にWindowsはOSのバージョン変更によるインパクトが大きくなりがちです。自動テストの改修にもそれなりの期間を確保しておきましょう。

座標による位置指定でのテスト自動化を行っていたときは、WindowsXPから７に変わったことでメニューバーのサイズが変わり、位置ずれがひどくて泣きそうになりました。余談ですが。

まとめ：テスト自動化の費用・工数効果の試算時には、保守コストをお忘れなく

一般的にこのくらいですよ、というのが言えればいいのですが、こればかりはテスト対象や組織などによってバラバラです。

が、保守のためのコストというのは試算から漏れがちです。手動テスターの工数と自動テスト実行時間だけを比べて「よし導入だ」と踏み切ると、想定より大幅に時間がかかってメンバーが苦労することになってしまいます。上記に挙げたものを含めて、自動テストの改修が発生するタイミングを細かくリストアップして計算しましょう。

（その場合でも、テストを自動化することによるメリットを単純に時間や人月コストだけだと思わないでほしいなぁ、という気持ちもあり。この辺は別記事に書きます。）