モバイル時代に求められるソフトウェアテストの形とは─「第2回 Androidテスト祭り」レポート

GW初日の4/28、東海大学高輪キャンパスにおいて、第2回Androidテスト祭りが開催されました。

昨年夏に行われた第1回は、開発者の方々を中心に Androidアプリ開発におけるテストを考える場でしたが、今回は、アプリを利用あるいは企画・発注する方々にも視野を広げてテストを考える場として開催されました。

ソフトウェアの開発において、好むと好まざるとに関わらずテストは重要な位置を占めています。殊にAndroidアプリ開発では、デバイスとしての特性以外にも、端末フラグメンテーションの問題や、利用者の幅の広がりにともなうセキュリティの問題などが顕在化し、従来のテストだけでは品質をカバーできないという懸念が拡大しています。

「使うだけ」の人としての一般ユーザの幅の広がりとともに、アプリ開発においても、ソフトウェア技術者以外の人、たとえばアプリを企画する人々やクリエイターの方々も巻き込んで、テストを考えていかなくてはならない状況になってきているのではないでしょうか。そこで企画されたのが、第2回Androidテスト祭りです。

さて、当日の様子ですが、開催場所の東海大学高輪キャンパスに入ると、受付担当の大正浪漫華組（Androidテスト部）が出迎えてくれました。受付後、約500名収容の講堂に進むと、Androidのテストを軸に、アプリ開発を考えるための密度の濃い半日のスタートです。

テーマは【上層テスト】

もちろん今回のテーマは、受付の風景でご覧いただいた「大正ロマン」ではありません、あしからず。

V字モデルでの【上層テスト⁠】⁠、つまり受け入れテストやシステムテストをテーマとしたのは、開発者だけでなくユーザ、アプリを企画する側（発注者⁠）⁠、テストに関わるサービスを提供する側など、アプリ開発の関係者の立場、考え方をテストを軸にコラボレーションし、よりよいアプリ開発・提供に役立てようということです。

そのため、次の観点でセッションを準備しました。

リリース後のセキュリティ問題からさかのぼって品質、そしてテストを考える。
アプリを企画するが、開発は委託する立場つまりアプリ開発の「発注者」の視点で、開発したアプリをどのように受け入れているのか、すなわち受け入れテスト、およびその基準を考える。
Androidアプリ開発における、大きな課題であるフラグメンテーションに対応する方策を考える。
テスト作業を効率良くするためのツール利用を推進する。

特に、端末フラグメンテーション問題に対応するサービスとして、リモートテストサービスが立ち上がろうとしています（端末を貸すだけでなく、自動テスト環境をサポートする⁠）⁠。こういったサービスの可能性として、多数の機種およびバージョンのテストを、自前の設備としてすべて準備することなく、必要な時に必要な分だけテストを行う環境が短時間で準備できることにより、機能テストは深く、幅広い機種やバージョンについてはより広くテストができるようになる、という利点があります。

テスト祭りでは、リモートテストサービス提供者の方々に、現状および今後の戦略を語っていただくだけでなく、三社横並びで比較されることを恐れず、会場からの質問に真っ向から答えていただきました。リモートテストサービスの有用性がかなり理解されたこと思います。

そして、通常のソフトウェア開発で行われる、継続的インテグレーションのAndroidでの実践事例の紹介、さらにそれらを前進させるための議論がテスト部部員より講演およびデモという形で実施されました。

各講演は以下のプログラムに従い行われました。

13:00	開会挨拶
13:10	招待公演「Androidのセキュリティと品質保証の問題について」
14:10	ユーザとベンダで生討論！みんなでつくる「受入れテストガイドライン」
15:30	CI導入ライブ-jenkins ci server
16:50	Lightning Talks Androidの会テスト部「Androidアプリリリース作業の効率化」「⁠Hello,CI. Jenkins met gerrit.」/テスト部 gerrit導入進捗報告
17:00	三大リモートテストサービス東海の大決闘！
18:05	閉会挨拶
18:45	懇親会

各講演プログラム別の注目ポイントをこれからご紹介します。

開会挨拶

開催挨拶として、長谷川孝二氏（Androidテスト部）から今回の「テスト祭り」の⁠”楽しみ方⁠”の紹介がありました。

