第2回 Androidテスト祭り に参加してきた #atecfes2

勉強会 Android Testing

前回第1回は申し込んでおきながら直前で参加出来ず…という何とも勿体ない事をしてしまった『Androidテスト祭り』。今回第2回はその辺り万全を期して参加してきました。

ちなみに前回(第1回)の各種エントリはこちら。

前回のおさらい


今回第2回の会場は東海大学 高輪キャンパス＠品川。最近出来た大会議室にて、400人を超える参加者を収容しての一大イベントとなりました。以下の写真は参加受付前の一幕。（※当日は写真撮影禁止でしたので、以降はNO写真なメモとなります）

開会挨拶

ATEC実行委員より開催の趣旨の説明とご挨拶をさせていただきます
  • テスト祭りについて
    • テストレベル（V字モデル）
    • 第1回：2011年夏
      • 主に下層のテストを範囲
      • 浴衣。
      • 設計工程の作り込みが重要
    • 第2回
      • セキュリティ
      • 受け入れテスト
      • CI、リモートテスト
      • フラグメント対策
      • 受け身ではなく、要件・仕様段階で品質を作りこむ
  • "祭り"をお楽しみ下さい！
  • 東海大：浜本先生より注意事項等。
    • 無線LAN：セキュリティが厳しくて使えません＞＜；
    • 10キャンパス。そろそろ8キャンパスに減るらしい･･･
    • 情報系を高輪に集約：産学連携の狙いもある。

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

品質保証と隣り合った分野であるAndroidのセキュリティの現状についてご講演頂きます

書籍、出ています。

Android Security　　安全なアプリケーションを作成するために

Android Security　　安全なアプリケーションを作成するために

講演内容については、予めスライドが公開されていたと言うこともあったので具体的なメモは割愛。最近の("やっちゃった")事例等も交え、非常に細かい点まで詳細に解説された素晴らしい資料だと思います。AndroidにはAndroidなりの流儀・お作法が必要とされる部分もあったりするので、上記のセキュリティ本等でその辺りを抑えておきたいところです。

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

  • ユーザサイド : 株式会社電通プラットフォームビジネス局開発部 様
  • ベンダサイド : 生路 茂太　松木 晋祐(Androidテスト部)
開発成果物の納品時に必要となる受入れテストの観点について、これまでのATECでの議論をふまえ、ユーザ側、ベンダ側に分かれて再構成を行います
  • 手作りというか、手探りのセッション？
  • テスト部として、受け入れガイドラインを研究。
  • いつも思う：ユーザーサイドの話が全く出てこない。
  • 今回かなり無理を言って、開発委託業務をされている方々を呼んでお話を伺ってみた。
  • 本日のお品書き
    • 動かない＋売れない＝儲からない！
    • 受け入れテストに求められている問題
  • 本日までのあらすじの紹介
    • ユーザ意見をガイドライン化すればいいんじゃないか？
    • リリース後のサポートをサービスガイドライン化すればいいんじゃないか？
  • 我々は何に困っているのか？
    • 作ったは良いが、動かない！売れない！儲からない！
    • 動かない！
      • 『差別化』という商売の原則と『標準化』という理想
    • 売れない！
    • 今、現場の『受け入れテスト』に求められている事とは、どこでも動く事、とたくさん売れる事。
    • この前提でどのようにガイドラインを導出するか。
  • Androidのプラットフォーム環境
    • Androidはプラットフォームの制約が緩い
    • システム開発における運用と同様に、環境追従対応は不可避。
    • 現実としてAndroid開発とは、プラットフォーム変化の追従対応運用（サポート）を伴う『サービス開発』ではないだろうか？
  • Android開発で考慮するサービス/サポート要素
    • 国や地域別の法律等を筆頭に、非常に多岐に渡る様々な要因が絡む。
  • Android受け入れテスト』に求められる事
  • Android SLAガイドラインの作り方
    • SLA（Serveice Level Agreement）
    • まずは、運用仕様の前提となる非機能要件部分を作成
      • 既存のベストプラクティスを集める
      • 既存のベストプラクティスとは？
  • 取り組みのまとめ
  • ユーザ企業様へ質問
    • 株式会社電通 プラットフォームビジネス局　開発部の方々にお越し頂き、色々質問を投げ掛けてみた。
  • 電通と言えば、何を思い浮かべますか？
    • 電通 採用
    • 広告代理店･･･だいたい正解です(笑)
  • 電通：基本的には『広告』の会社。
  • 基本的には人が資産
    • コンテンツをどうやって作るか
    • 飲み方の文化･･･如何にグラスを乾かすか、に力を入れているらしい
  • 実は、技術を重視する会社
  • Androidアプリ事例
    • ミテレ：ソーシャルの力を借りて、テレビを盛り上げるアプリを開発中。
    • Movile Clip：CMS
    • ※投資として作ってる、儲けるというフェーズでは今はない。


