OpenSTF の導入によるゲーム開発への貢献

2015/12/08

GREE Advent Calendar 2015 の8日目担当の @ma3tk です。QualityAssurance 部で QA エンジニアという職種をやっています。

本日も昨日に引き続き QA についてのお話です。

昨日のやまもとさんのグリーのテストエンジニアとテスト戦略という記事で、弊社の QualityAssurance 部の体制や Web ゲーム領域と新規事業領域の品質保証について言及されていますので、そちらも合わせてご覧いただけると幸いです。

さて、この記事では「多数の端末で実機テストする際に便利な社内サービスを提供していること」についてご紹介したいと思います。

 

その前に QA エンジニア とは何なの？

一言で言えば、「プロダクトの生産性と品質向上に対し、技術面から支えるエンジニア」です。

ゲーム開発はここ数年でより品質の高いものを提供する必要があり、複雑化・長期化してきています。

その中で、面白いゲームを効率よく開発するためにゲーム開発エンジニアはゲーム開発に必要な部分に対し責務を持ち、 QA エンジニアはそれ以外の品質を向上させるために必要な機能や各プロダクトの QA 担当者にとってあると嬉しい機能を開発することで役割分担をし、全体として生産性と品質が上がるような体制を取っています。

この記事中では具体的な解説はしませんが、過去に CEDEC で登壇した際の資料により詳しいことが書いてありますので、そちらをご覧ください。

そして現在、弊社の QA エンジニアは社内向けのサービスを提供し始めました。まずその一つ目は、 OSS の OpenSTF を利用した STF というサービスです。

 

OpenSTF (Smartphone Test Farm) とは？

OpenSTF とはサイバーエージェント社製の OSS です。 Websocket を利用しブラウザからリモートで Android 実機を遠隔操作/検証することができるサービスです。

また、OpenSTF を社内ツールとして利用したものを弊社では STF と呼んでいます。

STF を使うことでのメリット

このソフトウェアでは例えば以下のような事が可能になります。

  • いつでもブラウザから簡単に実機での検証が可能
  • 複数台同時にデザインチェックが可能
  • システムログをリアルタイム取得可能
  • ドラッグ＆ドロップでアプリをすぐにインストール可能
  • UI の統一による Android 端末の多様性の吸収
  • 特定条件の端末を探すコストの低減

こういった特徴を持つソフトウェアですが、実際に社内でサービス/社内ツールとして提供することでさらに以下の様なメリットが享受できます。

  • 多端末でのテストがコミュニケーションレスに行える
  • サーバで稼働することにより24時間使える
  • 端末貸出サービスまで物理的に移動する手間が減る
  • 物理的な移動がないため端末紛失リスクが低減する
  • 利用頻度をログから取得して今後の運用に役立てられる
  • 返却忘れという概念がないに等しい

特に大規模な会社や多くの端末を保持している場合にはこのメリットを活かせると思います。

 

実際の設置について

さて、弊社でもこのシステムを構築し運用してみよう、ということで実際に社内に設置してみました。(写真1)

stf_before
写真1: STFのお試し構築時

ネットワークに繋がるサーバを置いて、 USB 刺して、ソフトウェア起動、と準備はスムーズにできました。しかしながら運用をいざ始めるとなると、実際には様々な制約が生じる事に気づきました。

  • 会社のセキュリティ上、端末を紛失しない安全な場所に置くこと
  • 多数の端末が発熱することを考慮し、排熱できる状態を作ること
  • 端末が社内で漏れ無く管理されていることを確認できる状態を作ること
  • 多数の端末がWi-Fiを飛ばすので、電波が他者に影響を及ぼさないこと
  • どの端末がどこにつながっているか把握できる状態を作ること

上記の写真を見てわかるかと思いますが、制約をクリアしきれていません。

そこで社内のインフラチームの協力もありサーバ室のスペースと専用の無線アクセスポイントを借りることができました。このサーバ室はセキュリティ、室温管理による排熱が十分な状態にあることに加え、今回専用アクセスポイントがあることで他者にとっても影響を及ばさない状態を作ることができました。

また、最終的に端末用のアクリルケースを設置し、端末のケーブルにシールを貼ることで端末がどこにあるか一目でわかる状態を作りました。(写真2)

stf_after
写真2: 運用開始前の STF 接続端末

こちらの詳しいお話は 以前外部に登壇した時の資料 がありますので、そちらも合わせてご覧いただけるといいかと思います。

 

STF を使ったテストの支援

今回プロダクトを開発しているチームにとっても工数をかけずに端末の自動化テストを行うことで、プロダクトにとって有益になる方法がないかを考えた時に、端末が24時間端末が使えるという特性を活かしてモンキーテストを STF 上で行ってみることにしました。

モンキーテストとは

簡単に言うと、ランダムにタップやボタンの操作を行い続け、バグを発見するテストです。

使い所としては空き時間や夜中などに定期的にビルドを実行しバグが出ないかを見つける事ができます。

基本的に非効率なテストなので、不具合が見つかったらラッキーくらいの宝くじ気分で実施します。また、同じビルドかつビルドのステータスが同じ状態(アプリ未スタート)で、同じ設定(シードや実施間隔)でモンキーテストを実行することで、クライアントサイドに関する問題であれば 100% 問題を再現することが出来るはずです。

意図しない操作を自動的に行ってくれるので、メモリリークなども発見できることもあります。

