はじめに
私は自社開発のソフトウエア会社でQAを行っているQAエンジニアです。
今回は、テストの自動化に取り組んだが失敗した話と反省を書きとめておきたいと思います。
テスト自動化の失敗はあるあるかと思いますが、私の失敗が誰かの役に立てば幸いです。
経緯
当初QA担当者が1人しかいないということもあり、テストの工数削減のためテスト自動化を行うことになりました。具体的にはRPAツールを使用し、ブラウザでの動作を自動で行うシナリオを作成することでテストの自動化を図りました。
そもそもなぜRPAツールを使ったのかについては、以下の3点が選定理由となります。
- 専用のe2eテストツールより価格が安かったこと
- ローコードツールであったためseleniumなどと比較し学習コストがかからないこと
- RPAは業務効率化ツールなのでe2eテスト以外の業務での利用が可能であること
失敗した原因
-
動作環境の維持にコストがかかった
使用したツールがGUI上での実行が前提となっており、テスト中は常に画面が表示されている必要がありました。
テスト期間の短縮のため夜間や土日に無人でテストを進めたい考えていたのですが上記問題から無人での実行が不可能でした。
この問題を解決するため、サーバールームに画面を表示しっぱなしの状態のマシンをRPA実行用に設置してもらい無人でのテストが可能となったのですが、代償としてマシンが落ちた際はインフラチームに調査を依頼するなどマシンを管理するコストがかかるようになりました。 -
シナリオメンテナンスコストが大きかった
RPAツールではHTMLの要素を指定するためのロケータにidやnameなどの属性を指定するのですが、これらの属性が開発の過程で変わるたびにテストシナリオへの影響を確認しシナリオの修正が必要でした。テスト工数を削減するはずが、メンテナンスのため工数が増加してしまいました。
RPA用のカスタムデータ属性を付与してもらうという手段も取りましたが、QAチームの工数を減らすためにフロントエンドチームの工数が増えてしまい、本末転倒な結果となりました。
なお、テスト等で属性をロケータに使用したい場合は上記の解決方法がベターではある。
-
アプリとツールの相性が悪かった
最後に、フロントで使用していたフレームワークとツールの相性が悪いという問題がありました。
文字入力や画面遷移でうまく動作しないことが何度かあり、原因を調査したところフレームワークの仕様上シナリオ通りの動作をしない処理があることが判明しました。
フレームワークの仕様にあうように実行順などを改善し、なんとか当初想定していた動作をさせることはできましたがかなり苦戦をしました。
さいごに
今回のテスト自動化では、コスト増加してしまうという典型的な自動化失敗の罠にかかってしまいました。
ツール選定時に導入コストだけではなく運用コストやメンテナンスコストまで考慮したうえで導入を決定することで今回の失敗を防げたのではないかと反省し、次に生かしていく所存です。
Discussion