第四回Ques に参加してきました。

f:id:ea54595:20140422232305p:plain

会社の業務で遅刻したため前半の機械学習の自動化についてはほぼ終わり際のみですが。。
Mobageの自動化周りに話は面白かったです。
特にスマートフォン周りは業務で経験が無いため非常に参考になりました。

では以下メモ。

第一部.機械学習実装のテスト自動化

株式会社ALBERT システム開発部・コンサルティング部システム開発チーム
小宮篤史さん

※途中から参加したためこれより前の話は不明....

分岐だけでなく数値計算に気をつける。例えばこういった計算。

doubel v;
v = 1 / 0.0; // Infinity
v = 0.0 / 0; // Nan
v = 1 + 0.000_000_000_000_000_09; //1.0
Math.exp(800); // Infinity
Math.log(0); //Negative infinity
Math.log(-1); //Nan

機械学習のテストは業務システムとは異なる知識を求められる。
QAの知識を十分には活用することはできる。

精度を求めるにはアルゴリズムの分析レベルではロバストかどうかは求める。

Q&A

確実なベースラインを作るのは難しいのでは？

ベースラインではパーセプトロン分析を使う。
パーセプトロンが正確なものかの検証をキチンと分析のフェーズでする。
テスト自動化はその後のフェーズ。

どこまで機械学習でできるの？

スパムか正解メールかの分類は人間が行うしかない。（アカデミックでは研究されてるかも）
それと同じ結果になるかをテストする。

統計サイドのエンジニアが意識すべき観点は？

関数の帰ってくる値を認識して欲しい。上記のMath.expなど。
あとはパフォーマンスを意識して欲しい。

第二部.Mobageオープンプラットフォームでのテスト自動化

DeNA システム本部品質管理部 SWETグループ
中川勝樹さん
twitter @ikasam_a
github github@masaki

Mobageオープンプラットフォームとは

Mobageでゲームを公開できる仕組み
http://developer.dena.jp/mbga/
色々なデバイス対応

海外にもプラットフォームを展開。

SWETって何？

DeNAのテスト専属チームのこと。
当初3人から20人へ拡大中。

立ち上げ背景

オープンラットフォームのグローバル展開
大規模システムの拡張とリファクタリング
デリバリーのスピードを落とせない
検証の属人性の解消

➡　テスト専門チームの立ち上げ

Mission

End to End テストを確率する
テストを徹底的にに自動化する
テストしやすい環境を提供する
- テストしやすい環境とは?
  - 単体テストのREDが消えない問題　QCDの優先順位でREDのまま
  - リリーススピード
  - CI環境の整備

何故独立チームなのか？

横串チームによる戦略的な他プロダクトへのテストノウハウを横展開するため

そもそもSWETってどういう意味？

Software Engneer In Test
Missionは Quality Assurance

他の会社の読み方違うけど役割は同じ

company	Team	Name
Google	SET	Software Engneer In Test
MicroSost	SDET	Software Development/Design in Engneer Test
DeNA	SWET	SoftWare Engneer In Test

SETの役割

テスタビリティにフォーカスした開発者
デザインレビュー
テスタビリティ向上のためのプロダクトコードのリファクタリング
テストフレームワークを開発する

TE(Test Engneer)の役割

テストファースト
テストを自動化していく
テスト結果に関わる
テスト実行をドライブする

TEと違いSETは開発者にフォーカスしている

個々の質を上げる
開発者のテストをしやすくるする

Developer Productivity

技術基盤など開発の生産性向上を行う

SWET = SETの役割 + TEの役割

SETはテストに絞ったDeveloper Productivity向上のためのチーム
テスト対象の開発もできるぐらい技術と仕様を理解できる

プラットフォームテスト自動化戦略

対象領域 1. WebAPI 2. Web Application 3. Mobile Web 4. Client SDK

意識していること

適切なシステム分割をする
- システムビッグバンを避ける
サーバで完結できるところはサーバで
- WebAPIの機能テストはクライアント無しで
- ブラウザを使う場合は実記で

スマートフォンテスト自動化

テスト対象によってテスト方法も異なる

1.WebAPI, Webアプリ

ブラウザの自動化技術をそのまま使う

Selenium　WebDriver
スマートフォンブラウザを偽装(User Agentを変更する)
PC版のテストコードを流用して実機で動かす
- appium (w/ JSON Wire Protocol)
- Seleniumのネイティブ版

Capabilityでドライバを選択ブラウザによってDesiredCapabilityを選択

DesiredCapabilities capability=DesiredCapabilities.internetExplorer();
capability.setCapability(
              InternetExplorerDriver.INTRODUCE_FLAKINESS_BY_
IGNORING_SECURITY_DOMAINS, true);
WebDriver webdriver = new InternetExplorerDriver(capability);

2.ネイティブアプリ、SDK

アプリの操作を自動化する
外部からプロセスにアタッチして操作
- Appium
テスト用ライブラリを埋め込んで操作
- Calabash
- 自分たちでコードを弄れる場合のみ
- ただしアプリ改変になるため一部にするなど考える必要がある

最近はAppiumを使って直接プロダクトコードには手を加えない

SDKでは

ライブラリを組み込んだテストアプリを作成
ライブラリの機能を網羅できるようにつくる
テストアプリの操作を自動化
あとはネイティブアプリと同様

ブラウザテストはRubyでやっているのでそれを流用している

Rspec
selenium
capybara
headless Browser
- Phamtom.js

httpのアサーションなどブラウザ単体ではできない部分のため
セッション情報を渡して途中からMechanizeに切り替えてテストをしている

Q&A

プロダクトの改修などとの関わり方は？

SWETチームから各プロダクトチームに1名派遣されている SWET同士で情報交換をしている

テストだけだとモチベートしにくいのでは？

あくまでもプロダクトを出す事が目的。関わり方が違うだけと話している。

テストコードのメンテナンスはどうしている？特にGUIは変更が多いが？

テストに強い変更をする。テスタビリティの高い設計をメンバーにインプットしている。設計レビュー、コードレビューもしている。

Appiumが動かないAndroidはどうする？

Selendroidを組み合わせて使う。書き方が変わる部分はフレームワークを開発して対処。

Rubyでテストしている理由は？

自分が得意なのとPerlはSeleniumの公式ドライバが無いから。

Inside Out

自分自身の備忘録。アウトプット用のブログです。

第四回Ques 参加してきました