最近テストづいている？勢いで、GREE Tech Talk #04 : スマートフォン時代のソフトウェアテストに行ってきたのでメモ。

WAPとかCiRCUSとかHT03AとかIS01とか懐かしいキーワードが出てきたりUnityの話が聞けたりと、幅広く、そしてスマートフォンの闇の深さを再認識できた良いイベントでした。

モバイルテスティング・クロニクル

まず松木さんの講演。モバイルおよびそのテストの歴史、現在（スマートフォン時代）に求められる品質モデルの話など。

アプリの品質要素、iOS/Androidともセキュリティ＆プライバシーのプライオリティがダントツに高い
プライバシー保護については、セキュリティが確保されているのが前提

ちっともスマートじゃないスマートフォンアプリのテスト事情

GREEでTest Engineering Teamを立ちあげた山本さんの講演。

Androidは機種が多く、ユーザから不具合報告がある端末は高い確率で社内にない
同じモデルでもキャリアや国によって違う。Galaxy S4だけで12種類のバリエーション
IS01みたいな変態端末
チップセットなどの要素をもとにペアワイズ法でテスト対象機種を絞り込む
アプリがテストチームに渡ってから2日でリリースされるので、できるテストが限られる
先月からTest Engineering Teamを立ちあげ、
- まずドリランドでリグレッションの自動化を進めている。新規機能は手動で行なう。テスト実行環境はエミュレータ
- 課金機能について、Calabashで実機検証環境を整えようとしている

シェアカバー率について書き損じたので引用

やまもとさん「Androidは30機種揃えてでシェア55.5%、50機種で72%、100機種で99%」 #greetech04
— しんすく(け) ぱん。 (@snsk) 2013, 12月 5

Test Engineering Teamについてはこちらの書籍を参照

テストから見えてくるグーグルのソフトウェア開発

作者: ジェームズ・ウィテカー,ジェーソン・アーボン,ジェフ・キャローロ,長尾高弘
出版社/メーカー: 日経BP社
発売日: 2013/05/23
メディア: 単行本
この商品を含むブログ (4件) を見る

UnityによるGameObjectとコルーチンを利用したTestingフレームワーク

GREEの奥村さんの講演。

C#のユニットテストフレームワークとしてSharpUnitがあるが、以下の制約がある

1フレームで完結するものしか書けない
テストのツリーをコードベースで編集
失敗がログでしかわからない、どのテストが落ちたのかわからない

Unityにはそれぞれ補完できそうな機能が備わっているので、これらを改善できるフレームワークUniUnitTestを作った。これは近日オープンソース化されるとのこと。

Unityで作られたアプリがiOS/Androidで動くとは言っても、環境固有の問題は発生し得る。例としてアセットをアプリにバンドルしたとき、Androidではfile:///スキームでアクセスする必要があるなど*1。

Jenkinsによるテスト自動化の会社への導入

太田さん@SHIFT、岡崎さん@GREE、粉川さん@SEGAによるパネルディスカッション。皆さんドンキで買ったJenkinsさんコスプレで登壇。

内部品質はアプリの売上と必ずしも比例しない
ソシャゲのイベント投入などで上がる売上と、その修正にかかるコストの問題。コストが見合わないなら撤退
テスト自動化しやすいコードは既によくできている
既存のテストの無いプロダクト、テスト自動化しにくい場合は「あきらめる」も選択肢
できるところからはじめる
- ステートレスなユーティリティクラスはテスト書きやすい
- 静的検証ツールを使う。その指摘を通じて保守性の高い設計と実装をチームに学習させることでテスタブルなコードに変わっていく。これはQAからの指摘ではなく、開発チームのアーキテクト主導で実施してもらった
ビルドやデプロイの自動化だけでも効果はある
テストコードのカバー率、数などにゲーミフィケーションを導入して改善していく。1000本目のテストコードを書いた人、など

静的検証ツールのところ、詳細を質問しておきながら自分でメモ取れてなかったので引用

静的検証ツール導入するときも、最低限のレベルからはじめないと無理。JavaならCheckStyleは無視。FindBugsの優先度最高の指摘だけ直してね、というレベルからはじめる。サイクロマチック数も、かなり緩い限界値だけ示す。 #greetech04
— TOYAMA Sumio (@sumio_tym) 2013, 12月 5