読者です 読者をやめる 読者になる 読者になる

やらなイカ?

たぶん、iOS/Androidアプリの開発・テスト関係。

#tryswiftconf 3日目のテスト系セッションまとめ

3/3〜5の3日間、サイバーエージェントさんのセミナールームで開催されたtry! Swift、その3日目に行ってきました。 海外からも100人を超える方々が参加され、とても活気のあるカンファレンスでした。

Swift言語にフォーカスした本カンファレンスですが、3日目は開発者テストに関するセッションが2つありました。圧倒的にスイフト力が足りない私なので、これらのセッションについてだけ書きます。

Swiftにおける実践的なモック化について

Veronicaさんのセッション。Objective-C動的言語なので、テストコードでモック(を含む、テストダブル)を使ってプロダクトコードやフレームワークの挙動をランタイムに置き換えることができていました。またそれを容易に実現するためのOCMockというライブラリもありました。

しかしSwiftではこれができないため(反面、安全と言えます)、どうモックを使っていくべきか?というセッションです。

そもそも、モックを使う理由

続いて、DI(Dependency Injection: 依存性の注入)を使う理由

  • カスタマイズ(置き換え)が容易にできる
  • オーナーシップが明確になる
  • テスタビリティ(試験性、テスト容易性)を上げる

テストダブルの代表的なもの

  • スタブ(メソッドの戻り値を置き換える)
  • モック(メソッドの呼び出し、引数を検証する)
  • パーシャル・モック(特定のメソッドだけ置き換え。これは『xUnit Test Patterns』の定義・分類ではなく、恐らくOCMock独自の言葉)

パーシャル・モックのアンチパターン

  • setUp()でモックを定義するのが大変になる
  • What's real? What's fake?

モックを自分で作る場合、本物のサブクラスを作るのでなく、そもそも必要なものをProtocolとして定義しておく。Javaでも原則Interfaceを書くという宗派がありましたが、それ*1

「ロールをモックせよ」の話。むやみにモック化しない。壊れやすいテストになる。

Swiftで将来的に使えるようになりそうな?モックフレームワークの紹介(リンクはぐぐったもの)

GitHub - rheinfabrik/Dobby: Swift helpers for mocking and stubbing

GitHub - DeliciousRaspberryPi/MockFive: A Mocking Framework for Swift Unit Tests

GitHub - mflint/SwiftMock: A mocking framework for Swift

GitHub - SwiftKit/Cuckoo: First boilerplate-free mocking framework for Swift!

CuckooはMockitoインスパイア系っぽい。

QA

  • 日付や時間に依存するテストはどう書くべき? -> 遭遇したことがないけど、考えてみるのも面白そう

@niwatakoさんの書き起こしも参照。

niwatako.hatenablog.jp

所感

Objective-Cでは(OCMock/OCMockitoでは)依存オブジェクトの扱いが雑な設計であっても、ランタイムにモック化することで強引にテスト可能だったりしたのですが、Swiftではちゃんと設計しないとダメだよね、という話。

またSwiftに限らず、モックは便利さにつられて乱用しがち、そしてフラジャイルな(壊れやすい)テストになりがち、という点まで、短い時間で正しく警告されていてすばらしいセッションでした。

モックに頼らない、という点は、設計の見直しで回避できるものももちろんありますが限界もあるので、より上層の(結合度の高い)テストレベルで担保するなどが最適解かな、と考えています*2。このセッションではそこまで詰め込めなかっただけだと思う。

なお、Swiftの一部メソッドを(Objective-Cの機能を使って)動的に置き換える手段について、Danielさんの"Code Injection from scratch"セッションで触れられていました。こちらも@niwatakoさんの書き起こし参照。

niwatako.hatenablog.jp

An Artsy Testing Tour

Ashさんのセッション。Artsyではこれまで4つのアプリに対してテストを書いてきたが、それぞれアプローチが違うので紹介する。

前提として、

ひとつ目のアプリ

  • テストは無かった。Apple TVローンチまで時間がなく、担当者一人で作ったもの。
  • テストを書くべきか否か、バランスを判断。コードベースが小さいものだったので、ローンチを優先した。

ふたつ目のアプリ

  • はじめテストは無かったが、コードベースが大きかったのでリグレッションテスト強化のため、後からテストを追加した。
  • "Bus factor"*3防止のため、テストのドキュメントとしての役割を重視*4
  • DIを多く使った
  • RSpec*5を使い、セットアップの共通しているテストはbeforeEachにまとめるなど、テストコードをリファクタリング。リーダブルなテストに。
  • 余りにネストしたcontext*6はおかしいので、設計を見直す。十分に説明的な名前がつけられるか?
  • テストはドキュメント
  • 振る舞いをテストする。コードをテストするのではない。

