BLOG.tass.io

GTAC2014まとめ抄訳

2014-11-02

日本ではあまり話題になりませんが、今年もGoogle主催のテスト自動化カンファレンス「Google Test Automation Conference 2014(GTAC2014)」が開催されました。\

GTACの様子は全てyoutubeで見ることができますが、1日目2日目で合計16時間分もあるので、全て観るには結構な気合が必要です…。

そこで、testdroidのブログがいい感じ(1日目2日目)にまとめてくれているので、抄訳してお送りします。 testdroidがモバイルテストの会社なので、WebよりもAndroid/iOS関連のテストの話題が中心です。そのあたりは御了承ください(^_^;

リンク

実機 vs エミュレータ?

testdroidの記事にもあるのですが、AndroidであれiOSであれ、 エミュレータではなく実機でテストするべきという点を多くの方が同意しているようです。 そもそもエミュレータを肯定的に捉えている人が少ない感じ。 ハードウェア関連のテストをするだけでなく、ネットワーク等のユーザ条件やUXをテストする上でも、実機でテストするのがベストとのこと。

「そんなこと言われても、実機を揃えるのは大変過ぎて…」という方は、ぜひtestdroidを使ってみるといいんじゃないでしょうかw

NativeアプリとWebのテストの話題ばかり。あれ、ゲームは・・・??

WebやNativeアプリのテスティング、そしてその周辺技術に関するプレゼンテーションが多かったようで、 記者のヘルッピはモバイルゲームに関するプレゼンが無かったことを残念がっているようでした。

testdroidではモバイルゲームに関する記事がいつくも上がっているので、興味がある方はこちらを 読まれると良いと思います。特に無料の電子書籍“How to Build a Million-Download Mobile Game”は 一読の価値がありです。

注目のフレームワーク「Appium」!

Googleのエンジニア達は、AndroidではuiautomatorEspresso、iOSではKIF frameworkを好んでいるとのことです。Swift時代になると、KIFの代替とか出てくるのかしら…。\

ただ、いくつかのセッションではAppiumの話題もあがっており、徐々に熱が高まっているようです。 今年は国内でもAppiumのセミナーがあったりと、UIテストのデファクトはどこに落ち着くのか。まだまだ注目なのです!(•̀ᴗ•́)و ̑̑ フレーキ−・テスト


フレーキー・テスト(Flaky tests/成功したり失敗したりするテスト)を、多くのプレゼンテーターが口にしていたようです。 モバイルのテスト、特にUIが絡むテストでは常に同じ結果になるとは限らず、四苦八苦することが間々あります。テストの失敗が検出されたものの、もう一度テストを実行すると再現せず、、、という事態に遭遇すると、その調査確認にまた多大な時間が必要になります。 モバイルテストが100%再現可能なテストフレームワークの登場が待たれますね。。。

密閉テスト

密閉テスト(Hermetic tests)とは、クライアント単体でテストを完結させるものです。 クライアント側は単独でテストを行い、サーバの応答はモック等でエミュレートすることで実現します。 E2Eテストとは別に、こういったテストも組み合わせて行うのが主流になりつつあるようです。

後述するサーバーサイドのモックフレームワークとも密接に関わってきますね。

Facebookが営む”テストの温室”

これはぜひプレゼンを見たほうが良いと思います。動画はこちら https://www.youtube.com/watch?v=Stjc80e15-c#t=1h11m32s

Facebookが運用している、テストの品質管理システムのプレゼンです。\

プロダクトの品質管理ではなく、「テストコードの品質管理をBOTが行っている」ことがミソ。テストは自動的に識別され、テスト結果が再び信頼できるようにフレーキ−なテストはBOTにより無効化されるそうです。すごいな!

2009年の黎明期、Facebookはコードを書くことに集中する余り、多くのバグを持っていたそうです。\

自動テストを導入したものの、テストコードの増加に伴い、フレーキ−なテストも増大して、「(良くわからないけど)テストが失敗した」という事態も増えてきました。 テストの見直しには時間もかかり他の開発者の邪魔もして開発スピードが落ちますが、怠れば自動テスト自体の信頼性が失われてしまう悪循環に陥ります。

その対策として、Facebookは良好なテスト状態を保つための“温室(グリーンハウス)”を構築しました。 人が介入することなく、BOTによって「テストの品質」が管理され、”良いテスト”だけが温室の中に居ることを許されます。 不意に失敗する等の”悪いテスト”はBOTによって摘み取られて、再実行されたりして判別され、状態が決まります。\

人の手を使わずに良好なテスト環境を保ち、悪いテストだけを抽出して改善を促すシステムを構築したとのことです。

よく考えられてます。ってか、もっと知りたい…(๑•ૅㅁ•๑)

サーバーサイド・モックフレームワーク “WireMock”と”MSL”

話題が戻って、「じゃあクライアント側は密閉テストするとして、そのモックはどう準備するよ?」という話で、サーバーサイドのモックフレームワークについての発表がアツかったようです。 アメリカン・エキスプレスからはWireMock、そしてまさかの大御所、FINRA(全米金融取引業規制機関)からはMSL(ミサイル)についての発表がありました。 FINRAは積極的にオープンソースプロジェクトも公開しているのですね、知りませんでした…。

密閉テストについては、以前にtestdroidにも記事がありました。こちらもぜひ御一読を。

テスト結果のUX向上に向けて

Googleのアレックス・イーグルからは、意外な視点からの発表がありました。「Rich-test-results」と呼ばれるその新しいオープンソースプロジェクトは、テスト結果フォーマットを再構築するものです。\

現状のテスト結果(例えばxUnitでよく使われるXMLフォーマット)はテストの成否はわかるものの、正直、情報が少ないのが難点です。 Rich-test-resultは、より簡単に問題の原因を推測できる情報を持ちつつ、テスト結果を完全に表示現する相互運用可能なフォーマットを提供することを目標としています。

まだまだ初期段階とのことですが、これからが楽しみなプロジェクトですね。

汚染されたモバイル環境を除染せよ

最後の最後に、ややスベリ気味に始まったプレゼンがこちら http://youtu.be/Stjc80e15-c?t=7h13m13s
防護服で登場しての”oh,judas”とかの小芝居は面白かったですw

中身は、2012年にGoogleで起きた炎上案件の話から、如何にAndroidテストの環境を改善していったかのプレゼンでした。 このあたり、既に商用プロダクトとして事業展開しているtestdroidと被っているところもありますね。サイバーエージェントのSTFもオープンソース化するという話ですし、来年にかけてまたアツくなりそうです。

以上、ざっくり抄訳となります。\

GTACもそうなんですが、testdroidなどテストを主眼においたプロダクトも注目されつつありますし、これから積極的にテスト関連の情報を追っていこうと思います。


Michael Kuroneko

Written by Michael Kuroneko. Follow me on twitter, github.