「デザインが変わっただけ」でもスクリプトの修正が大変
3つ目の事例は「テスト実行が遅く、仕様変更時の修正が大変な現場」。顧客へのヒアリングにて「最近テスト実行に時間がかかって困っている」との声があがった。テストケースのステップ数が多いのか尋ねたら「画面数は数個で、UIが少し変更された程度だが、スクリプトの修正が非常に大変」とのことだった。大幅な機能変更の有無を問うと「デザインやメッセージが変わっただけ」との回答を得た。
詳細を調べたところ、テスト対象は問合せフォームで、文字列を入力し送信するページだった。テストスクリプトではデザインの検証に加え、フォームへの入力値やメッセージのチェックを行っていた。デフォルト値のチェックや、入力必須のアラートが出るかのバリデーションも行い、最後にテキスト入力をするなど、多岐にわたる検証を行っていた。
テストの実行が遅くなり、仕様変更時の修正が多くなる原因として考えられるのは、テキストの正確性などを確認するステップが多すぎることだ。また、UI検証が多いため、デザインやメッセージが少し変わるだけでも大きな影響が出てしまう。さらに、テスト自動化の目的や基準が明確でないことも原因の一つと考えられる。
解決策として、テスト自動化の目的と基準を見直すことを提案した。テスト自動化は何を目的として行うのか、その点から再検討することが重要だ。手動テストをそのまま自動化した場合、広範なテストが可能であるが、その分細かなチェックが増え、実行時間も長くなる。一方で、リグレッションテストに重点を置く場合、テキストやデザインの不具合を見逃す可能性はあるものの、機能に特化したテストを行うことで非常に効率的なテストが可能となる。テスト自動化の目的次第で、運用コストなどを加味したテスト基準を定めたい。
江村氏は最後に「テスト自動化は、構築よりも運用フェーズでいろいろな課題が出てきます。それ（課題をそのままにした状態）に慣れるのではなく、課題を認識し改善していくことが、テスト自動化を長く運用しつづける続けるコツです」とコメントした。
テスト自動化はツールに任せ、運用の課題改善に注力しよう
本セッションを振り返ってみると、テストの自動化が本当に効力を発揮するには、自動化そのものより運用フェーズが重要であることがよくわかる。特に、最近では各種ツールも出そろっており、中には非エンジニアでも扱えるものも多い。自動化はツールに任せ、エンジニアは運用フェーズの改善に注力するのも良いだろう
例えば冒頭で紹介された「T-DASH」では、インストールすればすぐ使えて、非エンジニアでも簡単にWebアプリケーションの動作確認・検証ができる。チュートリアルページも充実しているので自走も期待できる。そのほかにセミナーなども毎月開催されており、公式HPに集約されている。
気になった読者は、覗いてみてはいかがだろうか。