みっつ目のアプリ

  • これもはじめテスト無し、後で追加した。
  • ネットワークアクセスのあるアプリで、開発者も多く実装も散らばっていた。
  • はじめiPhone用、後にUniversal Appに。コンテキストが異なるので、一揃いのテストスイートを、iPhoneiPadふたつの観点からテストを実施した。
  • 大きなクラスからテストしたが、修正が入ると既存テストの書き換えも多発した。
  • Snapshot Test。画面のスナップショットを撮ってpngで保存し、ピクセルベースでdiffを取り合否判定*7。pull-requestの中にスクリーンショットがあるのでレビューしやすい。
  • 小さいクラスからテストすべき
  • 追加したコードにはテストを書く

よっつ目のアプリ

  • これは最初からテストを書いた。はじめてのSwiftアプリで手探り状態のところ、テストコードが拠り所になった。
  • テストツールにはQuick*8を使用。
  • Nimble*9というMatcherライブラリを使えば、assert()を、expect().to()形式で書けて可読性が高い。
    • Arrayなども直接比較できる。拡張もできるので、Snapshot用のMatcherを作った。

QA

  • TDDはハイコスト。クライアント側は手を抜いていいのでは?という意見があるが -> Swiftは型が強力なのでLLと比べてテストの重要性は低いが、でもコンパイラだけではチェックできない不具合を見つけられる。ドキュメントの価値もある。テスト大事。
  • Snapshot Testはどのテストレベルでやっている? -> 決めかねている。End to Endでなくてもいい。
  • TDDで「機能」を捉えるのが難しい -> TDDは賛否両論。Ashさんはどちらでもなくケース・バイ・ケース。繰り返しやっているとテスタブルなコードを書けるようになる。ロバストにはなりきらなくても、価値はある。小さく、小分けして、DI。繰り返しやってみること。練習である。

QAのメモはかなり怪しい。@niwatakoさんの書き起こしも参照。

niwatako.hatenablog.jp

所感

テストに対する姿勢、メリットが明確で、かつ4パターンの実際のアプリの事例を挙げられていることもあって、とても説得力のある、良いセッションでした。Spec BDD派が増えそう。

Spec BDDに限らず、可読性の高いテストはドキュメントとしても有効なので、ちゃんとメンテナンス、リファクタリングすべきですね。

また、質疑応答で出たTDDの話。プロダクトコードとテストコードを行き来することで、複数の視点でコードを見ることができるようになるはずなので、訓練だと思ってTDDをやってみるのは良いことだと思う。 後からテストを書くのは難易度が高いことが多いので、テストを書く習慣、テスタブルなコードを書く習慣をつけるのは良いこと。

カンファレンス全体を通して

先日のDroidKaigiもそうですが、開発者主体で、スポンサーも付けて、有料で、海外からも参加者およびスピーカーが来てくれる。ほんの2〜3年前には考えられなかったことで、それを実現された主催者・関係者の尽力はすごいと思います。

改めて、お疲れ様でした。ありがとうございました。

こうして(ごく一部のセッションの)ブログを書くことくらいしかできませんが、少しでも盛り上がりに貢献して、次回以降につながればいいな、と。

最後に蛇足ながら。Twitterで「本カンファレンスが1スレッド進行なのが良かった」という話がありました。完全に同意!なのですが、それは今の時期のSwiftだから、という条件付きかも。マルチセッションがすべて悪、みたいな方向には行かないで欲しいかな。

*1:Javaでは「C言語のヘッダファイルみたいに増える」という批判がありましたが、少し前までObjective-Cで書いていたから抵抗ないはず?

*2:モック愛好家のポジショントーク注意

*3:日本だとトラックを使いますよね?

*4:いわゆる仕様化テスト

*5:と言っていたけど恐らくKiwiかな?

*6:describeと同義

*7:FacebookOSSとのことなので、恐らく https://github.com/facebook/ios-snapshot-test-case を使用

*8:RSpec, Kiwiと同様、Spec BDDライブラリ。 https://github.com/Quick/Quick

*9:https://github.com/Quick/Nimble

Mastering Android NDK(PACKT)の査読をした話

Packt Publishing Ltd. から出版された『Mastering Android NDK』の査読をお手伝いさせていただきましたのでご紹介。

f:id:nowsprinting:20151212122627p:plain

PACKTでeBook版を購入すると、PDF、ePub、Mobi*1でダウンロードできるほか、Kindleのコレクションに直接送る(send-to-kindle)こともできます。 Print版(ペーパーバック)もキレイな作りです。

www.packtpub.com

もしくは、Amazonでも購入できます。

www.amazon.co.jp

