ユーザ受け入れテストでレガシーコードと戦っていく

レガシーコードとは、レガシーコード改善ガイドを参考にすると、テストのないコードを指しています。コードだけでなくレガシーなシステムも存在し、レガシーじゃないシステムよりレガシーシステムのほうが多いので、新しい要求への対応と、レガシーコードの改善をうまくやっていくスキルが求められるのではないかと思います。今日は、うまく戦っていく手段について考えてみました。

レガシーシステムでの問題

自動化されたテストのない現場にいたときに、以下の問題に直面しました。

レグレッションテストに時間がかかる
何をもって「ちゃんとテストした」のかがわからない

結果的に、リリース作業時間が長くなり、リリースにかけるコストが大きく膨れたり、テストを網羅しきれず、トラブルが継続的に発生してしまうというダメージを受けてしまいます。

1については、新しく追加した機能のテストはできても、追加した影響範囲まで特定できず、別の所で問題が発生しトラブルが起きてしまうパターンです。

2については、手作業テストで使ったテスト仕様書が管理されておらず、「過去のテストを1回流す」ことができないため、各自の裁量でテストを選択したり作ったりした結果、人に依存する問題が発生し、上と同じようにトラブルに繋がってしまうパターンです。

自動受け入れテストの導入

あるとき、この問題に対して、全体的なテストを作成し、テストでシステムを包み込んでいく方法を取りました。「テストハーネス」という言葉があるみたいですが、ハーネスという言葉は、この解決案の考えにとても近い言葉だと思います。

全体的なテストの定義は、Webサービスがテスト対象なので「画面テスト」としました。画面は最終的にユーザが見て操作するものなので、ユーザ受け入れテストと呼んでいます（User Acceptance Test：UAT）。画面テストを自動化する手段として、WebDriverを使いました。

テストを観点（シンプルでよく使われる機能、複雑であまり使われない機能など）でカテゴライズし、優先度の高いものから自動化して行きました。そして、Jenkinsサーバで定期的（1日1回早朝）に動かしながら様子を見ました。WebDriverはブラウザを起動して使うせいか不安定な時があるのですが、しばらくは良い感じでシステムをテストで監視することができるようになりました。