denaが取り組む software engineer in test

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.

DeNA TechCon 2016

DeNA が取り組むSoftware Engineer in Test

2016/01/29

Masaki NakagawaSWET (Software Engineer in Test) Gr.Quality Management Dept.System Management UnitDeNA Co., Ltd.


DeNA Technical Conference 2016

自己紹介

中川勝樹株式会社ディー・エヌ・エー SWET (Software Engineer in Test)

Testing Casual Talks @ikasam_a github.com/masaki metacpan.org/author/MASAKI

2

https://twitter.com/ikasam_a

https://twitter.com/ikasam_a

https://github.com/masaki

https://github.com/masaki

https://metacpan.org/author/MASAKI

https://metacpan.org/author/MASAKI



SWET

3



Software Engineer in Test

4



今日お話すること

SWET (Software Engineer in Test) とは？これまでの SWET の取り組み SWET の現在、そして未来

5



WHAT IS THE SWET

6



7

Software Engineer in Test,a Quality Assurance job title

in some software companies

en.wikipedia.org/wiki/SET

https://en.wikipedia.org/wiki/SET



8

Software Engineer in Testis also a developer role

except their focus is on testability

googletesting.blogspot.jp/2011/02/how-google-tests-software-part-two.html

http://googletesting.blogspot.jp/2011/02/how-google-tests-software-part-two.html







9

SETs primary focus is on the developer.

Enabling developers to easily test the code they writeis the primary focus of the SET.

googletesting.blogspot.jp/2011/02/how-google-tests-software-part-two.html








Developer Productivity

10



11

SWE SET TE

SWE SWET (and TE)

Google

DeNA

SWE = Software EngineerSET = Software Engineer in Test (Google)TE = Test EngineerSWET = Software Engineer in Test (DeNA)

White Box Approach Black Box Approach



SWET のミッション・ステートメント

1. プロダクト・サービスの品質向上2. エンジニアの開発生産性向上

12

SWET グループは

ソフトウェアテストを起点に品質と開発生産性の向上に取り組む

ソフトウェアエンジニアの集団です



SWET HISTORY

13



SWET ざっくり年表

2012 年プラットフォーム開発の中のチーム Mobage オープンプラットフォーム (WebAPI / WebUI)

2013 年夏メンバーも増えて SWET グループとして組織化 Smartphone 向け Mobage SDK も守備範囲に

2014 年春事業部を出て全社横断組織の SWET グループに “Mobage” から “ DeNA” へ

14



サーバ期(WebAPI, WebUI)

15



2012 年のプラットフォーム

オープンプラットフォームのグローバル展開大規模システムの拡張とリファクタリング（デリバリーの速度はできるだけ落とさずに…）

16

E2E テストを確立して自動化(checking)



RESTful API テスト自動化

API の仕様はグローバルで共通だったまずはバックエンドを抑える

つくったもの⁃ HTTP(S) WebAPI テスト (Perl)⁃ Mobage API 専用クライアント (Perl)• 開発、デバッグにも使えるツールとして

17



ブラウザテスト自動化

次はフロントエンドを抑えに行ったブラウザゲームのプラットフォームなので…

つくったもの⁃ オープンプラットフォームのブラウザテスト (Ruby)⁃ Mobage ブラウザテスト (Ruby)⁃ Mobage 専用クライアント (Ruby)• もちろん開発のお供に

⁃ プラットフォーム機能を使うテストアプリ (Perl/Ruby)

18



技術的な取り組み

2011 年 7 月⁃ Selenium WebDriver (Selenium2) リリース

2011 年その後⁃ フィージビリティ調査

2012 年⁃ ブラウザテストに実戦投入⁃ ブラウザテストのベースとした

19



20

@okitan

@deme0607

@vbanthia

urn:isbn:4774178942



21



クライアント期(Smartphone SDK)

22



2013 年のプラットフォーム

これまでは、ブラウザ / ゲームサーバが中心だった一方この頃、アプリベースのゲームが増えてきた

23

デバイス上の自動化技術に取り組む機運の高まり



Smartphone SDK の自動化の課題

SDK 単体では、 SDK の機能テストを実行できない⁃ SDK を使ったテストドライバが必要⁃ なので SDK を使ったテストアプリを作ることに⁃ そしてそのアプリを、どうにかして自動操作する