サンプルコードはPACKTのライブラリからダウンロードできますが、同じものがGitHubにもあります。

github.com

本書の内容・想定読者

本書は、Android NDKを使って、Android SDKだけでは実現困難なグラフィックスやサウンドの実装方法を紹介し、最終章でゲームを一本完成させる、という構成です。

Chapter 1でNDKアプリのビルド、Chapter 2でよく使われるC++ライブラリの組み込み方法を紹介した後、以降Chapter 10までC++の本。UnityやUnreal Engineといったゲームエンジンの台頭により、「クロスプラットフォームのゲームをAndroid NDKで作る」というケースは減っていると思いますが、もっと下のレイヤーまで知りたい、C++を駆使して実装したい、という方には参考になるはずです。

参考までに、目次は以下の通りです。

  • Chapter 1: Using Command-line Tools
  • Chapter 2: Native Libraries
  • Chapter 3: Networking
  • Chapter 4: Organizing a Virtual Filesystem
  • Chapter 5: Cross-platform Audio Streaming
  • Chapter 6: OpenGL ES 3.1 and Cross-platform Rendering
  • Chapter 7: Cross-platform UI and Input System
  • Chapter 8: Writing a Rendering Engine
  • Chapter 9: Implementing Game Logic
  • Chapter 10: Writing Asteroids Game

査読を頼まれた経緯

私のまわりでPACKTの査読をしたという話を聞いていないので、経緯などをざっくりと。

日本では、著者が自身の知り合いに査読を依頼し、その査読反映をもって著者脱稿として編集者に渡る、という流れが一般的だと思いますが、PACKTでは以下の流れで進められました。

  1. PACKTの「レビュアー獲得責任者」が、本書の査読ができそうな人を探して打診する。GitHubリポジトリなどの実績から選んでいるそうです
  2. 原稿は、著者とも編集者とも直接やり取りはせず、本書のコーディネータ経由で送られてくる(まとめてではなく、章ごとに数週間間隔で)
  3. 受け取った原稿に対し、テクニカルな指摘のほか、章ごとに内容の過不足や満足度といったアンケートも書いて返送する

本書に関しては、Android NDKやGradleまわりのサンプルをGitHubに上げていたのが目に止まったのだと思います*2。ニッチなものでも(ものこそ?)公開しておくものですね。

英語は義務教育レベルも怪しい私ですが、文法や言い回しに関してはちゃんとPACKTの編集者さんが付いており、我々レビュアーはテクニカルなところだけ見てくれればいい、ということでお受けしました。 とは言え、テクニカルなところも、オーディオとか門外漢なので余りお役に立てていないのですが。

なお、PACKTの書籍をお持ちの方はご存知だと思いますが、Reviewerは紹介文付きで載ります。

f:id:nowsprinting:20151212115359j:plain

「ぜひ書店でお手にとってー」と言えないのが洋書の辛いところですが、GitHubに上がっているサンプルコードを見て良さそうなら本も買う、という判断がいいように思います。

また、Print版を持っていますので、勉強会などでご一緒するときに事前に言って頂ければ持参し、お見せすることはできます。

*1:Kindle向けフォーマット

*2:噂のトニーモリス氏からはメール来てません

リンスタカフェvol8「ユーザーテスト見学会」に行ってきました #devlove

バイトルで有名なディップ株式会社さんで開催された、リンスタカフェ vol8 「特別編:ユーザーテスト見学会~みんなでピザとビールとUTを楽しもう!」に行ってきました。

devlove.doorkeeper.jp

実際に参加者の中から数名が被験者となって、写真共有サービス「30days Album」などのユーザテストを行ない、その様子をつまみに飲むという趣向。したがって、まず乾杯して開始。

ちなみに「リンスタカフェ」とはリーン・スタートアップに関するアレコレを話たりするイベントで、今回はなぜか初参加の方が多かったとのこと(私もです)。

以下、進行に沿ったメモですが、あとから質問した内容なども追記しています。

LEDライトを点灯させるテスト

  • ウォーミングアップとして、5名選出
  • 一人づつ室内に呼び、点灯のさせかたが特殊なLEDライトを渡し「点灯させてください」(タスクを与える)
  • 試行錯誤する様をみんなで観察
  • 点灯できたら、試行錯誤の手順を振り返り、「どう考えて操作したか」をヒアリング(回顧法/retrospective report method)
  • プレッシャーがかかるので、失敗しやすい
    • プレッシャーを緩和させる努力は、やっても効果が薄い
    • さらにプレッシャーをかけることもある。制限時間を設けて、砂時計を置く。

