2011年8月6日、東京・王子の日本ノーベル株式会社セミナールームにて、日本Androidの会テスト部主催による「Androidテスト祭り - スマートフォンでテストを楽しむための技術 - from ATEC」が開催されました。
このイベントは単なるアプリ開発におけるテストの事例ではなく、開発局面だけにとどまらずにテストの効率化・自動化や、価値の向上ということを目指し開催されたものです。
Android関連では国内最大級のイベント「ABC2011 Summer」でのアナウンスや、Twitter、ATNDなどでのイベント告知の効果のためか、ほぼ1日で当初の定員をオーバーする申し込みがあり、定員を増やした（50名→70名）にもかかわらず、結果的に170名という定員の2倍以上の申し込みとなるなど、Androidでのテストは非常に関心が高いことを実感できる状況での開催でした。
実際に、TDD研究会の井芹氏、太田氏による効率的なスマートフォンのテストについての講演をはじめ、株式会社ベリサーブの鈴木氏によるAndroid製品テストマップ、株式会社ACCESSの生路氏による受け例テストガイドライン、株式会社ソニックス立花氏によるオープンソースUI自動テストツールの実演、さらに、 .NET開発者の尾上氏からMVCパターンの応用であるMVVMパターンなど、貴重なお話を聞くことができる機会となりました。
第1回 Androidテスト祭り ホームページ
ATNDによる募集ページ
では、実際のイベントの様子を紹介していきましょう。
おっと、その前に受付の様子を紹介します。
受付の様子
ご来場された方は、まず、浴衣・着物の美女の受付に驚かれたかもしれません（これを目的に来られた方がいるかも？） 。
実際に来場された方は約70名（講演者、スタッフは除く）で、会場は補助用の座席も含め、最初からほぼ満席でした（UStreamでの中継も常時60名以上の方が視聴されていた模様です） 。開始30分前から受付を開始し、定刻通り13時より開催されました。
Androidアプリ開発でのテストの現状を概括 ～ 開“祭”の挨拶
まず、テスト祭り開催の挨拶として、日本Androidの会テスト部 副部長の松木氏から、テスト部の活動紹介とAndroid開発におけるテストの状況についての講演がありました。松木氏はJaSST（ソフトウェアテストシンポジウム）の実行委員としても活躍されています。
松木晋祐氏（日本Androidの会テスト部副部長/株式会社ACCESS）@snsk
まず、テスト部の活動紹介として、ツイッターのクライアント（testter）をテスト対象として、テストの方法など追求、受け入れテストのガイドラインの策定、翻訳、コードリーディングを行っている等の説明がありました。
続いて、Androidを取り巻く状況として、市場シェア、インストールバージョンのシェア状況の説明に続き、端末間の違いなどにより、テストが困難になっている現状が解説されました。そして、Androidのテストにおける課題のまとめ、また、Vモデルにマッピングすると上層はAndroid固有、下層はテスト全般の問題が多いことなどから、テスト実施の方法を改善する必要性を確認したところで、講演プログラムの開始となりました。
効率的なテストを追求する！ ～ Keynote
次にKeynoteとして、TDD研究会をはじめJaSSTやWACATEなどのソフトウェアテストに関する団体で活躍されている、太田氏、井芹氏のリレーで、「 より効率的に開発するために ～スマートフォン時代のソフトウェアテスト・アプローチ」と題した講演がありました。
太田氏からは、Androidにおけるテストを容易にするために設計、とくにアーキテクチャパターンに注目した効率化の方向性が語られました。井芹氏からは開発者テスト、つまり（テスト工程に対する）開発工程内でテストを活用するという発想で、さまざまなアプローチの仕方が示されました。
太田 健一郎氏（TDD研究会）@oota_ken
太田氏の講演テーマは、アーキテクチャパターンに注目した効率化でした。
「Androidはテストが大変、なぜなら、開発要求が大変、自動化なども進んでいないから。しかし、テストは重要であり、ターゲットがBtoCなので、特に重要なのは当たり前だが品質となる」
「効果的かつ効率的なテストのためには、テストの容易性を追求しなくてはならない」
「テストの容易性とは、構造化設計、オブジェクト指向設計に基づき設計されていること」
というような流れで、話は設計原則に進み、「 依存関係、凝集度、疎結合性を適切にすれば個別にテストしやすい。しかし疎結合をうまく作り込むには、各モジュールのレベルでの検討が必要。これには、エンタープライズ系の開発で得られた疎結合の考え方が有効なはず」とのことでした。
ところが、iOSに比べ、Androidではアーキテクチャパターンがあまり意識されていないのではないか？という問題提起のあと、Androidでは疎結合、DI、ORマッピングなどまでが中心となっていて、サーバーサイドを想定したステートフルモデルなどがあまり意識されていない、という話がありました。
さらに、「 パターン適用には概念は重要ではあるが、実現することが必要であり、パターンを実現するフレームワークを利用するべき。実際にエンタープライズ系でのフレームワークがそのままAndroid版として出てきている。たとえば、Android Bindingを使えば、View、Viewモデルのバインディングができ、Viewから切り離すとPOJOでテストできる、つまりAndroidエミュレータを使わずにテストできるようになる、こういったテストを容易にできることが重要」と締めくくられました。
人によっては理屈っぽく聞こえたかも知れません。しかし、テストを効率的に行うために守るべきことを駆け足で概観していただきました。今回具体例は挙げられませんでしたが、エンタープライズ系開発での経験に裏打ちされた、実践的な話でした。
ここで、井芹氏にバトンタッチされました。「 テストの活用で開発を効率化するには、開発の早期からテストを考慮すること。開発の早期からテストを実施すること」というトピックから講演開始となりました。
井芹 洋輝氏（TDD研究会）
そうした方法として、自動テスト、ユニットテストでバグを再現し、絞り込み、欠陥を特定するデバッギングテストの実例や、自動テキストの継続実行といった例の紹介から話がはじまりました。クールな語り口ですが、早口でのセッション開始、高密度のセッションとなる予感がしました。さっそく「時間が限られているので、詳細は参考書籍に回します、ぜひ読んでください」ということで、参考書籍がいきなり5冊紹介されました、ひるむ暇もなく次の話題へ。
「軽快な開発では開発工程内でのテストで品質を担保しないといけない。開発者テストはその有望な手段」「 ただし開発工程とテスト工程でテストに関わる工数が重複することがある」「 また前倒しでテストを構築するとそのテストの保守・変更コストにより、製品・テストの変更コストが悪化してしまう問題がある」と、アップテンポで問題提起され、解決方法へと進んでいきます。
そして解決には次のように「発想の転換が要求される」とのことでした。
テストを特定工程で構築するほかに、開発中継続的に開発に合わせながらテストを構築する
テスト対象をFixしてテストを作りこむほかに、テスト対象の変化を許容テストで変更をサポートする
担当ばらばらにテストを作るのではなく、全体で全体最適が得られるようにテストを育てる
次に、これらの実現手段として「堅牢なテストの構築」「 開発と一体化したテストプロセス」「 テストを支えるテストインフラの構築」という3案が示されました。そして引き続き、テストインフラの構築について、テスト側と、プロダクト側にわけた、詳細な説明がありました。キーワードは、スローテスト問題、テスト分割・多重化、接合部・制御点の組み込み（開発時に組み込みテストで使う）などです。
堅牢なテストの構築というトピックでの論点は、テスト設計で（開発者テストでは）発想の転換が要求され、YAGNIの原則適用、ビックバンではなく常にテストし、レガシーコード（テストがないコード）を回避すること、コンパクトかつ網羅的なテスト設計を行う、ということでした。堅牢なテストの確保には、テスト実装の工夫が不可欠で、可読性の改善、ハイリスクコードの分離、重複コードの共通化をおこなう必要があるとのこと。
最後に、テストプロセス構築として、「 開発工程の一部としてテストプロセスを作る、フィードバックが必要。開発工程中にテスト設計から実施のプロセスをもうけて、開発にフィードバックする」という話がありました。
この講演では、テストプロセスを開発作業に組み込むという考え方と、その効果、実践方法が説明されました。超高密度の講演に、実際に講演を聞かれた方はついていくのが大変だったと思います。講演資料と参考文献を読んで少しでも追いつくしかなさそうです。
ここで、臨時の休憩をはさんで次の講演になりました（プロジェクターが不調となり、2台から1台へ変更の変更作業を行ったため。あまりの高密度の講演に機械も悲鳴を上げたのかもしれません） 。
各講演のスライドは以下にあります。
Android製品テストマップ
次は、「 Androidのテストで遭難しないために」ということで、Android製品テストマップについての講演が、ベリサーブの鈴木氏からありました。
鈴木 利彦氏（株式会社ベリサーブ）
まず、自己紹介から。「 株式会社ベリサーブは今年で10年、ソフトウェア検証専門の会社としてCSKの検証事業部から独立しました。私はそのときに転籍、ここ1年はAndroidの検証専門でやっています」ということで、Androidテスト専門！の方の講演でした。
まず、Android製品シェアとその品質について、どのような不具合があり、現場の悩みはどんなことなのか、実感をベースに話があり、現場でどんなテストをしているのか紹介されました。
ところが、「 Android製品のテスト、銀の弾丸、魔法の杖がないのはほかと同じ」と、いきなりアンドロイドのデメリットの説明です。デメリットとは、次の2点。
オープンソース、バージョンアップ、機能仕様不明、ネットワーク依存
電池持ち、差別化のためのカスタマイズで不具合の温床
さらに、テスト現場の悩みとして、フィーチャーフォンのアプリ開発では、仕様は意外と決まっていたが、OEMなどでは、仕様わからない、スケジュール厳しい、品質悪いフィーチャーフォンの30倍バグ出る、グローバル・海外メーカとの考えの違い、などがあるとのことでした。
どれだけ大変かという実例として、あるプロジェクトの生データをもとに紹介されました。実際のデータでしたが、1時間あたりのバグ発生が認識できるくらいの不具合の多さに驚きです。
続いて「 テストマップ出さないと看板に偽りありになるので……」ということで、ベリサーブでの標準の手法の説明に移りました。
「最近ソフトの品質上がったと思っていたが、Androidのテストをやってみると、5、6年前の品質にもどってしまった感じ。VSM（Veriserve Standard Method）では、具合が悪くなると基本に戻ることを行っている」「 独自開発だが、一般的なプロセスの流れになっていて、11カテゴリに分けてテストをしている。そのつどテーラリングは必要」「 特徴的なのは、テスト結果報告後振り返りを行うこと（市場に出てから不具合があったか） 」
カテゴリとは、イベント割り込み、アプリケーション連携、マルチタスク、累積稼働、連続機能操作、件数容量フルなど、市場に出て問題になりそうなこと（市場不具合観点）とのことでした、また、重要機能、目玉機能のテストも含めるそうです。
進め方、テスト視点の解説もありました。おおまかには次の通りです。
テスト戦略計画表を作る
カテゴリ別に試験項目を設定
基本機能試験観点、イベント割り込み、アプリケーション連携、マルチタスク、……
セキュリティ観点（ベンダは重視しているとのことです）
強調されていたのは、「 設計・テストの考慮が漏れるのは、割り込み」ということで、「 状態遷移中に割り込みをテストし、問題がなければそれなりの品質になっていると判断してよい、ということを本日提案したい」とのことでした。
最後に、 時間の都合で少しだけ、ツール、ソリューションの紹介があり、地道な改善により、テストの品質が向上し、製品の品質が向上する、という言葉で締めくくられました。
Android受け入れテストガイドライン
生路 茂太（いくじ しげた）氏（株式会社ACCESS）の講演です。「 実はあまりテスト関係の仕事をしていなかった。しかし、プラットフォーム間の違いで苦しんだ経験あり」 、と、自己紹介をされていましたが、はたしてAndroid アプリの受け入れテスト戦略とはなんでしょうか？
生路 茂太氏（株式会社ACCESS）
講演の本題は、「 我々はなにに困っているのか？」との問題提起から始まりました。困っていることは、
ということですが、「 一番の問題は儲からないこと、受け入れテストがそこにどんな役割を果たすのか、情報をシェアしたい」とのこと。どうすれば、どこでも動くもの、かつ売れるモノができるのか、ためのガイドラインが欲しいということで、受け入れテストガイドラインがその役割を果たすということです。
そもそも、受け入れテストとはなんぞや？その答えは 「 ユーザ受け入れテストは、ビジネスで使えることを確かめる」かつ「売れるモノかどうかフィードバックを受ける」とのことです。
受け入れテストの役割を踏まえた上での、Android以外のプラットフォームでの成功例のおさらいとして、次のようにプラットフォーム別のまとめが示されました。
i-modeの場合
動かない問題：きちんとした検証部隊、垂直統合された仕様、製品出荷、サポート
売れない問題：マスマーケット、課金システム（月額）
iOSの場合
動かない問題：制服に体を合わせろ（よいものだからできる）
売れない問題：iTunesでのマーケットの仕組みに依存する
Windowsの場合
動かない問題：動かすことに対して、メーカが必死になる。フリーズしてもそういうモノだという刷り込みがある。アップデートも頻繁にあるが、そういうものだという刷り込み。不具合クレームがMSではなくメーカに来る。
売れない問題：Windows自体がマスマーケット、それ自体がソフトウェア経済
では、Androidはどうなのかというと、
動かない問題：発展途上の民主政治（Googleの提供方針に左右される） 、頻繁なバージョンアップなど（iOSとの比較では、多様性を持っているため）
売れない問題：月額課金の未発達など。結局、刷り込みの違い（無償が当然の様になっている）と、有償か、無償かの問題、それにGoogleはAndroidが売れなくてもつぶれない。
まとめとして、Androidプラットフォームの解決策については、「 統治者の力を持っているGoogleに言う─これは無駄。キャリア・アプリベンダ間でのカルテルを作る─これでは（市場が）分断される」では、どうすればよいかというと 「 OSの変化を待ち、今は低価格を受け入れる」と話されていました。
その状況のもとで、動くモノ、売れるモノを得るためにはどうするのか、ガイドラインを考えてみる。ガイドラインは、守るといいことがあるおまじないみたいなもの、経験則であり、過去のガイドラインをあてはめて、予測できるはずとのことでした。
そして、ガイドラインの策定について、株式会社ACCESSの事例（NF Life Browserの開発事例）で、リリース後情報の収集・分析の実例の説明がありました。各種窓口を設定、専任の要因をアサインし、分類（意見、質問、不具合） 、と報告手段（Twitter, E-mail、コンタクトフォーム）などでデータを集め、6ヵ月間のデータから分析した結果とのこと。
実際の状況は、「 リリースしたタイミングで、一気に情報が来た、その結果を分析した中身を検討した」「 Twitter, E-mail, コンタクトフォームとも同じくらい情報が来る。コンタクトフォームを作るだけでも情報が取れる」とのことでした。そして、とれたデータをナレッジにしていく様子の説明が引き続きあり、このような形で得られた知識を、以下のようにガイドライン化していくといのことでした。
意見→要求の獲得→たとえば、非機能要件のガイドライン
質問→市場認識の獲得→たとえば、（ 操作のしやすさなど）ポリシーのガイドライン
不具合→品質評価の獲得→たとえば、コーディング規約のガイドライン
「今回は株式会社ACCESSの事例紹介をしたが、たとえば、それを業界として取り組むにはどうしたらよいか？という難しい問題がある、こういったガイドラインはナレッジであり、その公開は経営判断になってしまうため。」
解決案としては、日本Androidの会のような非営利団体を通して共有するなどがあるが、まだ具体化していないということでした。
Androidのアプリ開発ビジネスに携わるにあたって、実例に裏付けられた非常に参考になる話でした。
Android向けUIテスト自動化ツール「Scirocco」
立花 優人氏（株式会社ソニックス/ファウンダー スマートデバイスソリューション事業部 アーキテクト）による、AndroidアプリのUIテストを自動化する、オープンソースのツール、Scirocco（シロッコ）の紹介ということで、実機テストに悩みを抱えている方注目のセッションでした。
立花 優人氏（株式会社ソニックス）
まずは株式会社ソニックスの紹介。2010年3月から活動開始した新しい会社で、スマートデバイス、アプリケーション開発を行っているとのこと、アプリ 開発実績の紹介もありました。立花氏はR&Dグループにて、ツールやミドルウェア開発を行っているとのことです。
「Androidアプリ開発の課題は、UIテストの負荷が大きい」実際、テスト項目数50～500、対応端末数1～30、OSのバージョン3～といったところであり、この状況を、そろそろ何とかしたい、そこで紹介するのがSciroccoです。ソースコードは Google Codeで公開されているとのことです。
Sciroccoの説明に移りますが、「 Androidテストのトレンド、テストどうやっていいかわからない、という声をよく聞くので、UI自動化等々が必要と考えSciroccoを作った」とのことでした、UIテストを自動化し、Webで共有、スクリーンショットもとれるとのことです。
仕組みとしては、Robotiumをベースに、Eclipseプラグイン（Scirocco plug-in） 、Scirocco TMSを組み込んだものとのこと。Robotiumは、UIテストコードを簡単に記述できるツールで、たとえば標準のAndroid Testing Frameworkでは8行のテストコードが1行で記述できるようにできるとのことです。先月、プラグインに新機能が追加され、メモリ使用量をテスト報告に含められるとのこと。具体的なテストツールの登場に会場では、興味津々という感じでした。
そして、デモ実施となり、テストを行うタスクの追加、タスクテスト、タスク削除が一連の動作でできること、接続端末を連続してテストできること、結果はHTMLで、サマリー、結果、スクリーンショットの並びで表示されることなどが示されました。引き続き、Scirocco TMSのデモも行われました。こちらは、Ruby on Rails で実装されたテスト管理システムです。
まとめとして、導入効果に触れていました、手動テストでは設計2時間＋テスト実施10時間となるところを、Sciroccoは、テストコード4時間、実行は自動（ゼロ？）とのことでした。また、現在、対応していないテストは、複数アプリにまたがったテスト、Webアプリのテスト。今後は、複数端末並列実行に対応していくとのことです。
質疑応答で、会場からの、「 どうやって儲けているのか？」という質問には、社会貢献です（3/11の直後に決定）ということでした。
テスト実施だけでなく結果収集と管理まで行える点などで注目度の高いツールであり、今回の講演でその魅力の一端が示されました。
講演のスライドは以下にあります。
SQLiteのテストを行いやすくする方法
ussy00氏（日本Androidの会テスト部/株式会社ヌーラボ）による講演です。この講演からは、具体的なコードの話に入っていきます。
@ussy00氏
ussy00さんの不得意言語は、日本語だそうです。テスト部に入ったきっかけは、「 UI周りのテストは難しい、データベース周りのテストだけでもやってみよう」とのことでしたが、実際Androidでデータベース周りの開発を始めてみると、とにかくテストがしづらいという問題ありとのことでした。
具体的には、データベースが切り替えられない、テストデータの準備を自動化できない、などの課題にぶつかり、検討を進めていったそうです。一例として、データベースが切り替えられない点は、RenamingDelegatingContext で切り替えられるということで、コードの説明を交えて、どのように解決していったのか説明がありました。その過程で整備したSQLite Fixtureライブラリの使い方も交えての説明でした。
まとめとして、「 SQLite Fixtureを使うと、テストが楽にできる。ライブラリはGithubにあげたので使ってください。Excelに対応できるかたはforkしてください。」とのことでした。
開発テクニックの一端を披露され、短時間ながら参考になった講演でした。
講演のスライドは以下にあります。
仕様化テストおよびTDD解説と、ライブコーディング
このセッションでは、テスト部@mike_neck氏より、開発者向け単体テスト技法がライブコーディングを交えて紹介されました。まず、仕様化テストについて会場に聞いてみると、挙手した人は一人でした。
@mike_neck氏（日本Androidの会テスト部） 、帽子を被っているように見えますが、実はねこみみ！で登場
「仕様化テストとは、レガシーコード改善ガイドによれば、ソフトウェアの仕様を調べ、その結果に基づいて仕様を書くことである」「 そこで、実際にコードで解説、Assertを仕込み、実行してみると、どのような文字が返るのかを考え、テストケースに反映し、それで再度テスト、そこから仕様を確認していく」とのこと。
次は、TDDです、こちらも会場に尋ねると、知っている人が大半のようです。『 TDD: Test-Driven Development; by Example』（ ケント・ベックの本）では、TDDはプログラミングの不安を管理する方法である、と書かれているとのこと。また、TDDによって具体的に学習する、はっきりとコミュニケーションする、等々、一通りの解説がありました。
ここから、TDDの実演として、ボウリングの得点を算出するプログラム例のライブコーディングの始まりです。まず、簡単に分ける、1フレームに分ける、簡単なケースに分類する、というところから始まりました。
「これからずっと独り言でやります。解説しながら、テストコードを記述していきます。」と、ライブコーディングが続きます。プロジェクターの画面を注視しないとついていけない、ということで、みなさん注視されていました。
しかし、スペアとストライクのケースだけできたところで時間切れ、「 続きは、喫茶店でも何でも行きます。呼んでください。」とのことでした。
講演のスライド、およびライブコーディングのソースは以下にあります。
招待講演「テスト可能なUI設計パターン」とは
.NETの世界を中心に、フリーランスとして活躍されている、尾上 雅則（おのうえ まさのり）氏を招待講演の講師としてお迎えしました。スマートフォンなどに向いているとされ、「 UIの状態をテスト可能にする事」ができる設計パターンとして、 MVCパターンの派生である PM（Presentation Model）パターン、MVVM（Model View ViewModel）パターンについての講演がありました。
単なるMVC,MVVMパターンの紹介ではなく、Android開発にどういったメリットをもたらすのか、テストの価値という点から、MVCモデル全般を含め、その特徴についての講演でした。
「Androidアプリの基本はUI、しかしUIのテストでは、テスト結果の自動確認ができない。各種のツールを利用することは出来るが、最終的な見た目、操作性の確認には人手が必要。テストの価値向上、というアプローチで、より効率的にテストができる」
このように、テストの価値向上、という観点からスタートして、責務の分割および単一責任の原則の説明、タイトルにあるUI設計パターンのMVCモデルへと話が進みました。
責務の分割
「適切に責務を分割すると、コードが減り、品質・テストの質の向上がしやすい、単体テストレベルで確認できる状態に持ち込める」 「さらに、単一責任の原則が守られていることで、適切なテストケースが導きやすい。結合テストでも、単体テストが適切なら、修正の連鎖が減少、そもそもバグが少ない」 「適切な責務の分割がもたらすメリットは、当然テストの価値向上だけではない。変更に強く、コードの見通しが良く、再利用がしやすい」 単一責任の原則
「オブジェクト指向の設計原則を意識することが大切。では、責務分割の方法は？各種設計パターンという、先人たちのベストプラクティスがあります。その設計パターンのひとつとして、MVC（MVP)パターンがあります」 「MVCの派生パターンはいろいろあるが、目的は一貫してプレゼンテーションロジックと、ドメインロジックの分離です。」 「見た目と操作（プレゼンテーションロジック） 、解決したい問題領域そのもの（ドメインロジック）を分割します」
そして、「 MVCがもたらす価値は、ModelとControllerがIN/OUT、すなわちデータを与えて出力を得る方法に統一され（いつ起きるかわからないイベント待ち／出力が他の要因に影響される、ということがなくなり） 、自動テスト可能になるということです」「 Viewのほうも、ユーザのアクション、Controllerからのイベントの二通りのやりかたで自身の状態を変化させるもの、というとらえ方ができるようになります。自動テスト可能な範囲が増えています」ということで、テストを自動化するという観点で、MVCモデルの利点を解説されていました。
ひき続き、派生パターンをいくつか解説したあと、PMパターンの説明では、「 PMパターンでは、Viewは、Presentationモデルをレンダリングするだけの存在にしたものです。実装が大変そうですが、Android Bindingを利用できます。これはAndroid用データバインディング機構です」「 これにより、Viewから、Viewが保持している状態が分離され、さらに自動テスト可能な範囲が増えます。PMパターンは、WPF/Silverlight（Windows Phone 7も）ではMVVMパターンと呼ばれます」とのことで、MVVMパターンの意義の説明がありました。
UIパターンの嵌まりどころとして、Webから来た人が三層モデルと誤解する例、クライアントアプリをMVCのViewと認識してしまう例などを紹介して注意喚起もされていました。
そして、UIパターンとコミュニティと題して、パターン（ベストプラクティス）は成長するということ、そのためにコミュニティで共有すべき、フィードバックすべきということを述べられていました。
最後に自己紹介で「一貫して、.NET技術者、ということでこの場での自己紹介は最後にさせてもらいましたが、どうやらそんな必要は無かったようです」と話されていました。Android開発者の集まりなので、怖いので最後に自己紹介を持ってきましたということでしたが、全くの杞憂だったようです。
テスト／パターン／コミュニティとそれらの価値を結びつけて語る、非常に魅力的かつ有意義で、招待講演としてふさわしいものでした。
講演のスライドは以下にあります。
クロージング：これからのアンドロイドテストの話をしよう
クロージングは、日本Androidの会テスト部部長からです。
宮田 友美氏（日本Androidの会テスト部部長/株式会社オープンストリーム）@miyatay
「テスト部の紹介と、これからの活動の説明をします。肩の力を抜いて聞いてください」と、淡々と語りはじめました。テスト部の紹介から始まって、これからのAndroidテストについて（テスト部の取り組みの方向）として、次のように話をされました。
「テストのやり方をどうやって現実に当てはめていくのかについて考えたい。テストにかけられるリソースはアプリによって異なる。リソースをかけられない場合は完璧にテストすることはできない。アプリによってカスタマイズ可能な、テストのガイドラインがほしい」
「最近の流行は、特定の人にプライベートで公開、フィードバックをもらって進化する。つまり、使う側の期待する仕様が大事（作り手の期待する仕様でのテストだけではだめなのではないか、ということ） 。しかし、どういう場合にプライベートベータが有効なのか。そういったガイドラインを策定したい」
「そうはいっても、引き続きテストのやり方については注力します。テスト自動化については特に。いろいろなことに対応するには自動化が必須」とも付け加えられました。
これまでの熱気を鎮めるためか淡々と語られましたが、作る側の視点でのテストの方法だけで無く、「 使う側の期待」という忘れてはいけないことを強く認識させる講演でした。
最後に「テスト祭り、またやります。テスト部の定例会にもぜひ参加してください。」ということで、講演プログラムはすべて終了しました。
セッション終了後も盛況 ～ 懇親会＆LT
プログラム終了後、そのまま会場配置を変更し、懇親会に移行しました。懇親会ではLTも行われました。アプリ開発者のテストでの工夫と苦労の語りに注目！
これからのXMLの話をしよう：@mike_neck
XMLかきたくねー、ではどうする？
これからAndroid開発のテスト自動化の話をしよう：@sassy_watson
自動化は便利（当たり前） 、でも工数は？やり方わからない…ツールがあるさ！
Native Driver：@asukaze55
NativeDriver開発者の方の生語り！
Camera、OpenGLそしてSensor入りアプリのテスト：@jy3n
カメラ､センサのテスト難しい、自動テストの試み…ただいまスクリーンショット
（飛び入り）スレッドの話：Zouさん（ATND）
CoreDuoでは大変な不具合で苦労しました、Tegra2はデュアルコア…
山吹色の茸疾走におけるテストの実例：@nowsprinting
ロジックのテストだけを切り出してJUnit4で行なったアプリの実例
これからうちの子の話をしよう：@hassy
Androidとは全く関係がありません…
（クロージングセッションのパクリ（もとい、パロディ）＆プライベート丸出し？のため、資料の公開は絶対ないそうです）
