Developers Summit2014[13-A-6] Mobageを支えるテストエンジニアリング
[13-A-6] Mobageを支えるテストエンジニアリング
Mobage Open Platformについて
Mobageでゲームを公開できる仕組み。 複数デバイスに対応
- Feature Phone
- Smartphone
- PC
2009年夏にスタート。国内プラットフォームとしては、
ガラケーからY!、スマホ、Mixiなどに対応していった。
SWETグループを作った背景
立ち上げ背景
- プラットフォームのグローバル展開
- 大規模システムの拡張とリファクタリング
- デリバリーのスピードを落とさない。
- 懸賞属人性の解消
日本と同じ品質を提供、かつ大規模システムとしてのリファクタリングが必要。
当時はテスターに属人化していた。一人のテスターの勤怠にリリースが左右される状態。
立ち上げの方針
- End to Endテストを確立する
- 徹底的なテスト自動化
- テストしやすい環境を提供する
テストしやすい環境
- 単体テストのREDが消えない問題
- リリース頻度・速度・影響範囲のバランス
- テスト時間のコスト問題
- CIの必要性
割り切りや、時間的制約に直面することがあり、CIの必要性を痛感していた。
立ち上げ
当初はQAチームとして３人。２年間で１６人で仕事。
なぜ独立したチームなのか？
→横串チームによる「戦略的横展開」を狙う。
SWETって何？
SoftWare Engineer Testの略。SETのDeNa版。
SETの役割
テスタビリティに特化した開発者の役割。レビューもする。テストに適したリファクタリングも行う。
テストエンジニアの役割ではない。テストエンジニアはテストの分析。
実行推進。自動化など。
SETは開発者にフォーカスしている。個々の機能を見たり、開発者がテストしやすい環境を作る。
DeveloperProductivityにフォーカスしている。
SWET = SET + TE
DeveloperProductivityも。Quality Assuranceを両立したい！
Mission Statement
- Keep the quality of platform
- improve the quality and prodauctivity of platform
あくまでエンジニア。
テスト対象を開発することができる。テスターではなく、テストエンジニアであること。
SWETグループって何やってるの？
サーバサイドのテスト
クライアントのテスト
全方位的なテストをしても無尽蔵なテストが必要になるだけ。
テストの分類などをして有効なテストを考える。
Who
デブテストなのか受け入れテストなのか
Which
How
ブラックボックス・ホワイトボックス・グレイボックステスト
What
機能テスト、非機能テスト。
RESfulAPI（WebAPI）
Mobage Developers(webアプリ)
mbga.jp Proxy serverモバイルウェブ
Mobage SDK (クライアント)
直接開発社、ユーザーにふれる外部インターフェースのテストを重視。
WebAPIに対するテスト
HTTP.JSONレスポンス、UIなしが条件。
同じセグメントの中にテストクライアントを置く。テストクライアントからDBやキャッシュの中も参照、編集できる。
ブラックボックス的に内部的な情報にアクセスしない。
ホワイトボックス的にE2Eではない。
グレイボックス！ホワイトボックス的な操作をしながらブラックボックステストを行う
事前条件として、キャッシュ情報やDBの状態を操作しておく。
特定の機能、Mdに対するテスト、ドメインに特化したクライアントを作成してテストを行う。
メッセージダンピングを行なって、レスポンシブなテストも行う。
WebApp/MobileWebに対するテスト
HTTP送信、HTTPレスポンス、ブラウザ上でのテスト。
SeleniumWebDriverを利用して、RSpec、headLessBrowserを利用。
エミュレーターとブラウザを使いわけしながらテストしている。
ブラウザはHTTPヘッターにタッチできない。エミュレータはJavaScriptを解釈できない。
DomainSpecificClientとしてモバゲーブラウザを利用している。Page Object Paternは使っていない。
Client SDKのテスト
アプリ実際に作ってSDKを叩いみてテスト
UI Auth 複数デバイスでも共通のテストケースを流せるように。carabashなどを利用している。