回顧法と思考発話法

  • 回顧法は、被験者が思考を覚えていないので不完全
  • 思考発話法(think aloud method)は、少し練習させてからでないと難しい
    • 練習は、お手本の動画を見せるのが早い。例えばUIscopeさんの被験者向けお手本動画(下記)
    • 被験者曰く「それでも難しい。行動を話すのが精一杯」

www.youtube.com

写真共有サービス「30days Album」のテスト

  • 被験者は、以下を満たした方
    • iPhoneを常用している方(Android版はUIが異なるため、OS自体への慣れ)
    • 普段から写真のシェアを行なう方
    • 30days Albumについて知らない、聞いたこともない方
  • 時間の関係で2名でしたが、本来は5名いれば問題の85%は見つけ出せるとのこと。
  • 今回は思考発話法なので、別室で練習。
  • ユーザーテストの流れ
    • 事前アンケート。普段どのように写真を共有しているか。誰に、どのサービスで。
    • タスクの提示(複数のタスクもあらかじめ提示。小出しにしない)
    • タスク(思考発話法)
      • 友達からアルバム共有のURLが送られてきたので、アプリで開く
      • アルバムから写真を数点、端末に保存する
      • アルバムに自分で撮った写真を追加する
      • 新規にアルバムを作り、写真を追加して友達にシェアする(SNS等でシェアする手前まででゴール)
    • 事後ヒアリング。このアプリを今後も使おうと思ったか、どこで詰まったか。

ドキュメント共有「DocBase」のテスト

  • 被験者は、以下を満たした方
    • 開発者(開発者向けサービスなので)
    • DocBaseを使ったことがない方
  • 同様に思考発話法で実施
    • 配属された先でDocBaseを使っている。アカウント追加したメールが届いたので、サインインして開発環境セットアップ手順書を確認する
    • 日報のテンプレートがあるので、探して日報を書く

所感

ユーザーテストの実施方法と、それを実際に見ることで、悪いUI/UXを炙り出せることは実感できました。

ただ、ではやろう、となったときの課題として以下がありそうです。

  • 適切な被験者、適切なタスクの設定
  • 結果をどう受け止めるか。シンプルに悪く、修正できる問題ならいいけれど、往々にしてトレードオフがあったりするはず

前者は、UIscopeさんのようなユーザーテスト実施サービスを利用することで解決しそう。タスクなど自前で用意できるのであれば安く、そうでなければテスト設計から分析レポートまで付けてくれるプランもあるそうです。

ユーザーテストサービスのUIscope

一方後者は、特に受託でやっていると色々難しい気がしました。受託の場合、顧客主導で(顧客 - UIscope 間で)やってもらわないとうまくいかなそう。

また、今回は触れられませんでしたが、テストとして実施するのであれば合格基準を設ける必要がありますし(例えばタスク完遂率とか、NE比とか)、このあたりはISO 9241-11とかISO 13407とか読んでみなくては。

あと、以前おすすめされて積読になっていたこれを読まなければ。

マーケティング/商品企画のための ユーザーインタビューの教科書 (Mynavi Advanced Library)

マーケティング/商品企画のための ユーザーインタビューの教科書 (Mynavi Advanced Library)

クックパッドエンジニアのトークナイト 〜クックパッドテストエンジニアのあり方〜 に行ってきました #cooketn

クックパッド株式会社さんで開催された『クックパッドエンジニアのトークナイト 〜クックパッドテストエンジニアのあり方〜』に行ってきたメモ。

connpass.com

クックパッドテストエンジニアのあり方

松尾さんのスライドに沿って、要所要所で t_wadaさん、諸橋さん、yoshioriさん含めたパネルディスカッションが入る進行。

www.slideshare.net