「去年の第1回では、V字モデルの下層、単体テストなどが中心のセッションで構成されていました。今回は、セキュリティや受け入れテスト、CI、リモートテストなど、Android開発上の課題を中心に、受け身ではなく要件定義および設計段階といった、前工程から品質の作り込むためのヒントが得られるセッションを準備しました。」（⁠長谷川氏）

なお、今回のテスト祭りは、参加申し込みが400名を超える規模になり、大人数でも収容できる会場を、東海大学のご厚意により提供していただくことができました。

また東海大学の濱本先生より、東海大学の最新の情報関連の設備の紹介がありました。こういった会合で時間のある場合は、キャンパス内のツアーも実施しているとのことです。

今回の開催にあたり、東海大学メディア学科の皆様にご協力いただきました。開催場所が大学と言うこともあり、ハードルが高く思われている⁠”テスト⁠”について、学生の皆さんにも参加しやすい環境だったのではないかと思います。

招待公演「Androidのセキュリティと品質保証の問題について」

タオソフトウェア株式会社代表取締役谷口岳氏の講演です。

Androidのセキュリティと品質保証の問題は、ただテストをしてつぶせば良いものではありません。Androidにおけるセキュリティの仕組みを理解した上で、設計／開発段階から取り組む必要があります。谷口氏から「今回、セキュリティとテストをどうつなげていくのか、を考えていくと、最近は落ちるアプリはなくなってきた、そろそろセキュリティを考えていかないといけない。セキュリティの仕組みを知らないと、設計に盛り込めないという状況がある。」ということで、その取り組みを事例を交えて解説して頂きました。

Androidのセキュリティというと範囲が広いですが、今回は開発者に必要な知識に絞り、また、「⁠何を守るのかが、ぶれると無駄足になる。」「⁠ソフトウェアでどれくらい守るのか、コストとの兼ね合い。テストでもバグがないことは、小さなプログラムについてしか言えない、セキュリティに関しても同じで、確実に安全とはなかなか言えない。」など、取り組むべきガイドライン的なところについても話をしていただきました。

具体的に守るべきこととして、つぎのようなことがあります。

アプリケーション内の著作物データ
アプリケーションの不正利用（ライセンス違反）を防ぐ
アプリケーション機能の使用
使用者の個人情報

こういった観点で、実際にセキュリティ上の問題点を取り上げて、アプリを設計したりテストをするために役立てるための対策を、実際に起きたセキュリティ事故の例をまじえて解説していただきました。たとえば、パーミッションの組み合わせに注意する、インテントの使い方など、Androidならではの考慮点がいくつもあることがわかりました。

自分で書いたコードだけではなく、アプリ作成時に注意しなくてはならない関連事項を解説するなど、具体的な講演でした。

ユーザとベンダで生討論！みんなでつくる「受入れテストガイドライン」

ユーザサイド代表は、株式会社電通プラットフォーム・ビジネス局開発部より、廣田周作氏、上原拓真氏、千代（ちしろ）裕介氏、株式会社電通イーマーケティングワンより徳田哲司氏の4名、ベンダサイド代表はAndroidの会テスト部から、生路茂太氏、松木晋祐氏の2名が登壇しました。

まず、生路氏より、講演趣旨の説明がありました。

「テスト部として、受け入れテストのガイドラインの模索を一年近く続けてきた。しかし、ユーザサイドで行われる受入れテストの検討をしているのにユーザサイドとの対話ができていなかった。そこで、電通で、開発の発注業務に携わる部署の方を4人お招きし、アプリの受け入れの状況を再現しながら、検討してみたいという趣旨のセッションです。」

セッションは、開発者（ベンダサイド⁠）⁠、発注者（ユーザサイド）でバックグラウンドが共有されていないため、まず、それぞれの取り組みを紹介するところから始まりました。

生路氏より、テスト部での取り組みとして、「⁠Android開発で困っていることは、ずばり、儲からない、ではないでしょうか。動かない（機種依存）＋売れない（市場ニーズ）＝儲からない、ということが問題で、受け入れテストのガイドラインを導出・適用すれば、動かない、売れないアプリをリリースしてしまう可能性を減らせるのではないか、ということで受け入れテストガイドラインの作成を模索してきた。」という説明がありました。

