自動テストを継続させるカシオ計算機の事例
さらに、2つ目の事例としてカシオ計算機の事例を紹介した。スマホから時計の機能設定が行える専用アプリ「CASIO WATCHES」に対して、デグレチェックを中心とした自動テストにより基本機能が正常に動作していることを確認している。
対象となるのは、本番アプリと開発アプリだ。また、リリース直前のアプリに自動テストを必ず実施することになっている。テストケースは、1スイートで約280ケースで、これを1日2回毎日動かしている。
この事例では、自動テストを継続する上で、2つの運用上の課題があった。
1つ目は、テスト失敗時の対応が大変な点。テストが失敗すると、その調査と修正に数時間かかっていた。1テストケースの実行時間が10～30分と長く、再実行しても別の要因で止まってしまい、その修正・確認でまた落ちるを繰り返してしまうのだ。
「原因は、画面単位でテストケースを自動化していたことでした。1つの画面のなかに複数のオンオフがあり、オンにしたらチェック、オフにしたらチェックみたいなことが延々と続いていました。対策として、テストケースを再設計し分割しました。また、1個のテストケースを1〜2分で終わるようにしました。するとテストが安定し、テストが失敗したときの原因調査の時間を大幅に短縮できました。それによってテストの運用をしっかり回せるようになりました」
もう1つの課題は、テストが不安定すぎる点。ちょっとした画面の変更で、テストが失敗してしまう。そうすると、画面変更のたびにテストスクリプトの変更が必要になる。
「スマホアプリのなかでWebViewを使っており、画面の要素にIDがないことが原因でした。XPATHで動かしているとスクロールで変わってしまいます。また、OpenCVの画像マッチングの精度にも問題がありました」
対策として、Appiumで認識できるIDを付けてもらうようにした。これは開発者の方にお願いする必要があったが、劇的に効果を発揮して全く落ちなくなった。
「自動テストを継続しようとするとき、テストエンジニアだけではできないことがたくさんあります。いかに開発者や他のチームとコラボレーションするのかが大事になってきます」