以下、メモ。

  • クックパッドでは、"Quality Improvement"と位置づけられている。品質"保証"ではない
  • 呼び方:QA、テストエンジニア、テスター、etc...
  • 募集から見てみると、やはり様々
    • Test Engineer @Google
    • Senior Software Engineer @Netflix
    • SWET @DeNA
    • テストエンジニア @cookpad
  • Qualityとは?
    • 「品質とは誰かにとっての価値である」
    • あなたのビジネスは何を生業としていますか?
      • 自動車など、製造業:腐食など経年劣化まで含めて保証 -> Quality Assuranceという考え方
      • 受託開発:納品のため。合意形成した指標を満足する。また、それを示す。 -> これもQuality Assuranceでok
      • サービス業:利用時の品質、ISO 25000, ISO 9241, ITILなど。対人なので「保証」はそぐわないのでは?
        • 価値検証を「しっかり素早く」し、改善を繰り返して品質を「向上」させる
          • TDD/BDD、自動化されたテスト、内部品質を高める
  • TDDと品質
    • 5年くらい前に炎上した話題。5年経過した今は?
    • t_wadaさん:
      • 厳密なTDDをやってる人は少ないけど、自動テストを書いている人は増えている、という印象。業界/会社ごとに乖離している。
      • 炎上の原因。「テスト駆動開発」の「テスト」という言葉。testでなくchenkだよねという話。「テストとは対象を破壊しようとする試み」(マイヤーズ『ソフトウェアテスト技法』)を前提とすると、TDDのテストとはcheckingである。
      • 開発者テストは書く習慣がつくと、なかなかやめない。
      • 割り切って考えられるエンジニアが増えた。「それはTDDじゃない」みたいなTDDの定義の話でなく、自分のスタイルでテストは書く、という方向。
  • サービスの開発速度を高めるために補完されるテスト
  • テストエンジニアに求めているもの
    • t_wadaさん:テスト書きすぎ問題。適切に減らすのが難しい。どこまでテストするのか
      • see: 直交表、ペアワイズ法。ツールとして、PICT、PictMaster
    • 諸橋さん:不具合のパターン、ユーザのイレギュラー操作を突くテストケース
  • サービスの開発速度を高めるための組織
    • 専業化していく? Quality Engineer, Software Engineer in Test, Test Engineer, etc...
    • クックパッドでは、今:土台作り、テスト環境の改善。発展させていきたい

ソフトウェア・テストの技法 第2版

ソフトウェア・テストの技法 第2版

  • 作者: J.マイヤーズ,M.トーマス,T.バジェット,C.サンドラー,Glenford J. Myers,Todd M. Thomas,Tom Badgett,Corey Sandler,長尾真,松尾正信
  • 出版社/メーカー: 近代科学社
  • 発売日: 2006/08
  • メディア: 単行本
  • 購入: 7人 クリック: 267回
  • この商品を含むブログ (46件) を見る

質疑応答

  • テストエンジニアを募集したけど集まらなかった
    • テストエンジニアはそもそも少ない
    • 欲しいスキルセット、応募側のスキルセットの解離があるのでは? GoogleやNetflixのように、ちゃんと名前をつけるべきでは?
    • 海外/外資だとQAの地位が高い。知識も高い。まず松尾さんが高給取りになるべき
  • テストコードがないプロジェクト
    • まず自分だけでもテストを書く。徐々にまわりに広げる
    • 先にCIサーバを立てて、静的解析やインスペクションだけでもまわす。周りに、面白そう、楽そう、という印象を与えて広める
  • テストの過不足、十分性
    • 足りている状態を定義、どこをokのラインとするか。正常系を優先とか。リスクの高低で評価する
    • 組み合わせテストも、組み合わせ数の十分性がレポートとして出ているので基準にできる。判断根拠の資料は残すべき。
  • End to Endテストは誰が書くべきか
    • 諸橋さん:E2Eのシナリオも開発者が書く限りchecking。テストエンジニアによってtestingに持っていく
    • yoshioriさん:black box/white boxで考える。E2Eはblack boxで中身を知らない人が書くべきなので、分業が理想
    • 松尾さん:checkingは自動で判断できるところまで。ユーザビリティなど人間がやるところがtestingという切り分け
    • t_wadaさん:気付かないものは気付けないので、それが開発者テストの限界。テストエンジニアが探索テストで見つけた不具合を自動テストで再現して自動テストに取り込んでいく。checking を拡張してtestingに。ランダム性、揺らぎを取り入れることで自動テストを拡張する

所感

特に「開発者テストをやってる人」「テストエンジニア」どちら向けともアナウンスされていないイベントでしたが、参加者も両方混在だったような雰囲気でした。

テストエンジニアに求められるものはどんどん高度化していく(けどまだ地位が低い)ので、うまく開発者側と補完しあえる組織の事例が増えていくといいですね。

Selenium勉強会@サイボウズに行ってきました #selenium_cybozu

10/20にサイボウズ株式会社さんで開催された『Selenium勉強会@サイボウズ』に行ってきました。

connpass.com

以下、メモ残したものだけ。内容すべて拾ってはいないので注意。

Selenium Conference 2015 参加報告

サイボウズの宮田さんより。

  • Selenium Conferenceは今年で5回目。今回はポートランドで開催。
  • 初日はワークショップ、2・3日目はセッション。セッション動画は公開されている
  • ランチ時も含めて、参加者間での議論も活発だった

面白かったセッションの紹介

  • FacebookのSimonさんのKeynote
  • Selenideの話
    • Selenide == Javaで書かれたSeleniumクライアントラッパー
    • smart waiting: shouldHave()で画面遷移・描画を待ってくれる
    • collection
    • automated screenshot
    • sizzle selectors
    • profiler
    • fast setVelue: JSでsetValueを置き換える(setValueの実行が遅いのを改善)
  • Selenium Grid Auto scale
    • AWSで構築
    • hub一つで、250並列
    • hub二つで、500並列
    • ネットワーク帯域を増やして、1000並列

