ソフトウェアテスト専業企業が事例で語る、UIテスト自動化の始め方と続け方は？

【15-B-2】WebシステムやモバイルアプリにおけるUIからの自動テスト事例3選

自動テストを始める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日でどんどんツールを試し、使いやすさを見極めればいいと思います。自動テストを継続するためにどんなテストをするのかが大切なので、そこに価値を見出して欲しいと思っています」