そして、Androidアプリはリリース後も継続的に瑕疵対応やユーザのフィードバックを受け入れて改良することから、サービス提供の側面が強いと考え、受け入れテストのガイドラインとして、Android SLAガイドライン作成に取り組んでいる、しかし、受け入れテストに関するテスト部の議論などでも、ユーザサイドの意見が出てこないことが今回のセッションを企画するきっかけになったとのことです。

ここで、電通側の千代氏にバトンタッチ、ユーザサイドである電通の仕事やIT関連への取り組みの紹介がありました。電通の仕事としては、メディア系（TV等⁠）⁠、コンテンツ系の流れがあるが、企業としては「人の心を動かす仕事」をおこなっているとのことです。しかし、実は、電通は技術を重視し、Androidアプリもリリースしている、たとえばソーシャルの力を借りてテレビを盛り上げるアプリとしてTune in, Mobile Clipなどがあるとのことです。

セッションはこのあと、ベンダサイドからユーザサイドへ3つの質問を投げかける形で進みました。

［質問1］Android はすべての機種、未来の機種への対応はできない、サポート範囲を考慮したビジネスをしませんか（つまり、どうやって動くアプリをつくるのか⁠）⁠。
［質問2］発注側のAndroidアプリ受け入れ現場はどのような問題意識を持っていますか？
［質問3］これまで受け入れ試験や、その元になるRFP/機能・非機能要件はどのように定義されていたのでしょうか？そもそも開発プロセスとして回っていますか？

［質問1］Android はすべての機種、未来の機種への対応はできない、サポート範囲を考慮したビジネスをしませんか。

つまり、Andoroid開発でフラグメンテーションは防げない、サポートサービスをもとに運用契約でビジネスをすることは可能か？という質問です。

電通イーマーケティングワン徳田氏から回答がありました。

「AndroidのOS、端末数は劇的に増加している。その中で、どうやって動くアプリを作るのかというと、現状では端末に依存しない技術で対応するしかない、たとえば、HTML＋CSSのようなワンソース、マルチデバイス。技術こそ開発パートナーに求める条件であり、そういった技術をどう適用していくのか、が問題になる。SLAの普及には時間が必要と考えている。」

