テスト自動化で地獄を見る　失敗事例から見た成功例のポイント

効率化・省力化を目指してテスト自動化に取り組んでみたものの、かえって手間が増えてしまったという失敗を聞いたことはありませんか？本記事では自動化を目指したが力及ばず、失敗してしまった筆者がプロジェクトの反省と、自動化前に考えておきたいポイントを考察します。

そして、3つの失敗事例と2つの成功事例を紐解き、テスト自動化プロジェクトを成功するために必要なポイントを解説します。

「自動化」という目的が先行したプロジェクト、他人事ではなかった

「ルーチンとなる業務を何とか自動化して、効率化できないか」、

業務を遂行する中でこのように思われる方、ましてや「テスト」に関してとなると自動化できるなら両手を挙げてという方も多いのではないでしょうか？

しかし、定型化されていない動作に明確でない完了条件などがあるテストの自動化ともなると、いかに難しいかは想像に容易いと思います。そこで、筆者が初めてテスト自動化に取り組んだ際、なぜ失敗したかをお話しいたします。

まずテストを自動化させる上で、数多くあるテスト自動化ツールの中から、どれがプロジェクトに合うか、判断する必要があります。その評価のために「まず自動化を組んで試そう」という軽い気持ちで自動化ツールを使ってスクリプト組んだのが筆者の失敗でした。

実際に自動化したテストを回してみると、どんどん出てくる想定外の挙動。それに対しケースバイケースでの実装を余儀なくされました。そして、組み終わって後もなお立ちはだかったのが保守に必要な想定以上の労力でした。ここまで来て振り返り、ようやく「これ自動化が目的になっている」と気づいたのも後の始末。見事にプロジェクトは失敗に終わりました。

■テスト自動化導入への第一歩！
テスト自動化推進ガイドブックを無料で配布中！

他にも見つけた、地獄のような失敗事例

前述のとおり、筆者は見事にテスト自動化の導入を失敗してしまいました。そこで、テスト自動化における知見が豊富にある、テスト自動化研究会(STAR: Software Test Automation Research Group Jp)を拝見したところ、事例セッションでもやはり目を引いたのが失敗事例でした。そのため、自戒を込め、やってはいけないアンチパターンを以下にまとめてさせていただきます。各事例についてはリンクを末尾に着けていますので参考にしてください。

【事例①（失敗事例）　無料だからという理由だけで始める】

「リグレッションテストの項目は毎回同じだし、自動化したら効率化できるのでは？」

「Selenium なら Python で書けるし、動かせるだろう」

まさしく身につまされそうなのですが、結果としてこの事例では次のバージョンでUIが大幅に変わり、スクリプトはほとんど組みなおしとなりました。その後も一人で自動化担当としてひたすらに対応をし続けています。（少し前だったら他人事で済んだのですが、経験してしまうと震えます。）

2年間自動テストを作り続けて分かったこと_失敗談から学ぶテスト自動化

https://speakerdeck.com/mt3_set/2nian-jian-zi-dong-tesutowozuo-risok-ketefen-katutakoto-shi-bai-tan-karaxue-butesutozi-dong-hua

【事例②（失敗事例）　「手動テストの実行より工数削減」するための自動化】

なにを当たり前のことと思います。この事例は、曖昧なテスト自動化の要件をもとに進行したことで、無意味な自動テストになってしまうものです。

この事例では、手動テストよりも実行を早く終わらせる（=工数削減）ことだけに注力した自動テストを組むというものでした。そう、本当に早く実行するために手動で確認している各項目の確認作業を行わずにエラーをはかずに最後の画面まで行けるかという実装です。

また、クライアントにテスト自動化の現実を伝えず、認識を曖昧なまま進めてしまいました。

そしでいつの間にか工数の削減という目的を成すための手段ではなく、テスト自動化を導入することが目的に変わってしまっています。この事例では自動化しなかった残した項目を手動でもやると思うのですが、完全に二度手間になってしまいそうです。

ぼんやりした要件とテストケースから出てくる地獄のようなゲームテスト自動化導入

https://www.slideshare.net/keysh2/ss-250840722

【事例③（失敗事例）　自動化スクリプトだけが更新される】

これは当社での講演内容ですが、テストケースを元に作られたテストスクリプト（Pythonなのか、はたまたツールのGUI上なのか）とテストケースの二重管理はかなり面倒です。

そこで良く起こるのが、自動テストが動くように「スクリプト」だけは更新するというやり方です。思い当たる方もいるのではないでしょうか？

結果起こるのが、スクリプトの実装者しか何のテストをしているのかわからないという超属人化です。この場合、実装者がわかっていればまだマシなのですが、場合によっては、実装者は動くように作るのに精一杯で、テストの目的まではわかっていないかもしれません。

だましだまし続けてきたものの、大半のテストケースとスクリプトの内容が一致しなくなりました。その結果、テストが足りているのかどうかの判断がつかなくなり、テストケースから全部作り直す羽目になったという事例となります。テストで品質を確保するための自動化なのですが、いつのまにか自動テストをパスすればいいという認識にすり替わってしまったようです。

事例③ 当社セミナー（定期開催）

https://codezine.jp/article/detail/16382

■未来の自動化時代への準備は今！
テスト自動化ツールT-DASH基本ガイド配布中！

失敗が起こるのは目的が迷走しているから

これらの原因を分析してみると、失敗事例１・２・３では共通点がありました。

失敗事例1では運用・保守工数を考えず体当たりしたところ、効率方ための自動化で大幅に工数を割いてしまったというものでした。

半ば自動化はできるのか試してみる目的もあり、自動化に取り組んでいたのならまさしく筆者の状態と同じで短期的には全く効率化は実現できていません。特に「テストの自動化」では対象物が大幅に刷新されることもざらなので、初めから保守に手間がかかることを念頭にツールも選んでおきたいところです。

失敗事例2に至っては、工数削減という名目がなぜか自動テストを組み込むことが目的になってしまい、結局工数削減は達成できていません。

こちらも目的が迷走しているのが結果的に大きな影響を与えています。

失敗事例3でも上述の通り、本来の目的である「品質を上げる」ための自動テストが、自動テストを動かすために奔走する羽目になり、

品質のためのテストが実現できなくなって、全面見直しとなってしまいました。

紹介した失敗事例以外にも失敗例／成功例はたくさんあります。今回まとめた3つの失敗事例では、いずれも筆者が嵌った「目的」と「手段」が入れ替わったことに根本的な課題が潜んでいるように見受けられます。

「手段が目的化する」という現象は、テスト自動化の取り組みで起きやすいように感じますので、重々念頭に置いておきたいところです。

一方で、目的を明確に置くことで成功した事例もありました。ここからはそちらも紹介いたします。

【事例④（成功事例）　自動化文化を作り、メンバー誰でも自動化できるように】

この事例では既にSeleniumやPlaywrightをベースに自動化を構築しており、ローコードツールの導入を行っています。既存の仕組みの課題としてSeleniumでは自動テストの構築・メンテナンスにコーディングスキルが必要となる点がありました。これにより、チーム全体に自動化文化が広がらない／一部メンバーに負荷が集中してしまうという事態が発生しました。

解決したい事象を明確に「だれでも構築・メンテナンスをできるようにする」ことに目的を設定して導入しました。そうしたところ判断基準が明確となり、成功に繋がったようです。

mablの導入と開発・QA間の協力体制

https://speakerdeck.com/shiromoto/mablfalsedao-ru-tokai-fa-qajian-falsexie-li-ti-zhi