Googleがソフトウェアをテストする方法

How Google Tests Softwareのウェビナーを聞いた後、私は非常に刺激を受けて、いくつかの論文を書くことにしました。 この記事は私の概要です。 まず、その内容を明確にする必要があります。 これは文字通りの翻訳ではありません。 ここでは、私にとって重要と思われるもののみを説明します。 簡単に言えば、ウェビナーで説明されているすべてがここで説明されているわけではありません。 また、何かを完全に理解していないか、誤解している可能性もあります。 そのため、 ウェビナーを自分で聴くことをお勧めします。
彼は、現在GoogleでCTOの役職を務めているJames Whitakerに率いられています。 ジェームズと彼の同僚は、同じ名前の本をリリースする準備をしています。 GoogleMaps、Google +、ChromeOS、Androidなどのテスト方法に関する包括的な情報を取得できます。

*さらに、プレゼンテーションを簡単にするために、ナレーションは私がジェームズであるかのように、一人称で行われます。

哲学

ほとんどの場合、Googleはエンジニアの文化を説き、管理職の見込みはほとんどありません。 ただし、各エンジニアは作業時間の20％を自分のプロジェクトに充てることができます。 今回は興味深いアイデアにとって最も実り多いものです。 たとえば、Gmailはそのようなアイデアから生まれ、人気のあるWebサービスになりました。 Chromeは20％のプロジェクトであり、人気のアプリになりました。 これらの例で、Googleの重要な機能の1つであるモビリティを強調したいと思いました。 新しいアプリケーションをすばやく作成します。 また、従業員は、ある開発グループから別の開発グループに簡単に移行できます。

Googleのテストの哲学では、テストは品質のためではないと述べています。 テストはエンジニアリングカルチャーの一部です。 テストは開発の一部であり、テストはリリース前に行うことです。 しかし、品質を上げるためのテストは行っていません。 高品質は、テストではなく、開発者、プロジェクトマネージャー、テスターに​​よって設定されます。 私たちの特徴は、テストを作業の不可欠な部分にしたことです。 開発者は、テストでカバーされていないコードをコーディングできません。 これはすべて、ワークフローの一部として自動的に行われます。 テスターのポジションはなく、役割があります。 それらについては少し後で説明します。 テストは誰にとっても仕事です。 しかし、私たちは自分をテスターとは見なさず、エンジニアを生産性部門と呼んでいます。 結局のところ、アイデアはテスト自体を作成するのではなく、開発を加速することです。 結局のところ、エラーと誤算が遅延の主な原因です。 テストは、その数を大幅に減らすのに役立ちます。 したがって、開発をはるかに高速化できます。 100日でGoogle+を作成できたのはそのためです。 夏、つまり今後3か月で、機能にさらに100の新しい機能を追加することができました。 これは驚くべき開発速度です。 そして、あなたは何を知っていますか？ この製品は国際品質規格に準拠しています。 もちろん、ソフトウェアは常に完璧ではありません。 Google+も例外ではありません。 ただし、迅速かつ効率的に作成しました。

生産性

ご承知のとおり、私たちの役割はグーグルをスピードアップすることであり、すべてのテストを強制することではありません。 エンジニアの生産性を高めるために、特別なツールが用意されています。 共通のツールキット（IDE、コンパイラ、アセンブリシステム、テスト）があり、個々の製品に固有のものがあります。 製品のリリース、エンジニアのトレーニング、そしてもちろんテストに協力しています。 テスターに​​は、SWE、SET、TEの3つの役割があります。

SWE-機能性に取り組む主な開発者。 コードレビュー、TDD、単体テスト、受け入れテストが含まれます。 また、各コードの品質にも責任があります。 これは重要です。 テスターは品質に責任を負いません。 SWEは小さなコードを記述できず、テスターに​​このコードの改善を試みます。 これは彼自身の作品です。