SDK は種類が色々ある⁃ for Android (Java)⁃ for iOS (Objective-C)⁃ for Unity (C#)⁃ フレームワーク選定の難しさ• OS の差異を（ある程度）吸収できるものもある• 引き換えに操作可能な部分が限定される場合もある

24



Smartphone SDK の自動化

つくったもの⁃ SDK を使ったテストアプリ• for Android (Java)• for iOS (Objective-C)• for Unity (C#)

⁃ テストアプリを使ったモバイルテスト• for Android (Java + Ruby)• for iOS (Objective-C + Ruby)

25



技術的な取り組み

Mobile Automation⁃ まだデファクトが確立されていない⁃ なのでフレームワークも群雄割拠⁃ もちろんそれぞれにメリット・デメリットがある⁃ 自動化の要件次第で選択肢が変わってくる

取り組み⁃ 昔は Calabash を使っていた⁃ ブラウザテストとの統合も見据えて Appium に着手

26



27

urn:isbn:4774159905



28

urn:isbn:4774159905



NOW AND FUTURE

29



NOW

30



プラットフォームの SWET として

各種自動テストに対応⁃ WebAPI 、 WebUI 、 Smartphone SDK/Application

その過程で各種アプリケーションも作成⁃ Web アプリ、スマートフォンアプリ

大規模サービスの CI 環境構築⁃ コンポーネント数が半端ない…⁃ “Jenkins 職人”

31



全社横断組織の SWET として

各サービス・プロダクトへの対応⁃ Game BaaS のサポートを開始⁃ 他にも相談ベースでテストアーキテクチャコンサルなど

技術の全社展開⁃ テスト基盤チームを作りました• 今まで蓄積した技術の横展開ができるように• サービス横断で使える技術開発のために• 先端技術の実用化を進めるために

32



具体的な最近の取り組み

モバイル自動テストの技術開発プライベートデバイスファーム構築テスト環境の高速化・仮想化 CI基盤環境の構築

33

エンジニアの開発生産性向上によりフォーカス基盤技術、テスト基盤としての取り組みを強化



テスト環境の高速化

シナリオテストあるある⁃ 実行に時間がかかる• よろしい、ならば並列化だ

⁃ 分割したけど Worker によってバラつきがある• 物理的なファイル数やサイズでの分割による限界• 論理的なシナリオ単位でできるだけ均等に分けたい

テスト実行計画管理ツールを作りました⁃ 並列数に応じてシナリオを分割⁃ シナリオ単位の実行時間を集計⁃ 累積集計結果を次回実行計画に反映

34



テスト環境の仮想化

背景⁃ 分割・並列で高速化できたので、有効活用したい⁃ 環境準備が意外と面倒なのは昔からの課題• 構成管理、プロビジョニングも流行るわけで…

Docker はじめました⁃ Selenium + Appium + Docker

35



デバイスファーム

デバイスファームとは？⁃ “ クラウド上にある複数のデバイスを、リモートで操作可

能にしたもの” と呼んでいます Smartphone Test Farm (STF)

⁃ OSS のオンプレミス・デバイスファームシステム⁃ openstf.io

STF の導入・運用・開発⁃ コミッターが在籍 (@vbanthia)⁃ モバイル検証・モバイル自動テストに実践導入中

36

http://openstf.io/



デバイスファームの活用

モバイル検証⁃ 検証用デバイスとしての利用方法⁃ 手元にデバイスを置かずにリモートで操作⁃ デバイスのログやスクリーンショットの取得が容易⁃ アプリケーションインストールなど面倒な操作も容易

モバイル自動テスト⁃ 自動テストの実行デバイスとしての利用方法⁃ そのためには API でのデバイス操作が不可欠になった⁃ なので API を実装しました (v2.0.0)

37



DEMO

38



FUTURE

39



これからの SWET 方向性

⁃ モバイルテスティング関連技術⁃ テスト基盤技術⁃ … でもきっと増えると思います• 例えば IoT とかどんどん来ますよね

想い⁃ 引き続き技術基盤としての立ち位置は大事にしたい⁃ 課題解決のためのエンジニアリングを忘れずに

40



今日お話したこと

SWET (Software Engineer in Test) とは？⁃ どのような役割なのか⁃ どのようなミッションを持っているのか

これまでの SWET の取り組み⁃ Mobage オープンプラットフォームでの取り組み

SWET の現在、そして未来⁃ 開発生産性向上へのフォーカス⁃ テスト基盤としての取り組み

41



SWET というキャリアパス

キャリアの認知度として⁃ まだ認知度が高いとは言えない役割ではある⁃ だからこそのやりがい

エンジニアの成長として⁃ 開拓すべき新しい技術がたくさんある• 技術的チャレンジの機会が多い

⁃ 開発サイクルの全般に関わるエンジニアのキャリアパスとして

⁃ 僕はアーキテクトに繋がる 1 つの道だと思います• テストアーキテクチャにはシステムデザインが要求される• 技術的な幅や視野の広さも要求される

42



ご清聴ありがとうございました

43

denaが取り組む software engineer in test

Technology