SWETグループを立ち上げ、エンド・ツー・エンドのテストを実現
2011年10月にDeNAへ入社して以来、中川氏は、Mobageオープンプラットフォーム開発における「エンジニアリングとしてのテスト」の実現に携わってきた。Mobageオープンプラットフォームとは、フィーチャーフォンやスマートフォン、PC向けのMobageゲームを簡単に公開するための仕組み。SWETグループが組織された背景には、このプラットフォームの急速な発展があるという。
Mobageオープンプラットフォームの提供を開始したのは、2009年8月のこと。以来、日本国内の市場に向けて、次のように短期間で提供範囲を拡大し続けてきた。
- 2010年1月：フィーチャーフォン向け
- 2010年10月：Yahoo!モバゲー向け、PC向け
- 2011年2月：スマートフォン（ブラウザ）向け
- 2011年6月：スマートフォン（ネイティブアプリ）向け
- 2012年12月：Shellアプリ向け
海外についても、2011年7月の北米・欧州を対象としたワールドワイドプラットフォーム（スマートフォンアプリ）の提供を皮切りに、同年同月に中国、2012年2月に韓国というように、対応する地域、デバイスを拡大している。
一方で、提供範囲の拡大は大きな課題も生んだ。「グローバル向けのプラットフォームを、日本向けと同様に品質を落とさずに展開することはもちろん、プラットフォームを支える大規模システムの拡張とリファクタリングを、恒久的に行っていかなければならない。しかも、デリバリーのスピードは落とせない」（中川氏）
さらに、検証の属人性も解消する必要があった。驚くことに、プラットフォームの検証は、非常に優秀な1人のテスターに依存していた。「要するに、システムテストを行う環境が整備されていなかった」（中川氏）
グローバル展開が加速していく中で、品質を保証できないのでは危機的状況に陥るのは明らかだ。それを防ぐため、中川氏がDeNAに加わると同時に、現在のSWETグループの前身となる「プラットフォームQAチーム」が、次の3つを達成目標に掲げて立ち上がった。
- エンド・ツー・エンドテストを確立する
- テストを徹底的に自動化する
- テストしやすい環境を提供する
これらには、「品質保証の観点だけではなく、テストしやすい環境を作るという狙いもある」と中川氏は説明する。
中川氏を含め3名でスタートしたプラットフォームQAチームは、その後20名弱が所属する現在のSWET（Software Engineer in Test）グループとなり、個々のプロダクトから独立して活動している。プロダクトに所属する形を取らなかったのは、「横串チームによる戦略的横展開を狙うため」（中川氏）である。
SWETグループの役割は、次のように定義された。
- Developer Productivity（開発者の生産性）
- Quality Assurance（品質保証）
これに従い、具体的なミッションも「プラットフォームの品質保証」と「品質および生産性の向上」となっている。そのために、中川氏がメンバーに常に意識させているのは、「自分たちはテスターではなく、あくまでもエンジニアである」ということ。メンバーには、テストの対象となるものを開発できるくらいの力量が求められている。
SWETグループの主業務は、プラットフォームのサーバーサイドおよびクライアントサイドのテストである。ただし、これは「全方位的に行っても、無尽蔵なテストが必要になるだけ。そこでテストを分類し、戦略を立てて行っている」（中川氏）。具体的には、テストを次の図のように4象限にマッピングし、有効なテストを考えると中川氏は説明した。
- Who：デベロッパーテスト、受け入れテスト
- Which：単体テスト、結合テスト
- How：ブラックボックス、ホワイトボックス、グレーボックステスト
- What：機能テスト、非機能テスト
Web API、Webアプリ、モバイルWebのテスト方法を披露
Mobageオープンプラットフォームアーキテクチャの中で、SWETグループがテスト対象としているのは次の4つである。
- Mobage RESTful API（Web API）
- Mobage Developers（Webアプリケーション）
- mbga.jp＆ProxyServer（モバイルWeb）
- Mobage SDK（クライアントSDK）」
「チーム立ち上げ時に、私たちはエンド・ツー・エンドのテストの確立という目標を掲げた。これらはいずれもユーザーに一番近いところ。だから、ターゲット（テスト対象）とした」（中川氏）
Mobage RESTful API（Web API）
では、具体的にどのようなテストを行っているのか。最初に中川氏が紹介したのは、Web APIのテストである。Web APIのテストでは、APIサーバーとHTTPで通信してテストを行うが、テストクライアントはAPIサーバーやデータベースなどと同じセグメントに置く構成をとる。これにより、データベースやキャッシュのデータを、テスト中に参照したり変更したりすることを可能にしている。
SWETグループでは、これを「Gray Box Fixture」と呼んでいる。テスト自体はブラックボックスで行いながらも、テストの条件を作るところはホワイトボックスで行う。特にWeb APIでは、この「グレーボックス」を重視していると中川氏は語る。
その他にも、テスト用にDNSサーバーを利用して特定のサーバー1台をテスト対象にしたり、Web APIのドメインに特化したクライアント (Domain Specific Client) である「mobage-api-client」を作成したりして、テストを行っている。また、HTTPの通信内容をダンプできるようにしたり、テストを対話実行できるようにして、テスト中でのデバッグを可能にしているとのことだ。
Mobage Developers（Webアプリケーション）と
mbga.jp＆ProxyServer（モバイルWeb）
WebアプリケーションやモバイルWebに対するテストは、ブラウザ上で行っている。先述のWeb APIのテストと異なるのは、UIやJavaScriptを多用している点である。
Webアプリケーションのテストは最近のデファクトに忠実で、ツールとして「Selenium WebDriver」を採用。高速化のため、Headlessブラウザも使用している。
特徴的なのは、「ブラウザとエミュレータを使い分けてテストしている点」と中川氏。ブラウザでは、一般的にHTTPヘッダは取得できない。一方、mechanizeのような方法では、HTTPヘッダは取得できるが、JavaScriptの解釈ができないことが多い。そこでブラウザの状態を保存し、ブラウザとエミュレータを自動的に切り替える工夫を施しているという。そのほか、ここでもDomain Specific Clientである「mobage-browser」というライブラリを作成して、テストを実施している。
また、UIテストではPage Object Patternを使っていない。モバイルエミュレーションについては、今はリアルデバイスを使う方向に動いており、「CalabashやAppiumなどに手を出していこうとしている」（中川氏）。
Mobage SDK（クライアントSDK）
クライアントSDKのテストについては、「実際に自分たちでSDKを使ったアプリを開発し、そのアプリ操作を自動化するテストを実行することで、SDKがちゃんと動いているかをチェックする方法でテストをしている」（中川氏）という。UIオートメーションに関しては、複数のデバイスでもテストケースに一貫性を持たせられるよう、「Calabash」や「Appium」を利用。Calabashによるテストについては、自身も執筆に参加した「『WEB+DB PRESS vol.77』（技術評論社刊）の特集1『スマートフォンテスト最前線』をぜひ読んでほしい」と述べた。
最後に中川氏は、Domain Specific Clientの強みを生かしたテストの例を示した。例としたテストの対象と内容、およびテストシナリオは次のとおりである。テストシナリオは、（中川氏があまり好きではないという）Cucumberで書かれている。
●テスト対象
「ゲームから送られるブロードキャストの通知に対し、ユーザーが、モバゲーチャットでnotificationを受け取るか受け取らないかの設定を、モバゲーのサイトから変更する」という機能
●テスト内容
❶ 「ユーザーがログインし設定ページでnotificationの受け取りを有効にすると、notificationのブロードキャストが飛んできて、そのメッセージを確認できる」こと
❷ 「ユーザーがログインし設定ページでnotificationの受け取りを無効にすると、notificationのブロードキャストが飛んできても、そのメッセージを表示しない」こと
●テストシナリオ
Feature: Notification from Games
Scenario: User can receive notification
Given user login to mbga.jp
When user visit to settings page
And user enable to “notification” setting
And game broadcast notification using API
And user visit to Mobage Chat page
Then user can show notification message
Feature: Notification from Games
Scenario: User can ignore notification
Given user login to mbga.jp
When user visit to settings page
And user disable to “notification” setting
And game broadcast notification using API
And user visit to Mobage Chat page
Then user can not show notification message
このシナリオには登場人物としてuserとgameがいるが、それぞれのテストコードの実装に、mobage-browserおよびmobage-api-clientというDomain Specific Clientを使っている点がポイントである。これにより、APIとWebをまたがる結合テストが容易に実装できている。「ここに、Domain Specific Clientにこだわってやってきた利点が出ている。コンポーネント単位のエンド・ツー・エンドのテストから、複数のコンポーネントを対象とするシステムテストまで、クライアントを再利用できるメリットがある」（中川氏）。
全体として、事例や実際に活用しているテスト技術に踏み込んだ密度の濃いセッションであった。