SET-テスト環境を開発しています。 彼らはテストケースを直接書きません。 彼らは作成のためのインフラストラクチャを作成します。 フレームワークをリリースし、チェックのルーチンを自動化するユーティリティを作成します。 自動化された手順を作成します。 これについては本で詳しく説明します。

最初の2つの役割は、100％コードに関連しています。 反対に、3番目の役割は彼から抽象化されています。 TEの役割はユーザーに関連しています。 この分離は多くの理由で理にかなっていますが、その主な理由は異なる種類の考え方です。 コードを守る人もいれば、ユーザーを守る人もいます。 誰もが自分のビジネスに集中してほしい。 TEは手動でテストを行う人だとは思わないでください。 TEは多くのコードを記述します。 それらのコードは入力に何かを送信し、出力を検証します。 これは異なるレベルのテストです。 また、テストスクリプトも作成します。

戦略

ハイエンドソフトウェアリリース戦略の最も重要なコンポーネントの1つは、クロール、実行、実行と呼ばれます。 アイデアは、製品の迅速な作成、リリース、フィードバック、およびそれらへの迅速な対応に要約されます。 Googleはこれに優れています。 私たちが絶対に見たくないのは、2年の開発サイクルです。 誰かが走って手を振るとき、彼は彼が世界全体を変える素晴らしいアイデアを持っていると言います！ そして、私たちがそれを実現したら、それはクールになり、誰もが確かにそれを愛するでしょう。 この番号は当社では使用できません。 そのようなアイデアがある場合は、コードをスケッチします。 最も重要な機能を実装します。 できるだけ広い範囲の人々の結果を知りましょう。 あなたが間違っていたかどうかを調べます。 そして、あなたが正しいと判明した場合、ユーザーが存在し、次のステップに進むことができます。 このアプローチは、非常に大規模なプロジェクトにも適用されます。 18か月に費やしたChromeを見てみると、毎日新しいリリースを収集していることがわかります。 これらのリリースをカナリアと呼びます。 プロジェクトに関係するすべての人がそのようなリリースを受け取り、新しい機能を試すことができます。 週の終わりには、最高のカナリアリリースが選択されます。 ドッグフードリリースと呼ばれるこの毎週の候補では、チームのすべてのメンバーが作業する必要があります。 誰もが同じ最新リリースをテストすることが非常に重要です。 すでに解決されたエラーの検出を回避するため。 毎月、最高のドッグフードChromeが自動的に選択され、従業員向けに設計されています。 後で、開発者とやり取りするために使用するツールについて詳しく説明します。 興味深いパターンが見つかりました。 dogfoodリリースのユーザーは、開発者やテスターよりも不均衡に多くのバグを見つけることがわかりました。 これは非常に重要な瞬間です。 ユーザーの行動をシミュレートするテスターの軍隊を雇う代わりに、実際にそれを使用するグーグルに製品を提供します。 それらから豊富なバグレポートを取得します。 最後に、 専用ユーザーによってテストされているベータリリースをリリースしています 。

テスト

テストを小、中、大の3つのグループに分けます。 いくつかの理由で、それらをユニット/統合/システムに分割しません。 まず、一元化されたテスト実行システムがあります。 このシステムに小さなテストを実行することを伝えると、システムは長続きしないことを理解し、それに応じて実行を計画できるようになります。 Googleのすべてのプロジェクトはこのシステムを使用しているため、プロジェクト間の時間を合理的に配分したいと考えています。 システムは、大きなテストの間に小さなテストを交互に挿入し、その結果、継続的に実行されます。

少しのテスト：

• ほとんど常に自動化
• 擬似環境（模擬/偽装環境）で実行する
• 1つの機能または1つのモジュールを確認する
• データ検証と例外チェックに焦点を当てる
• ミリ秒単位で実行
• 主に書かれたSWE

平均テスト：

• 通常自動化
• 擬似環境で実行する
• 関数間の相互作用を確認する
• データの相互運用性の機能的な問題に焦点を当てる
• 数秒で実行
• SETおよびSWEが書き込まれます

素晴らしいテスト：