テンプレートエンジンにMixer2を使うとSeleniumでのテストもラクになるかもよという話

ビズリーチの渡辺さんより、テンプレートエンジンMixer2がSeleniumによるテストと親和性が高いという話。

  • Mixer2は、Javaで書かれたテンプレートエンジン
  • DSLでなく、htmlのspan id/class指定を置き換えるエンジン -> SeleniumXPath書かずに済む
  • XHTMLJavaのObject変換が双方向 -> テストコード側では、パースして得たJava Objectに対してassertを書くことができる

SikuliXを知っていますか?

小原さんより、SikuliXの紹介と、Seleniumとの連携について。

  • sikulixからseleniumを呼ぶ
  • sikulixをライブラリとして使う
  • sikulix IDEで簡単にコードを書いたり、実行できる
  • Sikuliの開発をMITから引き継いだ時、xをつけてsikulixになった

本当にメンテナブルなSeleniumの運用について考えてみた

一休.comの赤坂さん

  • Seleniumのテストは、リグレッションテスト向けに書いて実行している
  • テストケースは30、8並列で実行
  • 本番環境は5〜7分、ステージングでは8〜10分
  • 最低限のシナリオ
  • 運用していくためにはどうするか
    • Page object design patternは手段の一つ
    • メンテナを増やす
      • 説明会、ドキュメント、継続的にアウトプット、自分でメンテしないで機能を実装した担当者にやらせる
      • フォローは喜んでやる

kintone開発を支えるSeleniumテスト

ふたたびサイボウズの宮田さん。kintoneの開発での実例。

  • 自動テストは一度壊れて放棄。『継続的デリバリー』を読んで再チャレンジ
  • テストケースは1000くらい
  • QAがテスト設計、PGが自動化実装
  • Java + WebDriver
  • 新機能追加時に受け入れテストも書いている
  • 既存機能は、手の空いた時に追加。優先順位はリスクを考慮してQAが決定
  • メインブランチに変更が入るたびテスト実行。落ちたらチャットで晒しあげられる
  • メンテナンス性
    • page object
    • 失敗時にスクショを撮る。動画も試したがリソースが辛かったのでやめた
  • コード品質を高める
  • 安定性の向上:リトライ回数。画面遷移待ちなどはラッパー(Selenideなど)でサポートされている
  • 実行時間;余計なテストは作らない、単体テスト等でカバー
  • IE, Safariはやってない

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

Seleniumデザインパターン & ベストプラクティス

Seleniumデザインパターン & ベストプラクティス

第6回「じどうかの窓口。」セミナー 〜クラウド時代のCIサービスとエコシステム〜 に行ってきました #ta_madoguchi

株式会社SHIFTさんで開催された「じどうかの窓口。」セミナーに行ってきました。今回のテーマはクラウドCIサービス(CI as a Service)。

madoguchi100.connpass.com

クラウドCIサービス5つの比較紹介

まず、SHIFTの太田さんから。

  • CI:継続的インテグレーションVCSへのコミットごとに自動テストを含むビルドを行なう、アジャイルのプラクティス。インテグレーション、せいぜいステージング環境へのデプロイまでを指す
  • CD:継続的デリバリー。CIにとどまらず、本番環境へのデプロイまでをパイプラインとして実行する
  • CIツールは、Apache Continuumなどが第一世代、Jenkins(旧Hudson)が第二世代、そしてクラウドCIサービスが第3世代と言える
    • Jenkinsの問題点として、維持管理にコストがかかる、環境が特殊になりすぎて「Jenkinsでしかビルドに成功しない」など。
  • クラウドCIサービスは、ざっと調べただけでも30以上ある
  • 代表的なクラウドCIサービスとして、5サービスを紹介・比較。
    • Travis CI
    • Circle CI
    • drone.io
    • Wercker
    • DEV@Cloud
  • Travis CIとCircle CIは、iOS/Androidアプリにも利用できる(OS Xが使えるサービスは少ない)
  • Circle CIはGitHub Enterpriseでも利用できるプランがあるが、OS Xは使えない
  • Werckerは日本で流行っている印象。利用者の4割ほどが日本人
  • DEV@CloudはJenkinsのクラウド版。無料プランは無いが、トライアル期間はある
  • どのサービスを使うにしても、そのサービスに依存してしまっては同じことの繰り返し。パイプライン構築にwalterのようなツールを使うなどしてポータビリティを上げたほうが良い