「また、ユーザビリティからのアプローチ（HCD＝human-centered design）がある。この考え方は、アプリ(ソフトウェア）に限定されるものではないが、人間に近いことなので定量化しにくい。結果として発注が曖昧になる。そういったことにはアジャイルUXを活用してうまく、お互いの専門性を重視しながら関係者間のパートナーシップを作っていければよいと考える。」

この後、松木氏から、アジャイルUXでは特に、お客様と開発者が一緒になって動いていくことが重要で、発注側からこういう言葉が出てくるのすごいこと、というコメントがありました。

［質問2］発注側のAndroidアプリ受け入れ現場はどのような問題意識を持っていますか？

電通研究員の上原氏からの回答です。

「広告代理店（電通）は、一般企業と開発パートナーの間に立つため、発注側と受託側の両方の顔をもつ。スマホだけでなく、スマートテレビなども含めデジタルデバイス全般をやっているので、いろいろなソフトウェアを制作しているが、制作ワークフローは同様。Webサイトであれば要件を固めるのは容易。」

「IEおよびsafariに対応とか、予算の見積もり、サイジングなどを含めればよい。（⁠成熟してきているせいもあるが）やりたいことがなにか、どのように制作すればよいのかクライアントとの合意もとれる。」

「しかし、スマートフォンではこのようには行かず、一般企業の人はどうしたらよいかわからないため、電通からできることを提案してマーケットを広げるフェーズになってる。電通としてマーケットを作っていかなければいけないという状況にある。」つまり、アプリの要件はあいまいなままとのことでした。

さらに質問で、「⁠スマホアプリの要件があいまいということだが、実際にはどうやってかためているのか？」に対しては、「⁠アイデアを説明する。まずは夢をお客様と共有することが最も重要で、細かい作りは何とかする。テレビとアプリをつなげてこんな世界ができます、とか。現実として、最上流のフェーズからSLAを定義したりするのは難しい。」とのこと。

要件定義をこちらから持って行った場合、さらに、クライアントがどれくらい採用してくれるのか？という点については、「⁠Webサイトだと企画を出しまくるが、スマホアプリだと、できることを提案していくので、結構話がはやい。きちんとできることを持って行けば、打率は高い。これまでの企画では、クライアントに提案をだしまくって、“⁠いいもの⁠”だけが採用されているが、スマホはできることを提案すると、『⁠そういうことできるんだ』となり話が早い。クライアントも何をするべきかというセオリーが明確でない、どんどん自主的に話す。」とのことでした。

ベンダサイドから「開発者は機能を訴えるが、そうではなく、マーケッター側は夢を訴えることが大事」と、コメントがあり、意識の差をまた一つ理解することができたと感じました。

［質問3］これまで受け入れ試験や、その元になるRFP/機能・脾機能要件はどのように定義されていたのでしょうか？そもそも開発プロセスとして回っていますか？

電通コミュニケーションプランナー廣田氏からの回答がありました。

「ツイッターでの質問に、『⁠どう要件定義している？』『⁠テストや技術の話が出てこないが？』ということが流れている、しかし、私たちは、そういう話ができない、それが問題かも知れない。」

「我々は技術者ではなくマーケッター。マーケッターがアプリを作る（企画する）状況になっている。そもそも文系的な発想なので、言葉が違う。技術者に伝わらない。外国に行ってなにか買うときにうまく伝わらないようなもの。」と、違いの認識から回答が始まりました。

「最近、クリエイティブとテクノロジーの境がなくなってきている。これまでは、広告コピーと印刷技術のように、それぞれ分業が成立していた。ところが、アプリになって、クリエイティブなテクノロジー、テクノロジーでクリエイティブであることが要求されるようになり、マーケッターはテクノロジーの言葉で語らなくてはならなくなっている。ここ1、2年、そのためにお互いコミュニケーションがとれない。新しい領域を表現する言葉がないのが大きな課題と考えている。」

そして、売れるアプリは、非言語的なところに宿るという話が続きました。

「機能要件は一生懸命勉強すれば、言語化できる、一方、インタラクションのイメージは、言葉にできない。『⁠シズル感が～』とか、『⁠ふわっとこういう』など。しかしアプリ成功の決め手はそこある。センスのあるテクニカルディレクターの方に仕事が集中するのは、その辺がわかるから。」

「⁠“⁠アプリを使ったときの気持ちの良さ⁠”が『わかっている』クリエイターにのみ仕事が集中する。技術的にも信頼でき、クライアントの言葉もわかる人には話しやすい。だからスタークリエイターとして仕事を大きくしている。たとえば、テトリスがない世界を想像してほしい。それを棒やブロックが落ちてきて……と説明すると、たぶんおもしろくなくなる。おもしろい要素を説明し、伝えることができればよい。」

「要件・非機能要件の指標（JISX129/ISO, JUAS『非機能要求仕様定義ガイドライン⁠』⁠）でも、『⁠魅力性』は以降の議論に譲るというように記述できないものとしてあきらめられている。」

最後に、「⁠そこで、魅力性を定義してみませんか？という提案をしてみたい。たとえば、芸術の計量は難しいが、何らかのテクニックに名称と難易度をつける。体操の技に名前と難易度を定義して採点していることにならう、というようなことができるのではないか。」「⁠そして、カンヌ広告賞のような、賞をアプリに与える。動き、こういうインタラクションに難易度(価格）のようなポジティブな評価をし、このアプリはここがすぐれている、とやっていく。」と、魅力性をテスト・評価する仕組みができないか、という問題提起で締めくくりとなりました。

一般の開発者ではない、ユーザやクリエイターサイドの方々との討論により、機能テストはもとより、要件／非機能要件に関するテストをも超えて、「⁠魅力性」に関わるテストを関係者を巻き込んで考えていかなけれならないのではないか、という課題が見えてきた貴重なセッションとなりました。

CIサーバ導入ライブ

末広尚義氏（twitter：@bols_blue）による講演。

ソフトウェア開発において、品質リスクを減らす方策のひとつである継続的インテグレーション。Androidアプリ開発においても、それは可能であることを証明するセッションです。CIサーバJenkinsでのAndroidアプリの自動ビルドおよびテストの事例を、テスト部員よりデモを中心に紹介するという講演です。

JenkinsでAndroidのテストをすることのメリットや具体的設定方法、注意点などを、実際に操作を行いながら解説がされました。まさにライブです。Android開発における自動化テストの具体的ノウハウが公開された、興味深いセッションでした。開発者の方には、ぜひ公開資料をもとに試していただきたい内容です（資料は本記事末のURLより参照できます⁠）⁠。

Lightning Talks

Android のテストを、より効率よく行いたいと思いませんか？ツールを利用した効率化の試みをテスト部員より紹介するLightning Talksは、ドラ娘、鈴木香澄さん（ACCESS/大正浪漫華組）に講演を仕切っていただきました。

テスト自動化について

神原健一氏（Twitter：@korodroid）によるLT。

テストを効率化するためにはいろいろなポイントがあるが、目的によって最適解は異なる。バージョンアップを繰り返すのか、多くの端末に対応するのか、などの状況により、テストツールの適用範囲を変えるという事例を、実際に開発したアプリを例に紹介していただきました。

「テストを効率化するツールは多数あるが、どんなときにどれを使うのか、わからないのが現状問題だと考えている。特徴を抑えることも重要。」「⁠テストを自動化する対象を絞り込む基準は、今後バージョンアップをする予定のもの、多くのバージョンに対応するもの、テストの自動化ができるもの（自動化できないものを外す⁠）⁠、試験工数が大きいもの。」「⁠ビジネスロジックはJUnit, 画面は、Robotium＋Sciroccoを適用して行きたいと考えている。」

「Hello,CI. Jenkins met gerrit.」/テスト部gerrit導入進捗報告

Kazushige TAKEUCHI氏（@myb1126）のLTです。

みんなで楽をして開発しましょうということで、CIサーバでテストを自動化するとともにgerritを利用してレビューを効率化する事例の紹介です。

「JenkinsとGerritを組み合わせて利用すると何が良いかというと、テスターとレビューアが一人増える点。CIは毎日ビルドを成功させることでよい結果を得る。XPの手法で、最新のソースからコマンド一発でビルド、テストの自動化、コマンド一発でテストできる。それに対して、Gerritは、独特のレビューシステムを備える。たとえばレビュー管理で“⁠いいね⁠”をつけられる。」

「結局なにがうれしいのかというと、CIの三大要素を満たしつつ、コミット忘れ、デグレードに気づきやすい、ビルドマシンへのリソース集中などが挙げられる。また、管理者にもうれしいのは、大規模の管理スキームにも対応している点。」と締めくくられました。

Lightning Talks では開発・テストに役立つ事例の紹介がありました、実際に活用していただきたいと思います（資料は記事末のURLより参照できます⁠）⁠。

三大リモートテストサービス東海の大決闘

講演者:（講演順）

金原正明氏（株式会社NTTドコモスマートコミュニケーションサービス部コンテンツ推進室コンテンツ支援担当）提供サービス名：リモートテストサービス
立花優人氏（株式会社ソニックスファウンダー/スマートデバイスソリューション事業部アーキテクト）提供サービス名：Scirocco Cloud
久納孝治氏（株式会社カトマック代表取締役）提供サービス名：リモート・スマホ・レンタル

司会進行：

東大輔氏（Androidテスト部）

テスト祭りのクライマックスは、Android端末のリモートテストサービスを提供する立場の方々のセッション＋会場からの質問に各社がまとめて答えるという、夢の対決です。フラグメンテーション問題の解決策となり得るのでしょうか？

各講演者とも持ち時間10分という短い時間で、それぞれのサービスの魅力や特徴を語っていただいた後、会場からの質疑応答となりました。

各社でサービス提供範囲に差がありますが、基本的にWebブラウザによる容易なアクセス（カトマックではネイティブアプリケーション⁠）⁠、実機を持っていなくてもいくつものOSバージョンに対応(端末は提供)、UIテストが中心、テストを効率化する各種ツールの提供などで共通点があります。リモートテストなので、センサー（端末を動かす）関連やカメラ関連のテストは得意ではないとのこと。

NTTドコモ金原氏

Android端末の種類の増加、OSの種類の対応状況の説明がまずありました。これは要するに、端末の種類、OSバージョンの種類もどんどん増えて、テストが大変ということです。

NTTドコモで提供するリモートテストは、ブラウザ上のFlashクライアントを操作することでネットワーク越しにADBコマンドを送り、画面液晶をカメラで撮影した映像をクライアントに表示する方式となっているとのこと。利用要件は、Flashの入ったブラウザおよび1.5Mの回線があればOKとのことです。操作方法のデモをしつつ解説されました。

サービスの特徴などは、次の通りです。

アプリのインストールに関しては、ローカルからも可能になっている
テストの様子が共有できるので、開発を依頼したクライアントの方に見せることも可能
標準のadbではテキスト送信に制限があるが、専用のIMEを提供することで日本語も問題なく送信可能
端末は、サーバ内で固定されているので、物理的に端末をふるなどすることは難しい
画面キャプチャなどのエビデンス取得もOK（動画とは別に静止画も撮影可能）
3G回線、ネット、Docomoのブラウザ、ポータルサイトのテストもOK

ソニックス立花氏

ソニックスではAndroidアプリケーションの開発のほかに、開発効率をあげるためツールやミドルウェアの開発を行っています。自動テストツールSciroccoをその一環として開発、オープンソースとして公開しました。さらに、今回紹介するScirocco Clouldは、リモートテストのプラットフォームを提供するサービスとして開始したとのことです。

特徴としては、自動テスト環境の提供がベースとなっていて、サポートライブラリは、NaviveDirver, Android Driver, monkeyrunnerで、テストコードの作成・実行、テスト報告書自動作成ができることです。

カトマック久納氏

ご自身の経験を生かし、4月に会社を立ち上げてサービスを提供しているとのことです。ネイティブアプリケーションで接続して端末の操作ができ、画像の転送も高速といった、サービス提供開始までのリードタイムも含めて全体的にスピード感が特徴といえます。

そのほかに、以下のような特徴が挙げられました。

端末情報を細かく提供している、一覧から選ぶことができる
ADT、DDMS、adbシェルで接続して状態を調べることができる、リモートでバッグもサポート
データは完全消去する、レンタル後、ファクトリーリセットをする
ローカル側のクリップボードと連携できる。テストレポートにも活用可能

各社の特徴をまとめると、このような感じなります。

ドコモ: （現状は自社のみ）多くの実機とOSバージョンの利用可能、3G回線も含めてテスト可、リモート共有も可能
ソニックス: 各種テスト自動実行ツールが使えるサービス
カトマック: 使いたいときに素早くテスト環境を提供し、画面更新も速い、終わったらきれいにする

各講演の後、3名そろって登壇していただき、30分間会場からの質問に答えるコーナーで、いよいよ大決戦です。

会場からの質問と回答は以下の通りです。

他社の講演を聞いて、自社サービスとの差異は何だったでしょうか？

D（Docomo⁠）⁠：他のキャリアの端末を提供しにくい。開発環境との親和性はあまりない、しかし、開発現場同士や発注者との場所が分かれているときに活用するために使ってほしい。
S（ソニックス⁠）⁠：3G環境でのテストができない、Eclipseとの親和性を高めないといけない。
K（カトマック⁠）⁠：自動テストツールの支援が弱い。

カメラ撮影をリモートでできるようになるか？

D：今も可能だが、サーバラック固定なので殺風景なものが写る。
S：対応はしたい。
K：現状は真っ暗。ディスプレイを準備しそれを撮影させる、カメラAPIへ画像を送り込むなど考えている。

どのようなセキュリティを考えているか？

D：利用権取得のシステムが前段階にあり、そこで排他制御。利用後は、いくつかの方法でデータを消す。どうしても消せないものがでたら、中の人ががんばる。
S：フィルタリングをかけてログを出す、消す方は独自対応。
K：基本的な仕組みとしてファクトリーリセットを行う。

OSのマイナーバージョンに対応するか？

D：メジャーは対応し提供、マイナーも準備（キャリアの強みで自社端末ならどうにか集められる⁠）⁠。
S：最新が基本で、マイナーはニーズ次第。
K：一番使われているバージョンに合わせる。

サーバと連携したテストに問題はないか？

D：制限なし。ただし、外部とのやり取りは自己責任で。
S：同様、制約に関してはフィードバックをもらえれば検討。
K：同様だが、SIMなしでの提供。SIMありだと、迅速なサービス開始が難しので。

申し込みが多数あるときなど、スケールアップが可能か？

D：端末をセットするサーバラックの制約があるので、緊急には増やせないが、できるだけ潤沢に提供していく。
S：利用時間を制限するなどして、調整する。
K：相談いただければ、サーバ増設などを検討する。

エンドユーザ視点から、利用可能時期と費用についてどれくらいか？

D：現在はdmenuに掲載されているコンテンツプロバイダ向けにのみクローズドで提供、オープン時期調整中。価格は戦略的・弾力的に用意します。
S：3月に正式提供、料金プランは3つ（ひと月あたり⁠）⁠。
K：ホームページにアクセスしていただければ使える。料金は30分ワンコイン。

実際の使い勝手が気になるが、お試しや無料プランに相当するものはあるか？

D：予約時に環境チェックなどは行える。現状のクローズドは無料提供。
S：あり（講演時説明）
K：現状、試用の仕組みはないが今後検討する。※ポイントチャージの仕組みを提供（会場参加者限定）

各社それぞれの特徴があり、単純に選ぶというよりは、使い分けも必要ということになりそうです。

大決戦の勝敗は見えませんでしたが、リモートテストサービスの可能性ははっきり見えたことと思います。

閉会挨拶～モバイルでのテストの課題

第2回テスト祭りのまとめは、テスト部副部長の松木氏から、モバイルでのテストの課題についてのお話です。

「⁠（⁠『⁠Joel on software』エッセイによれば）ソフトウェアを生業とする人々には5つの世界があり、これらにそれぞれコンテキストが存在する。それぞれコンテキストがことなり、異なる人々の間では、まったく話がかみ合わない。ソフトウェアテストでもそれは顕著。」

「テストに絞ってAndoroid開発のコンテキストに合わせるだけでも、本日のような成果が得られることがわかり、感動した。そして、ここに新しいコンテキスト「モバイル」が生まれていると思う。エンジニアの人たちは気づいていないかも知れないが、今の小学生などは、コンピューティングにPCがいらない世界に育っている。」

ここで挙げた“⁠モバイル⁠”というコンテキストの特徴として、

上位イベント割り込み
バッテリー駆動
ローコネクション
ユーザビリティ
プライバシー
物理センサー

などがあるそうです。こういった部分のテスト技術が必要とされます。

モバイルの業界の動きは、キャリアの垂直統合からオープンイノベーション（世の中にある技術を組み合わせる）になって来ています。この変化により、置き去りにされたのは「わからなさ⁠」⁠。

たとえば、一般的にはフィーチャーフォンからスマートフォンへの乗り換えで、年配の方が付いてこれないような分からなさがありますが、開発者自身も置き去りにされています。これまでは、部品ひとつひとつをすべて把握していましたが、今は調達した部品をわからないままに使っています。そこで、ソフトウェアテストが重要になると考えられます。

これらを承け、テスト祭りでは、1回目は下層（開発者向け⁠）⁠、2回目は上層（開発者以外も）を実施しましたが、3回目も考えていきたい、と話を結びました。

以上で、テスト祭りのセッションはすべて終了しました。

熱気はまだまた続く「突撃インタビュー＠懇親会」

講演終了後は東海大学高輪キャンパス内の食堂に会場を移し、懇親会が開催されました。会場は隣の建物でしたので、本会の熱気はそのままリラックスした雰囲気でのスタートです。

もちろん、おつかれさまということでただ親睦を深めていただく、という単なる飲み会は「テスト祭り」ではありません。懇親会というリラックスした場で本音を語っていただく突撃インタビューが実施されたのであります。突撃インタビュアーは大正浪漫花組、鈴木さん（ライトニングトークスではドラ娘を努めていただきました⁠）⁠。

講演者の方が語り尽くせなかったことや本音の一部、本会で語る機会がなかったテストやAndroidの有識者の方のご意見、スタッフの苦労話などが次々とインタビューされました。突撃インタビュアーの活躍により得られた成果は会場限定となりますので、ご紹介することはできませんが、名刺交換のみより多くの成果を参加された皆様が得られたことと思います。