自動テストを進めるうえで直面する2つの課題と環境変化
セッションの前半で、浅黄氏は自動テストを取り巻く課題について説明した。「自動テストについて時系列で考えた時に2つの山があります。始めるときの山と継続するときの山です」
自動テストをいざ始めようとしても、最初の山を登れない場合が少なくない。ツール選定に3カ月かかってやっと始めるのでは息切れしてしまうのだ。
「自動テストを始めるときの最初の山を越えるためには、初期構築をいかに素早くできるかがすごく大事だと思っています」
もう1つの継続する山を超えるには、テストをリファクタリングできるかが重要になる。UIの自動テストは不安定になりがちで、失敗し続けるテストは、誰も見ないテストになる。放置すれば、誰もメンテナンスできないテストになってしまう。
さらに浅黄氏は、ソフトウェア開発の激しい環境変化についても言及した。こうした変化が自動テストを後押しするのだという。まずは、ウォーターフォールからアジャイルへの開発プロセスの変化だ。これまでのウォーターフォールでは開発フェーズとテストフェーズで分かれていたのが、アジャイルではスプリント中に何度もテストを回すため自動テストが必須になる。
もう1つはテクノロジーの変化である。商用ツール全盛の時代から、オープンソースソフトウェアが普及し、さらにSaaSが当たり前になってきている。最近ではテスト自動化ツールを検討する場合も、SaaSを何社かとオープンソースソフトウェアを比較することが多いだろう。そこでは安定性と素早く進められるかどうかがポイントになる。
3つ目はテストに対する期待の変化だ。テストが、実施するものから実行されているものという感覚に切り替わってきている。さらにテストはバグを見つけるだけでなく、開発者やプロダクトオーナー、チーム全体がフィードバックを得るためのもの、品質を確認するものになってきている。
「この3つの環境変化を考えると、やはり自動テストはどうしてもやらなきゃいけないものだと思っています」
なお実際の事例について紹介する前に、浅黄氏はヒューマンクレストで利用している自動テストのテクノロジーについて簡単に紹介してくれた。
「当社では、テストの自動化のためにSeleniumからJUnit・OpenCVまで幅広いツールを使っています。そのため、自動テストを行おうと思ったときには、悩むことなくすぐに始められるようになっています」
自動テストを始めるBtoB：Webサービス企業の事例
続いて浅黄氏は、自動テストに取り組む2つの企業の事例を紹介した。
まずは、BtoBのWebサービス企業がテスト自動化に取り組み始めた事例だ。WebサービスなのでフロントエンドはJavaScriptで、バックエンドにPHPで作られたものとJavaで作られたものという2つのシステムがあった。この会社で課題だったのは、リグレッションテストがうまくできていないことだった。ウォーターフォールで開発していて、テストケース自体は数百と作ってあったが、それをすべて手動で回していた。そうするとテストをやり切れず、結果としてユーザーが不具合を見つけてしまい、サポートに連絡がきて調査に追われる。そういう状態が繰り返されていた。
「アップデートで動かなくなったところがないか、不具合が発生していないか、ちゃんと確認したい。毎日自動テストが動いている状態にしたい。そういう思いがお客さまにありました」
しかし、どこからテストの自動化に手を付けるのが効果的なのだろうか。これまで培ってきた数百のテストパターンのすべてを自動化するのは、手間も時間もかかってしまう。
「この最初の1歩が、自動テストを始める時にすごく大事です。どのツールを使っても大体同じことができるので、ツールは何でもいいと私は思っています。そして、何を自動テストするか？が非常に重要です。テストピラミッドから考えれば、UIのテストが少量でもテスト範囲は広くなります。そこで、既存のリグレッションテストを自動化するのではなく、新たに基本的な機能にフォーカスし、自動テスト用にUIテストケースを作成することとしました」
実際には、その企業のホームページに書いてあるサービスの基本機能をテストの対象にしたそうだ。そして、機能一覧の中から「ここが落ちたらやばい！」という重要度と手動テスト実施のコスト、テスト自動化のコストに優先順位をつけてもらい、重要度：高→低、手動テスト実施コスト：高→低、自動テスト作成コスト：低→高で並び替え、作るテストの優先順位を決めていった。
その結果、PHPで作られたシステムで20ケース、Javaで作られたシステムで77ケースのテストケースを作成した。そして、3週間で最初の1テストケースを回し始めて、2カ月ですべてのテストケースを作成できた。現在は、毎日1回自動テストを実行しており、テスト失敗時にSlackに概要とスクリーンショットを送信している。
さらに、End-to-Endの自動テストが基本的に回るようになったことで、もともと導入したかったスクラムが導入しやすくなったという。ユニットテストの自動化も開発者たちが率先してやってくれてリファクタリングできるようになった相乗効果も生まれた。
「"始める"という山を越えるには、とにかく1テストケースが毎日実行されるテスト実行環境を最速で作ることが本当に大事です。1カ月以上経つと、やろうと言っていた人たちも『アレどうなった？』『やっぱり無理か……』といった話になり、1年も経つともうほとんど語らなくなってしまいます。ツールの選定も重要ですが、どのツールでも大体同じことができるので、1～2日でどんどんツールを試し、使いやすさを見極めればいいと思います。自動テストを継続するためにどんなテストをするのかが大切なので、そこに価値を見出して欲しいと思っています」
自動テストを継続させるカシオ計算機の事例
さらに、2つ目の事例としてカシオ計算機の事例を紹介した。スマホから時計の機能設定が行える専用アプリ「CASIO WATCHES」に対して、デグレチェックを中心とした自動テストにより基本機能が正常に動作していることを確認している。
対象となるのは、本番アプリと開発アプリだ。また、リリース直前のアプリに自動テストを必ず実施することになっている。テストケースは、1スイートで約280ケースで、これを1日2回毎日動かしている。
この事例では、自動テストを継続する上で、2つの運用上の課題があった。
1つ目は、テスト失敗時の対応が大変な点。テストが失敗すると、その調査と修正に数時間かかっていた。1テストケースの実行時間が10～30分と長く、再実行しても別の要因で止まってしまい、その修正・確認でまた落ちるを繰り返してしまうのだ。
「原因は、画面単位でテストケースを自動化していたことでした。1つの画面のなかに複数のオンオフがあり、オンにしたらチェック、オフにしたらチェックみたいなことが延々と続いていました。対策として、テストケースを再設計し分割しました。また、1個のテストケースを1〜2分で終わるようにしました。するとテストが安定し、テストが失敗したときの原因調査の時間を大幅に短縮できました。それによってテストの運用をしっかり回せるようになりました」
もう1つの課題は、テストが不安定すぎる点。ちょっとした画面の変更で、テストが失敗してしまう。そうすると、画面変更のたびにテストスクリプトの変更が必要になる。
「スマホアプリのなかでWebViewを使っており、画面の要素にIDがないことが原因でした。XPATHで動かしているとスクロールで変わってしまいます。また、OpenCVの画像マッチングの精度にも問題がありました」
対策として、Appiumで認識できるIDを付けてもらうようにした。これは開発者の方にお願いする必要があったが、劇的に効果を発揮して全く落ちなくなった。
「自動テストを継続しようとするとき、テストエンジニアだけではできないことがたくさんあります。いかに開発者や他のチームとコラボレーションするのかが大事になってきます」
自動テストを継続する5つのポイント
そして浅黄氏は、自動テストを継続するための5つのポイントを説明した。
1つ目のポイントは、担当者を決めること。自動テストを導入すると属人化しないと言うが、実際はテストを作った人に属人化することになる。なので、「まずは属人化させてその人がちゃんと自動テストをやれる状況を作ろう」と説いた。
2つ目のポイントは、失敗したテストを放置しないこと。12時間放置すると次のテストが始まるため、1日過ぎたら原因追及なんてほぼされない。そのためヒューマンクレストでは、24時間以内に方針を決めることを基本ルールにしているそうだ。
3つ目のポイントは、テストを安定化させること。当たり前のことだが、不安定なテストは本当に正しい結果を出しているか見ることができない。「そのために不安定なテストは捨てても構わない」と主張した。
そして4つ目のポイントとして、テストのリファクタリングを常に行うことの重要性を説いた。テストの目的が何かをもう一度考え、価値の再構築を常にやっていく必要がある。
最後のポイントは、開発者や他のメンバーの協力を得ることだ。先ほどの事例でも触れたように、自動テストだけでは実現できないことがたくさんある。
「プラットフォームチームやDevOpsチーム、セキュリティチームとどれだけコラボレーションできるかが非常に大事だと思っています」
なお、3つ目の事例については「新しい技術をちゃんと導入していこう」と強調した。あるお客さまでは、新しい技術を常に取り入れながら、同じテストを10年続けているという。
最後に浅黄氏は、「技術トレンドを追わないと自動テストも陳腐化していきます。テストエンジニアも必ず疲弊していってモチベーションも下がります。地道ですが、当たり前にきちんと技術トレンドを追っていくことが大切です」と強調し、セッションを締めくくった。
