モバイル開発におけるテストの自動化はスクラムチームが行うべきだ，独立したテスト自動化チームを置くべきではない – European Testing Conferenceで，Nadya Denisenko氏はこのように述べた。そして氏は，モバイルテストのテストピラミッドに従って、開始時からテスタが関与するようにアドバイスする。テスタは品質指向の開発者として、他の開発者が高品質のソフトウェアを提供するのを指導し支援することのできる存在であり，手動テストは将来的になくなっていくだろう、と氏は言う。
モバイル開発はベンダロックされた分野だ。市場に２つの大手ベンダがあって，オペレーティングシステム，アプリケーション，開発，テストの方法を左右している，とDenisenko氏は言う。しかも多くの企業は、この両方のプラットフォームで自動テストを開発することのできる，万能な自動テスト開発者(ユニコーン)を探し求めているのだ。つまり、モバイルに携わるオートメーションエンジニアは、少なくともKotlin、Swift、Java、Objective-C、そしてiOSとAndroidの動作原理を理解する必要がある上に、オートメーションエンジニアからは手動でアプリケーションをテストする能力を期待されていることになる。これは非現実的だ，とDenisenko氏は言う。
モバイルアプリは開発期間が短いことで知られており，ほとんどの場合，QAは製品が市場に出回った後の極めて遅いタイミングで実施されている，とDenisenko氏は言う。このため開発チームは、テスト担当者を置かない開発に以前から慣れており，それがテストプロセスの設定に多くの問題をもたらしている，というのだ。最初はゆっくり始めよう，と氏はアドバイスする。開発者と共同で，最初にテスト自動化フレームワークを構築し，スプリントに自動化機能を取り入れ，ひとつのレグレッションシナリオを取り込むのだ。
Webやバックエンドに比較すると，モバイルプロジェクトは非常に小規模である。従って独立した自動化チームを設けるのは現実的ではなく，スクラムチームがそのタスクを実施すべきだ，とDenisenko氏は言う。
テスタの役割は，開発者が高品質のソフトウェアを提供することを指導し支援することにある，と氏は述べている。"テスタは品質指向の開発者であって，手動テストは将来的になくなるか，あるいは姿を変えることになるでしょう。"
テスト可能なコードとテストを開発することによって，開発者自身にテストを実施させたいとする企業が増えている，とDenisenko氏は指摘する。手動テスタから自動化エンジニアになった自身の経験から，氏は，それまでのテスタの役割が，テストを担当するソフトウェア開発者ないしコーチに変わりつつあることを感じている。
InfoQではEuropean Testing Conference 2019を取材するとともに，講演を終えたNadya Denisenko氏に，テスト自動化が失敗する理由と回避策について聞いた。
InfoQ: 講演の中で、自動化チームを分離するのはお金の無駄だという話がありましたが、その理由を詳しく説明して頂けますか？
Nadya Denisenko: 大きな理由はテスト設計です。テストカバレッジを決定する場合、一般的にはユニットテストが70パーセント、インテグレーションテストが20パーセント、E2E自動テストが10パーセント，というテストピラミッドを使用します。しかしモバイルの世界では、このようなテストピラミッドにはならず、砂時計型やアイスクリームコーン型になることがほとんどなのです。多くの場合、独立した自動化チームを用意するということは、チームの主眼がE2Eテストの自動化にあることを意味しています。そのためには、テスト設計に従ってリソースを分散した方が合理的なのです。
InfoQ: テストピラミッドを採用するのでしょうか、あるいは砂時計やアイスクリームの方が適しているのでしょうか？
Denisenko: そうです。ピラミッドを使用した方が、アプリケーションに起きていることをよりコントロールできますし、問題点をデバッグする時間を短縮できます。
InfoQ: モバイル開発者がテストピラミッドに従わないのはなぜでしょう？
Denisenko: いくつか理由がありますが、状況によって違います。
銀の弾丸。管理者や一部の(特にバックエンドの)開発者は、E2E UIテストを行えば、実環境のあらゆる状況における動作をカバーできると考えています。しかも、それらのテストを行えば、APIテストやバックエンド、クライアント統合テストなどが省略可能だと考えていますが、それは間違いです。プラットフォームの制限によってテストできないことが、モバイルではたくさんあるのです。単純な例は、外部アプリとの間のディープリンクやプッシュ通知です。もうひとつ忘れがちなのが、バックエンドとアプリケーションUIとの間にあるレイヤが多すぎるために、うまくいかないことがたくさんある、ということです。ざっと挙げただけでも、サードパーティ、バックエンド、ネットワーク、アプリケーションのネットワーク実装、UIなどがあります。問題がその中のどこで発生したのか、詳細な情報を提供してくれるようなフレームワークは、私の知る限りではひとつもありません。結果として、プロジェクトは保守不可能なテストを抱え込み、テストの自動化に失望することになるのです。
タイミング。新しいモバイルプロジェクトはいつもMVPから始まって、大規模なものに膨らみます。アプリケーションのテスト容易性はいつも考慮外です。つまり、アプリケーションにはユニットテストとE2E UIテスト以外は設計されていません。発者が詳細なテストの必要性に気付いた時には、変更を加えるには費用が掛かりすぎるようになっているので、チームはそれを無視するのです。
専門知識。専門知識が問題の場合もあります。統合テストはモバイルテストの新たな波なので、それが何であるのか、どうやってやればいいのかという点に関して、すべての開発者が十分な知識と理解を持っている訳ではありません。学ぶ気さえない者もいるのです。
InfoQ: モバイルテストの自動化に関して、どのようなことを学びましたか？
Denisenko: いくつかあります。
- 自動化されていないプロジェクトに参加する時は、決してキャッチアップゲームをプレイしようとはしないこと。
- テスト自動化フレームワークを開発する時は、可能ならばベンダのテストフレームワークを使用すること。オープンソース・ソリューションは一般的に、最新OSバージョンから6ヶ月遅れでサポートをリリースする傾向がある(従って最新OSでは自動テストがまったく機能しない)傾向がある上、サポートが中止されることも多いのです。
- 別のプロジェクトで開発されたテストを流用しないこと。自分自身のテストの開発やメンテナンスに集中できず、テストの統合と修正にスプリントを丸ごと費やす羽目になります。
- ネイティブな言語を使用すること。開発者は怠惰なので、テスト目的のみでrubyやpythonを習得しようとはしません。
- 品質は共同責任であり、チームメンバ全員が貢献すべきものです。
InfoQ: AppleやGoogleはどのようなテストガイドラインを提供しているのでしょうか、それらはどのように利用可能ですか？
Denisenko: 次のようなガイドラインがあります。
Google は、ユニットテストや統合テスト(コンポーネント間の統合)、UIテスト、機能UIテスト、E2Eテストというように、異なるレベルでのテストの実施を推奨しています。できる限り自動化されたテストを使用して、さまざまなレベルでテストを行う方法を習得している開発者の世代を増やそうとしているのです。そのためのチュートリアルも多数作成しています。Googleのテストコミュニティは議論も活動も活発です。
Appleは対照的に、ユニットテストとE2Eテストの開発を推奨しています。同社は開発者に対して、ユーザが実施に使用するようにアプリを自動化することと、E2Eを自動化でカバーすることを提唱しています。
個人的な意見としては、ベンダは開発者やテスタに干渉せず、戦略の選択を彼らに任せるべきだと思っています。ルールを追加して制限を設ければ、新たな、優れた、革新的なものが作り出される可能性を削いでしまうことになります。