ヤフー、楽天、クックパッドにおける「テスト」への挑戦――ツール、体制、アーキテクチャはどうなっているのか：システムテスト自動化カンファレンス2015（3/3 ページ）

「システムテスト自動化カンファレンス」第3回が開催。ソフトウェアテストの現場にはどのような課題があり、エンジニアがどう解決してきたかが紹介され、いくつか共通するキーワードが見えてきた。

[高橋睦美，＠IT]

【クックパッド】モバイルアプリのテストはつらいよ？

クックパッド 松尾和昭氏

　クックパッドの松尾和昭氏は「Testing Tools for Mobile App」と題し、iOSやAndroidをターゲットにしたモバイルアプリテストのポイントを紹介した。

　モバイルアプリにはWebアプリケーションとは異なる事情がいくつもある。「モバイルを取り巻く環境はとにかく変化が早い。さまざまなOSがあり、バージョンもまちまちな上に、端末もスマートフォンだけではなく、ウェアラブルやテレビなど多様化している。加えて利用場面が多様化していて、さまざまなケースを考えなくてはならない時代になっている」（松尾氏）。その中で、短期間の開発で高頻度のリリースを繰り返していかなければならない。

　中でも苦しいのは、自力ではどうしようもない要因や条件に従わざるを得ないことだ。アプリ自体には問題がないのに、通信環境やプラットフォーム事業者側の問題でダウンロードできなかったり、リリースまでに時間がかかったり、逆にリリースしてもユーザーがアップデートしてくれるとは限らないため不具合が残存したりと、さまざまな要因がある。

　加えて年に1回程度の頻度でOS自体が大規模に更新され、開発環境や仕様にも「破壊的」な変更が生じる。松尾氏はその状態を「お祭りのような騒ぎ」と表現しつつ、開発者はそれを受け入れざるを得ないと述べた。「モバイルアプリは環境の変化が激しく、高頻度なリリースを行うには、公式からリリースされるものに追従していくことが重要だ。しかもこの変化は強制される。無視するという選択肢はない」（松尾氏）

　こうした制約の中で、外的要因も考えながら安定したリリースを回し、不具合を減らしていかなくてはならない、というのがモバイルアプリ開発者の置かれた状況だ。

　松尾氏は、iOSとAndroid、ネイティブアプリとWebと連動したハイブリッドアプリとに分け、「XCTest」「XCUITest」や「JUnit」「Espresso」「UI Automator」、それに両方のOSをサポートしている「Appium」といった主なテスト環境を紹介した。カード決済サービスを開発しているSquareという会社が公開している「Spoon」や、GutHub上で公開されている「awesome」シリーズも参考になるという。

　さらに「Test as a Service、TaaSというものも、モバイルアプリ向けにいくつか出てきている」（松尾氏）。主に実行環境と結果レポートを提供するもので、あまり凝ったテストはできないが「いろいろな機種に対してテストを行い、機種固有の不具合を見つけるのにいい」そうだ。

　なおモバイルアプリのテストには、Webアプリと異なりいくつか「不安定」な要素が入り込む可能性がある。こうした不安定なテストは「Flaky」と表現されるそうだ。松尾氏は、Flakyなテストを減らすコツとして「MockやStubサーバを使って閉じた環境を作る」「アニメーションをオフにして揺らぎをなくす」といった事柄を挙げた。

苦い経験を糧に、開発の流れにテストを組み込む

　後半では、クックパッドのAndroidアプリで発生した不具合を例に取り、どのようにテスト自動化に取り組んでいるかを紹介した。

　あるとき、AndroidアプリでCPUやメモリが激しく消費されるという問題が発覚した。短期間触っただけでは発覚しない性質の問題で、意図しないスレッドが生成され、ある条件を満たすとリソース消費が爆発的に増えてしまうことが原因だった。残念ながら開発プロセスの中では発見できず、レビューや問い合わせによって発覚したもので、「テストエンジニアとしては身に染みた不具合」（松尾氏）だったという。

　松尾氏はこの原因を、CPU使用率をはじめとするリソース消費状況を計測するという手順が「一連の開発プロセスの中に組み込まれていなかったこと」と判断した。機能要件こそテストによって満たしていたが、CPU使用率をはじめとするリソース消費状況の計測は「たまに」「必要なとき」だけに実施するのみで、開発の流れに組み込まれていなかったのだ。

　そこで、Androidのadbコマンドを活用し、CPUやメモリの使用状況、通信状況等を監視するツール「droid-monitor」を作成。これを自動化されたテストの一部に組み込んで、必ず数値を取れる状態にした。「開発者も普段からリソース使用量まではなかなか目が行かない。入れてみると、『目に見えない指標が得られる』といい反応が得られた」という。

　「自動化というものは、『開発の流れに組み込まれないもの』を減らすためにやるものだ。手動で『これをやろう』『ああしよう』とやっていくと、抜けや漏れが発生する。やるべきことを開発の流れに組み込み、必要なものは計測されている状態を作ることが大切だ」（松尾氏）

クックパッドにおけるスマホアプリ開発の流れ（松尾氏の講演資料より）

　今後はテスト管理や、デザイナーやディレクターも含めたフィードバック先の拡大に取り組んでいきたいと考えているという。

「実績」を重ねて上司の理解を

　今でこそテストが当たり前の状態になっているクックパッドだが、松尾氏が入社した当時は、Excelシートで管理するような手動テストしかなかった状態だったという。どうやってこの「デファクト」を変えたのだろうか。

　「手動テストには人手がいるが、リリース頻度が増えていけば人手が足りず、破綻するのは明らかだった。一方で、ビジネスの要請上、アプリの継続的な改善は必須。自動化によってこの課題を解決できるだろうと信じて取り組んできた」（松尾氏）

　こうした変化を広げていくには、やはり上司の理解が必要だ。そして上司の理解を得るには「実績」を残さなくてはならない。松尾氏は、やみくもにテストケースを実行するのではなく、優先順位や重要度に応じて取捨選択し、不要なテストを省いたり、ディレクターにその利点を説明したりといった工夫を通じて、効果を上げてきた。

　こうして実績を残せば「周りの人たちもインパクトを受け、今までの概念を塗り替えていくものを作り出すことができるし、周りからも『どんどんやって』と後押しされる」という正のスパイラルが動いていくことになる。

　松尾氏は将来的な目標として、「組織的に開発者の文化を成熟させ、開発者が、普通の開発プロセスの中に自分たちでテストを組み込むことができる、そういうところまで実現できれば、テストエンジニアという職種が増えなくてもスケールさせていくことができるだろう」と述べ、講演を締めくくった。