質疑応答タイム：

  • [質問1].android開発はどんなにｈ頑張っても『全ての/未来の機種差分』を防ぐことは出来ないんです。サポートサービスを込みにした運用込契約でビジネスする事は可能ですか？
    • 確かにandroidのOS・端末は劇的に増加。
      • 世界中のandroid端末を検索するアプリも登場
      • 課題：どうやって、どこでも動くアプリを作るか？
        • 現状は端末に依存しない技術で対応するしかない。
        • 技術こそ、開発パートナーに求める条件。
        • →運用SLAの普及には時間が必要。
    • 領域の近接化と技術の深化
      • データ領域、基幹システムの設計・DB構築
      • 分析・戦略領域、ビッグデータ処理、行動データ分析
      • コミュニケーション領域、マルチデバイス化、O2O施策
    • 課題：どうやって売れるアプリを作るか？
    • パートナーシップとビジネスモデル
ビジネスモデル 担保責任 パートナーシップ
ストックビジネス 納品物 作業者
フィービジネス 技術・知見 コンサルタント
レベニューシェア 成果 パートナー
  • [質問2].発注側のAndroidアプリ受け入れ現場には、そもそもどんな問題意識があるのでしょうか？受注側からすると、押し付k（ry
    • 電通：発注と受注両方やっている。
    • クライアント/広告代理店(電通はココ)/外部制作会社
    • 作業的にはデジタルぜんぶやってます。
    • デジタル以外でも色々やっています
    • iPhoneAndroid、どのようなイメージか調査してみた。
      • 機種やブランドにこだわる：iPhone
      • キャリアにこだわる：Android
      • アプリ系機能（音楽・動画・SNS）：iPhone
      • ウェブ閲覧や検索:Android
    • 検索するときに頭を悩ます事
      • やっぱiPhoneユーザって年齢問わずにアクティビティ高いよな〜
      • Androidシェア過半数だけど、デバイスごとに不具合起きてクライアントに説明しにくいなぁ･･･
      • クライアントはどっちも同じって思っちゃってるんだよなぁ･･･
  • WEBサイト制作に対して、スマホアプリだと…
    • やりたいことが曖昧？
    • 自主的に提案、自主的に開発
    • ※ビジネス的にはスマホアプリはこれからのマーケット。
    • Q：要件を固めるにはどうしている？
      • アイデアを説明して納得してもらう。
      • 夢物語を説明して気持ち良くなって貰って･･･
    • Q：企画書の打率、どれ位･･･？
      • Webサイト：企画を出しまくる。100個出していいのだけ採用
      • スマホ：こういうことを出来ます、で自主的に提案→採用される事が多いかも？割と打率良いかも。
        • あまり明確ではない？自主的に訴える事重要
        • 夢を訴えるの大事。
  • [質問3].これまで、受け入れ試験やその基となるRFP/機能/非機能要件の定義はどのようにされていたでしょうか？そもそも開発プロセス回ってますか？
    • マーケティングの言葉とエンジニアリングの言葉の翻訳が問題
      • やりたいイメージがあっても、エンジニアの方に伝わる言葉を知らず曖昧な表現が出来ず。
      • マーケティングの言葉とエンジニアの言葉が違う。
    • さらに、技術とクリエイティブの垣根がなくなっている
      • 広告コピーと印刷技術
    • クリエイティブなテクノロジー/テクノロジーでクリエイティブに。(→インタラクションデザイン)
    • 課題は、新しい領域のクリエーティブを表現する『言葉』が無いこと。
      • インタラクションのイメージ（暗黙知）・機能要件（顕在化）
      • 暗黙知としてのアプリの気持ち良さが、『わかってる』クリエーターにのみ仕事が集中。
    • 例えば、『テトリスが無い世界』でそれをどうやって説明する？
      • テトリスを面白くしている『要素』を記述する事で、表現可能にしていくことが出来れば・・。

