開会の辞
Tony Voellm（Google）
リンク: 動画
開会の基調講演 - 品質保証からテスト エンジニアリングへの進化
Ari Shamash（Google）
アプリをリリースしました。成果をあげ、いくらかの資金を集め、資金を調達し、ゼロから始めて、まさに「上手にやる」ことだと思いました。しかし、新機能の需要は非常に高く、かつてない規模で前例のない速度の伸びを求められています。これはどうすればよいですか？
捨ててゼロから始めることはできないので、今あるものを進化させ、高品質の機能を圧倒的なスピードで追加し続ければよいのです。また、既存の手法が破損しないようにする必要があります。そのためには、幸い、ソフトウェア エンジニアリング業界には、この一般的なシナリオに対処する新しい分野があります。Google ではこれを「テスト エンジニアリング」と呼びます。
このセッションでは、テスト エンジニアリングとは何か、それが品質保証からどのように進化したか、また業界全体がテスト エンジニアリングをどのように実装したかに焦点を絞って説明します（Google での具体的な実装例も取り上げます）。
@Twitter によるシステムの大規模なテスト
James Waldrop（Twitter）
James は、Twitter でパフォーマンス テストに取り組むツール、プロセス、理念についてお話しします。特に、Iago オープンソース負荷テスト ライブラリに重点を置き、このライブラリは、コードを本番環境にデプロイする前に Twitter のエンジニアリング チームが負荷テストを実行できるように作成しました。ここでは、これらのテストの一部（ソースコードを含む）の実装の詳細と、OAuth や任意の Thrift プロトコルなどの複雑な要素の管理方法について説明します。
モバイル OS のテスト方法
David Burns（Mozilla）、Malini Das（Mozilla）
これが、FirefoxOS の世界に足を踏み入れることになったときに Mozilla が直面した問題です。どこから始めて、どうやって行うのが面白いタスクだと判断しました。この問題を解決する方法、新しいフレームワークを作成した方法をお聞きください。
継続的デリバリー パイプラインでのモバイルの自動化
Igor Dorovskikh（Expedia）、Kaustubh Gawande（Expedia）
Expedia は 2012 年初頭に、モバイルウェブおよび iOS/Android アプリへの投資を開始しました。それと同時に、テスト エンジニアは、サービスの品質とテスト可能性を最初から構築するテスト自動化ソリューションの開発を開始しました。このトークでは、Expedia のアジャイル開発および継続的デリバリー環境で、オープンソース ツールを利用して自動テストを構築した経験と教訓を共有します。ここでは、Test Pyramid と、Google で効果を発揮した特定のオープンソース ツールについて詳しく説明します。オープンソース ツールとして、Cucumber、ウェブ自動化ツール Selenium-WebDriver、iOS 自動化ツール Frank、Android 自動化ツール Robotium、Calabash、継続的インテグレーション システム（Jenkins）などの BDD ツールが挙げられます。さらに、TDD、ペア プログラミング、ビルド、テスト ラジエーターなど、Google が導入を目指しているアジャイル デリバリーの原則についても紹介します。最後に、アジャイルなテストと自動化の自動化から得たメリットと、それにより継続的デリバリーの目標を達成する方法について説明します。
GStreamer と OpenCV を使用した自動セットトップ ボックス テスト
David Röthlisberger（YouView）
GStreamer のコマンドライン ツールと OpenCV を使用して、動画キャプチャ画像認識システムを 3 分で構築します。（GStreamer はオープンソースのメディア処理フレームワークで、OpenCV（Open Computer Vision）はオープンソースの画像処理ライブラリです）。
このようなシステムの代表的な例は、セットトップ ボックスの UI テストを自動化するために YouView で開発されたオープンソースのツールである http://stb-tester.com です。stb-tester、GStreamer の基盤となる柔軟性、それがもたらすいくつかの可能性、今後の課題について説明します。
リンク: 動画
Chrome 用 Webdriver
Ken Kania（Google）
Chrome は、Windows のみのブラウザとしてリリースされてから、Mac、Linux、ChromeOS に加え、最近では Android と iOS にも拡張されました。これらのプラットフォームでのウェブ アプリケーションのユーザーレベルのテストは困難であり、さまざまな自動化アプローチが必要でした。このセッションでは、すべてのプラットフォームで WebDriver を Chrome で使用できるようにするために Chrome チームが行っている取り組みについて説明します。基礎となる手法を技術的に見ていきますが、デベロッパーが新しい ChromeDriver を使用して Chrome のさまざまなプラットフォームのテストを作成する方法に焦点を当てます。また、プロジェクトの現在の状態と将来のロードマップについても取り上げます。
Karma - JavaScript 用テストランナー
Vojta Jina（Google）
Karma の概要 - 実際のブラウザでスムーズかつ楽しい JavaScript アプリケーションをテストするテストランナー。
多数のブラウザやデバイスで動作する必要がある JavaScript アプリケーションを構築している場合、テストは省略できます。しかし、これらすべての多様な環境でテストを実行するのは困難です。Karma は、この手間のかかる作業を簡単な作業に変えています。スマートフォンやタブレットなどの実際のブラウザやデバイスで、ターミナルやお気に入りの IDE から直接 JavaScript テストを実行できます。
リンク: 動画
動画品質の自動測定
Patrik Höglund（Google）
はい。動画の品質など、複雑な主観的な測定値を自動的にテストできます。このセッションでは、WebRTC ビデオ通話の継続的な自動テストをどのように構築したかについて説明します。ツールチェーンの概要と、ツールチェーンの作成中に発生した問題をご紹介します。メディアテストを次のレベルに引き上げる方法のヒントを得るために最適な方法です。
悪いことが起こると...
Minal Mishra（Netflix）
モバイル コンピューティングとタブレット コンピューティングの急増により、ソフトウェア業界はアプリケーション開発プラットフォームに浸透しました。コンピューティング プラットフォームで消費者アプリケーションを開発することで、エンドユーザーは独自の魔法を体験できます。消費者向けソフトウェア企業は、このようなプラットフォーム向けのアプリケーション開発で常に最善を尽くそうとします。しかし、アプリケーション開発における最大の課題は、企業が最初のバージョンをロールアウトした後にのみ始まります。消費者とソフトウェア企業は、最新の機能や機能を最高品質でできるだけ早く開発することを望んでいます。そのため、スタックの各レイヤでコードの絶え間ない変化が生じます。UI 自動化エンジニアは、さまざまな問題を検出するシステムを構築し、アプリケーションの問題を迅速に特定します。このセッションでは、アプリケーション レイヤの外にある問題を発見する一方で、ユーザー エクスペリエンスに悪影響を及ぼす問題を検出するために役立つ、このような検出システムの背後にあるいくつかの課題と成功についてご紹介します。
教育向けゲームのテストとテスト用ゲーム
Tao Xie（ノースカロライナ州立大学）
このプレゼンテーションでは、Pex4Fun（http://www.pexforfun.com/）が、自動テスト生成を活用してオンライン プログラミング システムにおける自動採点を支え、何十万人ものユーザーにスケーリングできます。クラスルーム以外でプログラミング指向のゲーム体験を提供し、パラメータ化された単体テストの作成などのテストスキルを含め、プログラミングとソフトウェアのエンジニアリングのさまざまなスキルを学ぶためのトレーニングを行います。Pex4Fun は、課題の採点という既知の問題に加え、インタラクティブなゲームをベースにした楽しい学習体験にも大きく貢献しています。2010 年 6 月に一般公開されて以来、Pex4Fun はコミュニティで大きな人気を集めてきました。2013 年初頭の時点で、「Pex を尋ねる」ボタン（ユーザーが Pex4Fun でゲームを解決しようとしたことを示す）のクリック数が 100 万を超えました。
基調講演のまとめ - Facebook での Android 向け Facebook のテスト方法
Simon Stewart（Facebook）
Facebook は、人気のある Android アプリの一つです。このセッションでは、Facebook が各リリースの品質向上に取り組んでいることをご紹介します。コードの管理方法から、テストの手法から dogfood まで、あらゆる項目を網羅しています。
開会の基調講演 - テスト可能な JavaScript - テストしやすいようにアプリケーションを構築する
Mark Trostler（Google）
テスト可能な JavaScript はプロセスです。空白のスレートから開始しても、すでに実装されているアプリケーション（あるいはその中間）でも、JavaScript コードをシンプルかつクリーンに、効果的にテストできます。テストできないコードは書き換えられます。
JavaScript は実行環境が多種多様であるため、独特なものですが、JavaScript にも当てはまる、他の言語による実証済みの「テスト可能な」手法がいくつかあります。もちろん、JavaScript デベロッパーがコードを記述してテストする際に直面する固有の課題は依然として存在します。
コードをテスト可能にするパターンとはテストの妨げになるアンチパターンは次のうちどれですか。コードのテスト性を測定するために使用できる指標や常識的なガイドポストは何かテスト可能なコードを作成するプロセスが開始されたら、次は何をすればよいでしょうか。
テスト可能な JavaScript を作成するプロセスを詳しく説明します。Google は、テストのしやすさ、ひいてはコードの保守性、正確性、寿命を大幅に向上させるアイデア、パターン、手法を調査します。クライアント側の JavaScript を作成する場合でも、サーバー側の JavaScript をマスターする場合でも、このプロセスをマスターすることでコードの品質が大幅に向上します。
マトリックスの破壊 - 大規模な Android テスト
Thomas Knych（Google）、Stefan Ramsauer（Google）、Valera Zakharov（Google）
赤い錠剤の準備はよろしいですか？
モバイルによって、人間とコンピュータとの関わり方は様変わりしました。これは素晴らしいことですが、エンジニアは、コードが実行される環境のマトリックスが絶えず直面しています。少数のブラウザや画面解像度しか考慮しない時代が到来しました。エンジニアはマトリックスにどのように対処できますか？ここでは、Google がワークステーション、クラウド、頭の中でこのテスト問題にどのように対処しているかを説明します。
「Neo に関しては、ただ、ドアしか見せることはできません。確認するのはあなたです。」
Android UI 自動化
Guang Zhu（徐光）（Google）と Adam Momtaz（Google）
Android がモバイルで普及するにつれ、アプリ デベロッパーと OEM ベンダーは、アプリまたはプラットフォーム全体の UI をエンドツーエンドでテストする方法を模索するようになりました。Android での既存の UI 自動化ソリューションを簡単に確認しながら、最近リリースされた Android UI Automator フレームワークを紹介し、その後、フレームワーク、一般的なユースケース、ワークフローの内部を引き続き説明します。
Appium: モバイルアプリ向けの自動化
Jonathan Lipps（Sauce Labs）
Appium は、ネイティブ モバイルアプリとハイブリッド モバイルアプリ（iOS と Android の両方）を自動化する Node.js サーバーです。Appium の考え方では、アプリを修正するためにアプリを変更することはできません。また、テストコードはどの言語またはフレームワークでも作成できる必要があります。その結果、モバイルと同じようにネイティブに動作する Selenium WebDriver サーバーが使用されます。Appium は実際のデバイスとエミュレータ上で動作し、完全にオープンソースであるため、モバイルテストの自動化を開始するのに最適な素晴らしい方法です。このトークでは、Appium の設計の基本原則、他のモバイル自動化フレームワークにおける Appium を紹介し、その魅力を引き出すアーキテクチャを紹介します。最後に、新しいモバイルアプリの簡単なテストのコードについて掘り下げ、Appium が iPhone と Android でこのテストを実行する例を示します。
Google+ モバイル向けのスケーラブルなモバイルテスト インフラストラクチャの構築
Eduardo Bravo（Google）
ネイティブ アプリを有意義で安定かつスケーラブルな方法でテストするのは困難です。G+ は、モバイルが提示する複雑なテストシナリオごとに適切なインフラストラクチャを提供することで、こうした問題に取り組むための効率的なソリューションを開発しています。現在のテスト インフラストラクチャでは、iOS アプリと Android アプリの両方に適切なツールが提供されています。開発チームは、新しい変更が既存のクライアントに影響を与えないという確信を与えています。
Espresso: Android UI テストを最初から実行
Valera Zakharov（Google）
更新 [2013 年 10 月]: Espresso がオープンソースにhttps://code.google.com/p/android-test-kit/ をご覧ください。
エスプレッソのショットを撮るのと同じくらい、信頼性の高い Android テストの開発も迅速かつ簡単でなければなりません。残念なことに、既存のツールでは、ダブルショット キャラメル ソースを逆さまにしたシングル ヒープ ハーフ デカーフ ラテを作るような感じがします。わかりにくくて一貫性がありません。Espresso は、簡潔で美しく、信頼性の高い UI テストを迅速に作成するための新しい Android テスト フレームワークです。コア API は小さく、予測可能で、習得も簡単ですが、カスタマイズも可能です。Espresso のテストでは、ボイラープレート、カスタム インフラストラクチャ、乱雑な実装の詳細を妨げることなく、期待、インタラクション、アサーションが明確に述べられます。テストは最適に動作します。待機、同期、スリープ、アンケートはすぐに実行し、UI が静止している間はフレームワークが正常に操作してアサートします。ぜひ実際に UI テストの作成と実行を始めましょう。Espresso をお試しください。
WebDriver によるウェブ パフォーマンス テスト
Michael Klepikov（Google）
ウェブ パフォーマンス テストでは、ページの読み込み速度を分析する方法がよくわかりました。しかし、ページの読み込みだけでなく次の段階に移行する必要があります。最新のアプリは高度にインタラクティブで、オペレーションはページ全体を再読み込みするのではなく更新する傾向があります。私を含め、さまざまな人が WebDriver をウェブ パフォーマンス テストハーネスに統合しました。これにより、パフォーマンス テストは他の UI テストスイートとは別に分離されます。最近追加された Logging API を利用して、WebDriver 自体に直接パフォーマンス テスト機能を組み込むことを提案します。これにより、通常の機能テストの実行中にパフォーマンス指標を収集できるため、パフォーマンス テストの開発とテストのフロー全体とよりシームレスに統合できます。また、大規模な組織の大半が作成するカスタムビルド/テスト ツールチェーンへの負荷も軽減されます。
新世代の ChromeDriver（Chromium ブラウザ用 WebDriver）を使ってデモを行います。
マップの継続的なデータテスト
Yvette Nameth（Google）、Brendan Dhein（Google）
継続的なテストでは通常、単体テストと統合テストを実行します。しかし、サーバーで処理するデータが実際に変更の最大の要因である場合、データ利用者が引き続きそのデータを使用できること、そして変化の速度や不適切な変更でクラッシュしないようにするにはどうすればよいでしょうか。継続的なデータテストの手法について、Google マップの例を使って説明します。
失敗したビルド内で自動的に原因を見つける - ビルドを中断したのは誰ですか？
Celal Ziftci（UCSD）、Vivek Ramavajjala（Google）
継続的ビルドは、Google の主要なインフラストラクチャの一つです。ビルドが失敗した場合、ビルドを緑色に戻すために、原因の変更リスト（CL）や変更リストを素早く特定することが重要です。
原因検出ソリューションは、小規模および中規模のビルドに存在しますが、大規模な統合ビルドには存在しません。
私たちのファルファインダーは、非常に短い期間で、大規模なビルドの CL CL を自動的に見つけることを目標にしています。過去 9 か月間の複数のプロジェクトでの本番環境の使用状況から、非常に有望な結果が得られています。この動画では、このファインダーを実装した方法、本番環境における成功例、使用感と外観について説明します。
ソフトウェア プロダクト ラインの品質の実証的調査
Katerina Goseva-Popstojanova（ウェスト バージニア大学）
ソフトウェアのプロダクト ラインは、プロダクト ライン内のシステム間で高い共通性を示し、バリエーションが十分に明確になっています。2 つのケーススタディ（中規模の工業用プロダクト ラインと大きくなったオープンソースのプロダクト ライン）から抽出したデータに基づき、体系的な再利用によって品質を向上させ、以前に経験した障害、ソースコード指標、変更指標から発生する潜在的な障害の予測成功をサポートすることを経験しました。調査の結果、ソフトウェア プロダクト ライン設定において、静的コードが指標よりも障害と指標の関係が高いことがその他の調査結果で確認されました。品質評価結果によると、古いパッケージ（共通性を含む）は継続的に変化していますが、フォールト密度は低くなっています。さらに、オープンソース プロダクト ラインは、リリースに伴って品質が向上しました。一般化された線形回帰モデルに基づく予測では、以前のリリースで構築されたモデルを使用して、リリース後の障害に応じてパッケージを正確にランク付けしました。その結果、リリース後の障害予測は追加のプロダクト ライン情報の恩恵を受けることも明らかになりました。
AddressSanitizer、ThreadSanitizer、MemorySanitizer -- C++ 用動的テストツール
Kostya Serebryany（Google）
AddressSanitizer（ASan）は、C/C++ プログラムのバッファ オーバーフロー（スタック、ヒープ、グローバル）と use-after-free バグを検出するツールです。ThreadSanitizer（TSan）は、C/C++ プログラムと Go プログラムにおけるデータ競合を検出します。MemorySanitizer（MSan）は、初期化されていないメモリ（C++）の使用状況を検出する開発中のツールです。これらのツールはコンパイラ インストルメンテーション（LLVM と GCC）に基づいており、高速に動作します（たとえば、ASan では速度がわずか 2 倍になります）。これらのツールを使用した大規模テストの経験を共有させていただきます。
基調講演の締めくくり - 海洋の飲用 - Google 規模で XSS を探す
Claudio Criscione（Google）
クロスサイト スクリプティング（XSS）は、現代のウェブ アプリケーションにおける中世黒人のペスト病に相当するもので、今は広く普及しています。しかし、手遅れになるまでは技術的を検出する方法はほとんどないか、まったくないのです。DOM XSS は特に厄介な問題で、実際のブラウザや同等のものを検出するために必要です。自動化ソリューションがほとんどなく、難しい問題です。
開発ライフサイクルの早い段階で、セキュリティ チームの外部のエンジニアが使用できる DOM XSS を特定するために、高性能で自動化されたツールが必要でした。私たちが必要としていたのは、動きの速い、非常に複雑で難解なアプリケーションのコーパスをスキャンできる製品だけでした。そのため Google は、標準的な Google テクノロジー上で設計された DOM XSS をターゲットとするウェブ アプリケーション スキャナを独自に構築しました。App Engine で実行され、強力な Chrome ブラウザと数百の CPU をセキュリティ スキャン プラットフォームとして使用します。
また、Google のテストの武器として、セキュリティ チームの一員としてではなく、Google のテスト インフラストラクチャに属しています。
この講演では、Google の規模に合わせてシステムをスケーリングする際に直面した課題と、JavaScript を多用するアプリケーションでの検出とクロールモデルに対する考え方について、新たなアプローチについて説明しています。