CI及びCDについて詳しく知るには『継続的デリバリー』がおすすめです。

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

また、以下の二冊にもCI/CDの概要および、Travis CIの使いかたが紹介されています。

システムテスト自動化 標準ガイド (CodeZine BOOKS)

システムテスト自動化 標準ガイド (CodeZine BOOKS)

  • 作者: Mark Fewster,Dorothy Graham,テスト自動化研究会,伊藤望,玉川紘子,長谷川孝二,きょん,鈴木一裕,太田健一郎,森龍二,近江久美子,永田敦,吉村好廣,板垣真太郎,浦山さつき,井芹洋輝,松木晋祐,長田学,早川隆治
  • 出版社/メーカー: 翔泳社
  • 発売日: 2014/12/16
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (3件) を見る
iOSアプリテスト自動化入門

iOSアプリテスト自動化入門

プルリクエスト駆動型国産コードインスペクションサービスSideCIの紹介と活用方法

SideCIを運営する、株式会社アクトキャットの角さんによる、SideCIの紹介、デモ。

  • SideCIは、コードレビュー向けのCIサービス。インスペクションをやってくれる
  • GitHubと連携し、pull-requestに対してコードの問題点や改善方法をコメントしてくれる
    • インスペクションの対象はpull-requestに含まれるファイルのみなので、フォーカスを絞って対応できる
  • 裏では各言語向けのLint等インスペクションツールを走らせている
    • ツールによっては、SQL Injectionも指摘してくれる
  • 現在はPHP, Ruby, Pythonなどを中心にサポート
  • 現在ベータサービスだが、ほぼすべての機能を無料で提供しているので、ぜひ使ってみて欲しい

www.sideci.com

ディスカッション:クラウドCIサービスやその周辺サービスの活用と課題

テーブルごとに分かれてディスカッション。私のいたテーブル(4名)で出た話は以下の通り。

  • 4名とも、現在はJenkinsを利用*1。しかし内情はそれぞれ異なっている
    • AWS上に構築、AWSの契約は顧客
    • 社内サーバに構築。Active Directoryを使う都合でテスト実行環境を外部に置けない
    • iOSアプリ開発ではビルド環境のバージョンアップ時期にはクラウドサービスは使いにくい
    • 本番環境には直接つながっていない、顧客管理下である、などの理由で、デリバリーまではつながっていない
  • いずれも、Jenkins専任の担当者はおらず、インフラ担当者などが兼任しているが負担は大きい
  • Jenkins環境の安定性はひとつの課題であると太田さんの話にありましたが、AWS上に構築し、イメージの履歴管理をするなど工夫している
  • テストまでは実行しているが、インスペクションについてはわかれた
    • PyLint, pep8を実行している
    • 古いコードがあり、その内部品質が悪いため、インスペクションのエラーに対処しきれない
      • エラーとなるしきい値をチューニングしては?
      • Googleの出した"bugspots"を使う/組み合わせるといいかも?
      • インスペクション対象を指定できればいいかも?
  • クラウドCIサービス導入への課題
    • テスト実行環境の制限
    • 料金。顧客に納得させるか、受託側でかぶるのか
    • 以前オープンソースのプロジェクトにpull-requestを出したとき、ビルド待ちがとても長かった(数時間〜半日)
      • Freeプランだと待つ。有料プランではもっと速いはず

最後に、他のテーブルの「クラウドサービスを利用できない理由」

  • コードを外に出せない、セキュリティ、SLA(ダウンタイムとか)
  • サービスを組み合わせて使うということは、サービスの数だけ会社の承認を取る必要がある

まとめ

みんな苦労してるんだな、というか、苦労してるからここに来たんだな、という当たり前の感想を持ちました。

クラウドサービスにはまだ課題があるとして、それ以前にテスト実行環境のコンテナ化など、テスト実行を安定させるためにできることは多そう。

蛇足ですが、SHIFTの太田さんと玉川さんが監訳された本を持参してサインいただきました!

Seleniumデザインパターン & ベストプラクティス

Seleniumデザインパターン & ベストプラクティス

*1:私も受託案件はJenkins

第2回 FOVE体験会&トークセッションに行ってきました

DMM.make AKIBAにて行われた、PANORAさん主催の『第2回開催!! FOVE体験会&トークセッション』に行ってきました。

atnd.org

FOVEは、現在Kickstarterでクラウドファンディングを行なっている視線追跡ができるVRHMDです。Backer募集はあと60時間ほどで締め切られ、また締切後の一般販売はしばらく後になるそうです。気になっている方はお早めに。

www.kickstarter.com

FOVE体験

受付でもらった整理券が6番だったので、トークセッションに先立って実機でデモを体験しました。装着した感じ、とても軽く感じられました。