非機能要求仕様定義ガイドライン(UVCプロジェクトII)

非機能要求仕様定義ガイドライン(UVCプロジェクトII)

(とある文言の文末)
...以降の議論からは割愛する。
-------
( Д) ﾟ ﾟ

『魅力性』については、語られる事無く来てしまっている。

    • 提案：『魅力性』を定義してみませんか？
      • 暗黙知と思われているものを顕在化して価値として難易度（価格）やクリエイティビティを証明できるようにする。
      • 男子ゆか体操の技名と難度
      • フランス：批評文化が熟成している。
      • クリエイティブの発展と制作価値の向上へ
        • 発注する側も、価値が顕在化して見えるので、その分の工数や価格に対して理解が増す可能性

CI導入ライブ-jenkins ci server

継続的インテグレーションを強力にサポートするjenkins-ciサーバーの導入、運用をライブで行います。Androidの開発で問題となるフラグメント化の対応策になりえるか！？
  • 自己紹介

Android Hacks ―プロが教えるテクニック & ツール

Android Hacks ―プロが教えるテクニック & ツール

    • 社会人4年目。
    • Jenkinsのコミッタ−です。
    • オーバートーン株式会社
  • CIのメリット
    • 開発中のバグが発見されやすくなる
    • テストを自動で行うので、開発者は全体のテスト実行に時間を費やされなくて済む
    • 問題があればすぐに発見されるので、開発者は安心してプログラミングを行える
  • JenkinsでAndroidアプリをCIするための3つのポイント
    • どうやってJenkinsにAndroid sdkを入れるのか
    • Antが無いプロジェクトはどう実行するのか
    • 複数デバイスが繋がっている場合にどうやって指定して実行するのか
  • 導入ライブ
    • ここからの内容は@itにもっと詳しく載っています
    • 動作環境はjenkins.android-tec.org/でアカウントを取ると、動作している環境の設定を参照したり変更できます。
    • サーバーはcloudcoreの開発者支援制度を利用しています。
  • Jenkinsのインストール
    • aptやyumで管理
    • コマンドのコピペでOK 
android update sdk -u
    • android emulator pluginチェックを入れ：ダウンロード実施。

  • ジョブの作成：フリースタイルビルド
    • ビルド環境の中に候補が出てくる。
    • show emulator windowのチェックは外しておこう。
  • ビルド・テストの自動化
    • ビルドだけの場合、ターゲットバージョンで指定したバージョンのAPIがインストールされてないとエラーになります
    • ビルドだけするときにもエミュレータを実行させておくと安心。
    • ついでだからモンキーだけでも走らせると良いでしょう。
    • Antが無いプロジェクトに次のようなコマンドで自動生成出来ます。
