モバイルアプリケーションテストの自動化を進めることのメリットとデメリットについて、2人のベテランのソフトウェアテスターが議論を交わした。

　企業向けのシングルサインオン（SSO）サービスを提供している米認証管理企業のOktaの場合、できるだけ多くのテスト作業を自動化するという方針を採用している。同社の主任技術者でベテランソフトウェアテスターでもあるデナリ・ルンマ氏は「Oktaでは、テスト、配備、運用を含め、アプリケーションのライフサイクルのあらゆる部分の自動化を進めている」と話す。拡張性と高可用性に対するニーズを考えれば、SSO機能の開発とテストを手作業で行うのは無理だという。テストの数が非常多いため、手作業で全てのテストを実施する時間がないからだ。「当社では自動化に特に力を入れており、手動テストはほとんど行っていない」と同氏は話す。

　しかし全てのモバイルアプリケーションのテスターが、ルンマ氏のようにモバイルソフトウェアのテストの自動化を支持しているわけではない。米Project Realmsでソフトウェアのテストとサービスのコンサルタントを務めるジーン・アン・ハリソン氏によると、自動テストツールが乱用されるケースも見受けられるという。「人々は何でも自動化できると思っているが、そんなことはない。テストの90％を自動化できると思われているようだが、とんでもない」と同氏は語る。

　また機能テストに関しては、ハリソン氏の経験では、テストを自動化できるのはモバイルプロジェクトの20％程度だとしている。テストツールと自動化手法が今後さらに改善されれば、自動化率が40％に達する可能性はあるが、50％まで自動化するのは難しいという。

　「Webアプリケーションやデスクトップアプリケーションと比べると、携帯端末の場合はテストの多くがまだ手探りの状態」というのがハリソン氏の見方だ。「モバイル分野はもはや幼年期ではないにせよ、まだよちよち歩きの段階」と同氏は指摘する。「モバイルアプリ開発分野が成熟していけば、今後も多くの変化があるだろう」

自動テストを積極的に推進するOktaルンマ氏のチーム

　「当社のWebサイトは非常に重要だが、われわれは任意の端末上で動作するネイティブクライアントも提供している。未対応の端末があっても、すぐに対応する」とOktaのルンマ氏は話す。

　同氏によると、OktaのWebサイトは隅々までチェックし、テスト手法も成熟しているが、ネイティブモバイルプラットフォーム向けに多数の新しいテストを現在も開発しているという。「Webアプリケーションとデスクトップアプリケーションだけでなく携帯端末からのアクセスにも対応するために、われわれのチームはモバイルソフトウェア用の自動テストツールを積極的に活用している」と同氏は話す。

　Oktaが採用したのは、オープンソースの新興企業である米Sauce Labsの自動テストプラットフォームだ。ルンマ氏によると、Oktaが自動化ツールを導入したのは、開発者がコードのデバッグに費やす時間を短縮するためだという。「当社では開発者の時間が最大のコストだ」と同氏は語る。ビデオログ、スクリーンショット、ブレークポイント、ブラウザとのインタラクションなどの機能を利用することで、開発者のデバッグ時間が3～5日から3～5時間に短縮された」（同氏）

　しかし1つのツールであらゆるニーズに対応することはできない。ルンマ氏によると、Sauce Labsは米Appleのプラットフォームに主眼を置いており、Windows端末のサポートは遅れているという。「Mac上のSafariの自動テストは大いに役立った。しかしWindows用のテストでは、特定のOSバージョンとサービスパックの組み合わせのサポートが不足していた」と同氏は振り返る。Sauce Labsはいずれこの不備にも対応するだろうが、現時点では、モバイルソフトウェアのテスト自動化サービスは、Windows端末上のネイティブコードのテストにはあまり役に立たないという。この部分については、同氏のチームは「Skytap」というクラウドベースの開発・テストツールを利用している。

　ルンマ氏によると、ソフトウェアのテストがほとんど自動化された今、新たなテストよりも既存のリグレッションテスト（回帰テスト）に重点が置かれるようになったという。「アプリケーションの成長と変化に伴い、テストのメンテナンスコストが増大する。その意味では、リグレッションテストはチャレンジであると同時に大きな効果が期待できる」と同氏は話す。

「モバイルテストでは計画が肝心、自動化はその次」――Project Realmsハリソン氏

　一方、Project Realmsのハリソン氏の経験によると、モバイルアプリケーションの開発プロジェクトでは大幅な変更がよくあるという。「ほとんどの変更は小規模で反復的なものだが、バージョン2.0からバージョン3.0といった総合的なバージョンアップの場合は大幅な変更になることが多い」と同氏は語る。デスクトップアプリケーションは比較的変更が少なく、長期的なリグレッションテストの自動化に対するニーズは高い。一方、モバイルアプリケーションの場合は、全面的に変更されたり、コードベースが一から書き直されたりすることがあるという。「コードベースが根本的に変更された場合、自動リグレッションテストがそのまま使えるケースはほとんどない」と同氏は付け加える。

　ハリソン氏は、携帯端末内の機能の相互依存性にも不安を感じている。コードの実行を停止させるような変更がアプリ自体に反映されていない場合もある。例えば、携帯電話の通知機能はそのOSに緊密に結び付いている。開発者が既存のモバイルアプリに通知機能を追加する場合、これまでそのアプリに含まれていなかったモバイルOSの機能を品質保証チームがテストする必要が生じる。「このため、テストの方法も変わらざるを得ず、自動テストも全面的に変更しなければならない」と同氏は話す。

　「こういった変更を軽視してはいけない」というのがハリソン氏の見解だ。モバイルアプリでは速度が重要な要素であるからだ。「テストスクリプトを作成して実行するよりも手作業でテストした方が早い場合、『自動化を進める価値があるのだろうか？』と自問すべき」

　ハリソン氏は「モバイルソフトウェアの自動テストツールで最も優れた製品はどれか？」という質問をされることが多いという。それに対する同氏の答えは「『何をテストするのか』『何のためにテストするのか』『どんなテストを行うのか』といった条件によって異なる」というものだ。同氏が無条件で推奨できる唯一のテストツールは“しっかりした計画”であるようだ。「1にも2にも計画。テストの計画をしっかり立てることが大切」と同氏は強調する。