• 自動または手動のいずれかです。
• 実際の環境で実行
• 最終的な機能がチェックされます。
• 数時間行うことができます
• 書き込みはTEおよびSETによって行われます

テストについてのもう少しの言葉

すべてのチェックの自動化に努めています。 マシンで結果を確認できる場合は、自動化します。 人間の評価の必要がない場合、このテストを自動化します。 何度か確認する必要がある場合は、自動化されます。 何かを偶然に委ねることができない場合、自動化します。 これらの条件が適用されない場合にのみ、開発者が手動でテストできるようにします。 ただし、テストを手動で実行する場合でも、jsアプリケーションを使用して記録します。 これにより、このようなテストを再現して再利用できます。 後でこのアプリケーションについて説明します。

コードの可読性もテストします。 C ++、phyton、java、およびjavaスクリプトの各行は、開発プロセス内で読みやすいかどうかがチェックされます。

エンジニアとテスターの両方が同じ環境を使用しています。 タスクに関係なく、サーバー上のデータセンターでも開発者のデスクトップでも、誰もが同じバージョンのLinuxを使用します。 エラーの再現には、環境の均一性が非常に重要です。 私たちにとって、ローカル=テスト=ステージング=本番です。 そうでない場合は、真剣に考えることをお勧めします。

ACC-10分間のテスト計画

私が最初にグーグルに来たとき、私はテスト計画の退屈な読書に従事していました。 各プロジェクトには、他とは異なる独自の計画がありました。 これらの計画には共通点が1つしかなく、時代遅れで現実を反映していませんでした。 これらの計画は書かれ、レビューされ、無視されました。 テスト計画はTEの責任の1つであり、これを改善する必要があることはわかっていました。 これが私がしたことです。 私は部屋に数人のエンジニアを集めて、彼らに1つのアプリケーションを与え、あなたは10分あると言って、テスト計画を立て、それらを残しました。 もちろん、私は10分後に戻り、「おい、冗談を言っていると思った。10分では完全な計画には不十分だから」と聞いた。 グーグルでは、マネージャーがいないにもかかわらず、責任と責任の理解があるので、一般的に彼らは私が指示したことをしなければならなかったと言わなければなりません。 私は彼らにそれを処理できると言いました、彼らにもっと一生懸命にさせてください。 それから彼は彼らに別のアプリケーションと新しい10分を与えました。 今回、彼らはいくつかの進歩を遂げました。 私は彼らに別のアプリケーションを再度与え、わずか10分かかりました。 これは1時間半続き、エンジニアの1人が何か価値のあることをするまで続きました。 その結果、この手法は方法論をもたらしました。 学んだことは次のとおりです。

• リストを支持して散文をあきらめる
• 気にするな販売
• 水を入れないでください、これはエッセイではありません
• これが再現可能でない場合は、忘れてください
• フローを作成し、一方を他方に流します
• テスターの考え方に同行する
• 出力はテストでなければなりません

この計画をACC（Attributes Components Capabilities）と呼び、そのような計画の準備を容易にするために、オープンソースアプリケーション（ ライブバージョンもあります）をリリースしました 。 これで、30分以内にGoogleアプリケーションのテストを行うことができます。 重要なシステム属性をリストすることは、おそらく最も長いプロセスです。 通常、開発者が最後に望むのはそれに参加することです。 メインリストを取得するために、アプリケーションの公式Webサイトを見ることができます。ほとんどの場合、すべてがすでにそこに書かれています。 開発者が関与するためにGoogleで使用するトリックを次に示します。 たとえば、ChromeOSのテスト計画を作成したとき、20分で私たちが知っていたすべての機能を説明しました。 304個のアイテムのリストがあります。 開発者のところに行き、「ChromeOSは非常に単純なので、実際にはテスト用に304の属性しかありません。」と言いました。 彼らは、これは不可能であり、システムは非常に複雑であり、非常に複雑であると即座にあいまいになりました。 開発者は物事を複雑にするのが大好きです。 彼らは自分のコードが世界で最も複雑であると考えるのが好きです。 したがって、彼らのコードが原始的であると言うなら、彼らはあなたが間違っていることを証明したいと思うでしょう。これはまさに私たちが必要としたものです。 彼らは2時間の会議をまとめました。これは、Googleの基準では、仕事から1週間人々を疎外することと同じです。 彼らは座って、このリストにさらに重要な属性を追加しました。その結果、リストは320ポイントになりました。 このトリックはうまく機能します。 属性の一部を作成し、開発者が関与します。これが機能しない場合は、それらなしでテストを開始します。 重要なものが徐々に差別化されます。 ブログで10分間の計画を立てる方法について詳しく読むことができます。