デモの最初に視線(瞳孔?)をキャリブレーションするプロセスがあり、視界の周囲を、左上、右上、右下、左下、と緑の点が表示されるのを見つめます(まばたきしてはダメらしい)。

デモは宇宙モノのシューターで、自分の位置は固定、視線の方向に弾が発射されるというもの。視線追跡のスピードと精度は十分確認できました。 頭を素早く動かしたときの追随性も問題なさそう。ただし、デモの作りにもよるので単純に他と比較できるものではありませんが。

FOVEの紹介

FOVEのCEO小島由香さんによるFOVEの紹介。以下、簡単なメモ。

  • VRの世代として、presenceの世代、controlの世代と来た(イマココ)。そしてexpression、感情表現ができるのがFOVE
  • parallax error==左右の視差のため、咄嗟にエイムできない
  • FOVEは、FPSのほか、キーボードをタイプする用途にも使える。1cm角くらいは認識できる
  • 見ている部分だけ解像度を上げることで、1/6くらいの負荷低減が見込める
  • 用途は、わかりやすいのはゲームだが、ALS患者(末期だと眼球と脳波しか入力に使えない)、筋ジストロフィー患者

トークセッション

FOVEのCEO小島由香さん、CTOのロキ(ロックラン・ウィルソン)さん、週刊ASCII初代編集長の福岡さんによるトークセッション。以下メモ。

1. なぜFOVEを作った?

  • 元々、PS VITAのフロントカメラで表情を取るところが原点。そこからアイトラッキング
  • 企画をスタートしたとき、VRはここまで流行っていなかった
  • 1995年に『CAPE X』というVR雑誌を創刊。9冊で休刊*1(福岡さん)

2. ハードづくりで技術的に難しかったところは?

  • はじめはハードを作る気はなく、iPadとソフトの組み合わせで考えていたが、精度や画面サイズなどからHMD制作へ。試作は既存製品に穴を開けて改造
  • 小ロットで部品を調達するのは難しかった。日本企業の方がそのへんは協力的。面白そうなものには協力してくれる。
  • アメリカはお金は集めやすいけど、部品調達は日本のほうが楽。SFは家賃も高い。
  • Kickstarterのコンバージョン率は日本の方が高い
  • 視線は、瞳孔を赤外線で拾っている。可視光をブロックすることで精度を上げている。
  • 黒目を追跡==black spot tracking

3. 目線追従ってどんなことに使っていきたい?

  • ピアノを弾く少年のVTRのように養護施設への提供(Just giving project)、年内には実機が配られる予定
  • 軍事、ドライブシミュレータ。ドライバーがどこを見ているかを後から収集・解析できる
  • お店の陳列のA/Bテストを簡単に行える
  • ドローンの操作。ただし視線誘導の問題として、衝突しそうな障害異物を見てしまって、そちらに飛んでしまう
  • 犬、猫は人間より視野角が広いので、その疑似体験
  • 自閉症の人は他人の目を見るのが苦手なので、克服する訓練に使う
  • MITで面接シミュレーションの研究がされている

4. 開発にあたって他のVRHMDと異なる注意すべき点は?

  • 基本はUnity、Unreal Engineでも作れるはず
  • 全てがくっきり見えるのはVR的にはよくない。ピントが外れているところはぼやけるのが現実に近い
  • ピントの合っているものの情報を表示する(攻殻機動隊みたいに)
  • 片目をつむるとズームするなどの工夫も

5. VR業界は今後どうなる?

  • 90年代、ヒッピー、LSD、VR、みたいな流れ。NASAでも研究。これらが合流したのが97年くらい。当時で2〜3千万円くらいの機材
  • 当時の問題は、解像度、コスト
  • 最近は酔わないVRコンテンツのノウハウも溜まってきている
  • personal/consumerのVR

質疑応答

  • アイトラッキングでできること → ウィンク、まばたきも取れる
  • 瞳孔の収縮をトラッキングできるか? → 瞳孔の大きさとして取得はできるが、明るさなどの要因もあって難易度は高いと思う
  • 外見デザインのこだわりは? → (CEOが)女性なので、つけて格好いいもの、シンプル、ミニマルな、無印良品的な。製品版はもっと小さくできる

懇親会でロキさんに伺ったこと

  • SDKは筐体より早め、あと3ヶ月くらいで出せると思う。早めに出して開発者の意見を取り入れたい
  • フォーカスと解像度の連動は自動ではなく、シェーダでフォーカス範囲を取得して解像度を判断する処理が必要。サンプルのシェーダが付くので、それを参考にできるはず

*1:懇親会で聞いたところ、当初月間、途中から隔月刊