グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？

グーグルは検索エンジンだけではなく、メールソフトのGmail、オフィス系ソフトのGoogle Apps、WebブラウザのChromeやOSのAndroidなど、さまざまな種類と規模のソフトウェアを開発しています。

それらはどのようにテストされ品質管理されているのでしょうか？ グーグルのブログGoogle Testing Blogに、Test Engineering DirectorのJames A Whittaker氏による「How Google Tests Software」がポストされ、その概要を伝えています。

3つのチームからなるEngineering Productivity

Whittaker氏はまず、グーグルにはテストの専門部隊はいないのだ、という組織構造の説明から始めます。

There isn't an actual testing organization at Google. Test exists within a Focus Area called Engineering Productivity.

グーグルには、実際にテストを行う組織というのはありません。テストは「Engineering Productivity」と呼ばれるフォーカスエリアの中にあります。

フォーカスエリアというのは、グーグルの中にある組織の分類のことのようで、Search、Apps、Ads、Moblie、OSなどの1つとしてEngineering Productivityがあるとのこと。このEngineering Productivityという組織はグーグル社内のエンジニアの生産性を向上させるのがミッションで、その中でもテストについては重要なものの1つだそうです。

そしてこの組織は、以下の3つチームで構成されていると説明されています。

プロダクトチーム
内部ツール、オープンソースにかかわらず、社内のすべてのエンジニアのためのツールを開発する。IDE、テスト管理ツール、自動テストツール、ビルドツール、ソース管理ツール、コードレビュースケジューラ、バグデータベースなど、エンジニアの生産性向上のためのあらゆるものを担当。

サービスチーム
社内の製品チームに、ツール、ドキュメント、テスト、リリース管理、トレーニングといったあらゆる専門的なサービスを提供する。その範囲は、信頼性、セキュリティ、国際化対応といった製品チームが直面する課題を含む。

エンベデッドエンジニア（Embedded engineers）
社内の製品チームの要請に応じてエンジニアを貸し出す。グーグルはエンジニアに対してときどきは担当製品を変更することを奨励しており、つねに製品に対する経験と同時に新鮮な視点を保てるようにしている。

この3つのチームからなるEngineering Productivityのメンバーは、Engineering Productivityのマネージャが上司（レポートライン）ではありますが、Search、Gmail、Chromeといったそれぞれの製品チームに所属しています。ミーティングも、ランチも、ボーナスの受け取りもその製品チームのメンバーとして扱われるとのこと。

テスターはデベロッパーがテストできるようにするのが仕事

このようにEngineering Productivityのメンバーのレポートラインと所属を分けることのメリットを、Whittaker氏は次のように書いています。ここにグーグルの品質管理の大事なポイントがあるようです。

This separation of project and reporting structures has its challenges. By far the biggest is that testers are an external resource. Product teams can't place too big a bet on them and must keep their quality house in order.

プロジェクトとレポートラインを分けることは1つのチャレンジだ。これまでは、テスターは（製品チームにとって）外部のリソースだった。製品チームにとってテストとはあまりに多くのリソースを必要とするため、それを適切に維持することができなかったのだ。

一般にテストは製品開発の最後の段階で行われることが多く、製品チーム／開発チームの中にテストチームを抱えても、テストフェーズ以外は手持ちぶさたになってしまうため、多くの開発組織ではテストチームは製品チーム／開発チームとは別に存在し、必要なときに登場してテストを行う、というケースがほとんどです。

ところがグーグルではEngineering Productivityに属する、テストのノウハウを持ち支援を行うエンジニアたちは、前述のように各製品チームに所属しています。

Yes, that's right: at Google it's the product teams that own quality, not testers. Every developer is expected to do their own testing. The job of the tester is to make sure they have the automation infrastructure and enabling processes that support this self reliance. Testers enable developers to test.

そう、グーグルではテストチームではなく、製品チームが自身で品質管理を負っている。各デベロッパは自身でテストすることを期待されている。テスターの仕事は、自動テストのインフラを確立することと、それによってデベロッパ自身がそれをプロセスの中で実行できるようにすること。テスターはデベロッパーがテストできるようにするのだ。

各製品チームは、Engineering Productivityのメンバーの支援を受けつつ、自分たちの責任でテストを行わなければならない、ということがグーグルのテストを行う際のポリシーのようです。

しかも各製品チームが自分たちの責任でテストを行うと同時に、社内の優れた開発ノウハウ、テストのノウハウ、ツールといったものがEngineering Productivityのレポートラインによって速やかに全社で共有できる利点もある、とWhittaker氏は書いています。

テストエンジニアはテストへの取り組みを促進する

Whittaker氏はさらに次の記事「How Google Tests Software - Part Two」で、エンジニアに与えられる3つの役割についても触れています。

Software Engineer（SWE）
これまでのエンジニアと同様に、顧客に提供するための製品のコードを書く役割。ドキュメント、データ構造、アーキテクチャなどもこの役割が担当する。と同時に、品質の責任も負う。

Softweare Engineer in Test（SET）
テストのしやすさ（Testability）にフォーカスした役割。デザインレビューをし、品質やリスクをチェック。コードをテストしやすいようにリファクタリングする。ユニットテストや、テストフレームワーク、自動テストも書く。

Test Engineer（TE） TEはSETとは逆の立場で、テストが最優先、開発は2番目と考える役割。ユーザーとして振る舞い、利用シナリオを考え、自動テストのスクリプトを書く。SWEやSETのテストへの取り組みを促進するようにし、結果を分かりやすく伝える。

エンジニアはこの3つの役割を受け持つとのこと。ここでもテストエンジニアの役割は、デベロッパーに対してテストを実行する環境や知識、アドバイスを提供することであることが繰り返し強調されています。

Whittaker氏によるグーグル社内のテストへの取り組みに付いての説明は、この先もまだ続くようですので、機会を見てまた紹介したいと思います。