現在、弊社では機能全体の主要な動きを通しで実施するプレイスルーテストや、ケース等を用意せずテスト実行者の感覚でテスト対象や内容を決めながら実施する探索テストを手動で実施をしています。

しかし、プレイスルーテストの自動化は現在費用対効果の関係上行っていません。具体的に、一般のアプリケーションに比べゲーム開発では画面の UI 等が複雑であることや変更が頻繁に行われるため、クライアント側でのプレイスルーテストの自動化はテスト内容の修正コストが大変で、費用対効果上実施していません。

モンキーテストならば、ランダムに画面を操作するため画面の変更に関係ないテスト手法です。そのため常にテストが実施が可能です。

また、Android の adb コマンドでは、モンキーテストができるようなオプションが入っています。これを使って実際にテストを行ってみました。

STF を使った簡単なモンキーテストのやり方

具体的な方法を記載してみます。

前提

大前提として以下の準備が必要です。

  • STF が稼働し、端末が 1台以上利用可能なこと
  • 利用したい端末でテストしたいアプリがインストール済みなこと
  • アプリのパッケージ ID がわかっている

今回は、消滅都市 をインストールした端末でモンキーテストを実施することにします。

アプリのパッケージ ID は net.wrightflyer.shoumetsu です。

1. 端末を利用する

STF にブラウザからアクセスし、任意の端末を借りる(図1)

stf_login
図1: STF ログイン後の画面

2. リモート操作画面右上の スイッチを Native にする

これを Native にしないと該当の項目が出てきません。(図2)

2463526-40fb0599062f7838bc5e177df32bd49d65ee3305
図2: スイッチの切替

3. モンキーテスト用のコマンドを作成する

adb コマンドの monkey を利用します。

adb monkey の詳細については公式のドキュメントを御覧ください。

今回は下記のように、設定しました。

上記のコマンドは、 「消滅都市を 300 ミリセカンドのディレイで 100 コマンド分ランダムに操作を行い、その操作の内訳としては 画面上の任意の位置を100% の確率でタップする」というような内容です。

※本来コマンドラインで実行する場合、 adb shell monkey 〜 のように記載しますが、 STF の画面上で端末に対し直接操作するため、 monkey 〜 から記載しています。

4. 実際にコマンドを実行してみる

先ほどの 2. で Native にスイッチを切り替えると、 シェルという項目が出てきます。(図3)

このインプットボックスで先ほどのコマンドを入力すると、アプリが勝手に動き出します。

シードの設定や実施するアクション等を細かく設定できるので、各パラメータを調整して試してみるといいと思います。

また、平日の日中にこれを行うと端末が専有されてしまうため、始業前や帰社後などの会社が非アクティブな時間に実施するとベターかもしれません。

stf_shell
図3: シェルの入力部分

 

STF と AWS Device Farm の使い勝手の違い

ここまで、OpenSTF を使った STF 社内サービスについて紹介してきました。OSS 化されているもの以外にも現在様々な自動化テストサービスが提供されています。

ご存じの方も多いかと思いますが、 例えば AWS でも AWS Device Farm というサービスが提供されています。今後同様のサービスが Google でも提供される予定とのことで、クラウド上での多端末テストがより一層発展してくると思われます。

これらのサービスでクラウド上で端末のテストが可能ですが、具体的にクラウド上でのテストサービスは CI (Continuous Integration) として自動化テストを実施する側面が強いと考えられます。逆に STF はユーザ自身が画面を見て確認しながら行ったり、手元の検証用端末をオンラインでできるようにしたといった違いが有ります。

2015年12月8日現時点の AWS Device Farm の一覧にはグローバルモデルが中心で日本のキャリア端末が無いため、ネットワークの疎通テストなどのためにどうしても自身で端末を準備する必要があります。

もちろん、 STF でもリモートの STF 接続端末に adb connect をした上で端末にコマンド送ることで自動化テストも可能です。

どちらもメリット・デメリットがあるため、うまく使い分けられるといいかと思います。

 

STF を使った QA エンジニアリングでの支援

さて、STFを使ったモンキーテストのやり方についてご紹介していきました。他に実際タップを記録し、その動きを自動化させることによってプレイスルーテストの自動化ができそうで、今後弊社でも実施できるようにしていきたいと思います。

コマンドラインからのテストや各種端末のバッテリー温度を利用した非機能テスト等を行う際に STF を活かせそうです。

 

振り返り

今回この社内サービスを導入したことにより、社内から多くの反響をいただきました。本来、ネイティブゲームの開発を中心に使えるのではないかと予想していましたが、ウェブゲームを開発しているプロダクトにとってもテストの自動化や検証などが便利になったという声も頂きました。導入できて本当に良かったと思っています。

無事導入はできたものの、課題は多く残っています。

特に直近では、端末を増やした場合に十分スケールするような機材の準備が必要です。サーバに限らず、ネットワーク環境や物理的スペースの確保などについてこれからも考えていかなくてはなりません。

そして、社内の先進的な利用事例を他プロダクトへ横展開することで、より魅力的なサービスとして提供していけると考えています。

より楽に、そしてより効率的に品質を担保できるような仕組みや支援をQAエンジニアとして提供していくことで、今後のゲーム開発支援と品質の担保を行っていければと思っています。

明日は @nov さんによる OAuth の記事が掲載される予定です。お楽しみに！！