バイト記録と再生

私がお話ししたい2つ目のツールは、前述のBITEです。 BITEは、 オープンソースアプリケーションとしてもリリースされました。 ブラウザでアクションを記録し、この素材を再生できます。 このツールは、社内のドッグフードリリースのテスターであるすべてのグーグルが使用しています。 検証テストの作成に役立ちます。 詳細については、 ブログをご覧ください。

バイトバグファイリング

あなたが読んだテストの作成に関する本がいくつあるかは私には関係ありません。 さらに、私はこれらの本の著者でもあります。 実際のユーザーよりもテストのメリットが少ないと確信しています。 再作成する環境ではなく、実際の環境で動作します。 彼らはあなたが作ったものではなく、本当のデータを持っています。 彼らは、エミュレートするシナリオではなく、独自の作業シナリオを使用します。 あなたはユーザーであると主張するテスターです。 ユーザーはこのタイトルを主張せず、ユーザーです。 そのため、ユーザーをテスターに​​変えることにしました。 Googleマップについて考える場合、これは私が多くの時間を費やしたもう1つの製品です。 ユーザーだけが周囲の現実のデータを確実に検証できることを理解できます。 どうすればそのようなことを確認できますか？ 真剣に、これは文字通りグローバルタスクです。 この通りに住んでいる人だけが、地図に間違いがあることを認識することができます。 私たちはグーグルですが、テスターを雇ってすべての土地を再確認することはできません。 ユーザーを信頼し、ユーザーの知識に頼らなければなりません。 結果として、これは私たちよりも優れているため、これは良い考えです。 このユーティリティは現在開いていません。 エラーデータベースに直接接続されています。 マップをクリックすると、このユーティリティはdom構造のスナップショットを作成し、ブラウザ、オペレーティングシステム、つまりエラーを再現するために必要なすべての情報を収集します。

高品質のボット

最後に、Chromeブラウザのテストに使用する別のユーティリティについて説明します。 クロムのテストを初めて開始したとき、多くの手動チェックを行いました。 実際、それらは私には無意味でした。 「インターネットを壊さない」ことが重要でした。 Chromeが人気のあるサイトを正しく表示し続けることが重要でした。 私たちは、cnn、facebook、その他の人気のあるサービスをレンダリングしないブラウザをリリースしたくありませんでした。 もちろん、人気のある数百のサイトをダウンロードして、それらがブラウザのクラッシュを引き起こすかどうかを調べるテストを行うのは簡単です。 確かに、これは必要なものではありません。 実際、最も人気のある1万のサイトをチェックし、古いバージョンのブラウザーに見えるかどうか、Firefox、Safari、およびIEでどのように見えるかを確認します。 作成したアプリケーションはQuality Botsと呼ばれます。これについては、 ブログでも説明しました 。 アプリケーションは2つのことを行います。 DOMを比較し、ページ上のすべてのコントロールの場所を確認します。 もちろん、毎日広告があるサイトは異なって見えます。 それらがほぼ類似していることが重要です。 その場合、テストに合格したと見なされます。

エピローグ

詳細に興味がある人は、ジェームズのツイッターをフォローしたり、 プロをまとめたり、このトピックに関する記事が定期的に掲載されているブログを読むことができます。