android update project
android update test-project
  • シェルの実行：
    • アンドロイド実行パスを設定
  • 複数OSのバージョンでのビルド・テストの自動化
    • マルチ構成プロジェクトを使います。
    • ユーザ定義を利用することで変数を置き換えます。
    • アカウントの申請をすることで、マルチ構成プロジェクトを見る事が出来る。
    • マトリックスの設定
      • ユーザ定義で変数『OS』を追加、バージョン値を設定
      • 組み合わせフィルターを用いる

Lightning Talks

Androidテスト部に所属するエンジニアが、ナレッジの共有を目的とした業界最先端のAndroid開発テスト手法の紹介を行います
  • ドラ娘 : 鈴木 香澄(ACCESS)
「Androidアプリリリース作業の効率化（2）」
  • 自己紹介
    • NTTソフトウェア株式会社の人
    • コンテストなども多数参加
  • プライベートなアプリ開発は平日夜中と休日
  • Androidアプリリリースに伴う作業
    • ビルド、テスト、デバッグの繰り返し
    • 面倒、しかも楽しくない･･･orz
    • なるべく楽にして、新機能追加に時間を！
    • 前回はビルドを効率化！
    • ※いきなり全フェーズの効率化は無理。
  • 今回は『テスト』を効率化する際の前提となる考え方を紹介。
  • 何を目的として、効率化したいのか？→目的によって、最適解は異なる。
    • 対応したいAndroidのバージョンは？
    • アプリのバージョンアップ頻度は？
    • アプリの画面数／試験項目数は？
    • アプリの複雑度？UIとUI以外の規模は？
  • テスト効率化を実現するツール
    • 多数あるが、どんな時にどれを使う？
      • Junit：主にビジネスロジックの試験に、はじめのいっぽ
      • Robotium：UI系の試験に
      • Roboletric：エミュレータなくてもOK。JavaVM上でのテスト
      • MonkeyRunner：UI操作の自動化
      • Scirocco：robotiumの拡張版
  • 自分のアプリの場合、アプリをどう絞って、どのツールを使う？
  • そもそもVerUPする？
  • テスト自動化可能？
  • 試験工数大・多端末対応？
  • 第1段階
  • 第2段階
    • その他不便な箇所への対応
「Hello,CI. Jenkins met gerrit.」/テスト部 gerrit導入 進捗報告
  • 自己紹介
    • 趣味：アンドロイド開発
      • 開発の仕組み：みんなが楽になる仕組み
    • 言語：python等
  • Agenda
    • 1.jenkins/gerritとは？
    • 2.jenkins/gerrit連携の進捗状況
  • 組み合わせると何が嬉しいのか？
    • テスター／レビューアが一人増えます。
  • 1.jenkins/gerritとは？
    • プラグインで拡張
      • gerrit hudson trigger!
      • gerrit:
        • Google謹製のレビュー管理システム
        • 大規模プロジェクト向けgitレポジトリ管理機能
        • 独特のレビューシステム
        • 便利なクライアント Egit（Eclipseが標準サポート）
    • で、何が嬉しいの？
      • CIの三大要素が満たせます。
      • コミット忘れやデグレに気付きやすい。
      • ビルドマシンへのリソースの集中
    • レビュー結果
    • 管理者にも嬉しい
      • かんたんインストールで試用もらくらく
      • 大規模の管理スキームにも対応
  • 2.jenkins/gerrit連携の進捗状況
    • 進捗状況
    • 今後のTODO
    • 資料・マニュアル整備
    • 環境構築



本来であればこの後もう1セッション＋閉会挨拶〜懇親会という流れだったのですが、別の勉強会イベントへのハシゴ参戦の為、途中退出。

『今回は上層』という事で、テストテストした感じの内容？では無かった部分もありましたが、よりお客様・ユーザ層から観た視点での意見やコメントも多数聞くことが出来、多いに勉強になったイベントだったのではないでしょうか。第1回の内容も併せて復習し、Androidテストに関して理解を深めて行きたいところですね。

その他関連：