以前はMicrosoftのアーキテクトを務め、現在はGoogleのテストエンジニアリングのディレクターであるJames Whittaker氏は“How to Break Software” シリーズで何冊かの著書がある。氏はGoogleがどのようにテストをしているかについて数回に渡って記事を書いた。Googleではテストは開発と共に行われ、テスターの数は比較的少ない。各製品は多くの人に触れられる前に一連の手段によって評価される。
Googleでの品質探求は普通の組織とは異なった道を経る。Googleは巨大なテスト部門を持っているわけではない。むしろ、テストはある程度は開発者の役割になる。氏によれば、
テストと開発は連動しています。コードを少し書いてビルドしてテスト。また少し書いてまたテスト。できれば、コードを書いているときか書く前にテストを計画します。テストは開発と別の活動ではなく開発の一部であり開発に包摂されています。品質はテストと同等のものではなありません。開発とテストをミキサーで混ぜ合わせこのふたつが分離できなくなったときに獲得できるのが品質です。
というのは、Googleは品質は検出することによって保証されるのではなく、“予防活動”によって保証されると考えているからだ。
品質は開発の課題です。テストの課題ではありません。開発にテストを組み込むという点で、私たちが作ったのはひとつの開発がバグだらけだった場合にはロールバックするというような強力な反復開発プロセスです。こうすることで多くの顧客の問題を未然に防ぐだけでなく、リコールが発生してしまうようなバグを防ぐために必要なテスターの数を低減できます。
Googleではテスターは一般的に知られているようなテストはせず、“開発者が確実に、テストするための自動化インフラを構築しテストを実行できることを保証する”のに専念する。こうすることで“品質は製品を良くすることに責任がある開発者の義務”になる。この品質についての考えを実践するため、Googleには3つのタイプのエンジニアがいる。氏によれば、
- SWE、すなわちソフトウエアエンジニアは従来の開発者の役割を担います。SWEは機能するコードを書いてユーザに提供します。設計書を作り、データ構造と全体のアーキテクチャを設計し、コードの記述とレビューに大部分の時間を費やします。テスト駆動設計、単体テスト、そして後の記事で書きますが、小テスト、中テスト、大テストの構築に参加するなど、大量のテストコードを書きます。SWEは書いたものであれ、修正したものであれ、変更したものであれ、触ったものすべての品質に責任を持ちます。
- SET、すなわちテスト時のソフトウエアエンジニアも開発者の役割ですが、彼らはテストの容易性に注力します。彼らは設計のレビューをしコードの品質とリスクを詳細に調べます。コードをリファクタリングしてテストしやすくします。SETは単体テストのフレームワークと自動化の仕組みを構築します。コードベースでは彼らはSWEのパートナーですが、新しい機能の実装や性能改善よりも品質の向上とテストの網羅性に関心を持ちます。
- TE、すなわちテストエンジニアはSETと真逆の役割を担います。テストを最優先にして開発を後回しにする役割です。Googleの多くのTEは自動化スクリプトやシナリオを動かすコード、ユーザーのまねをするコードを書くことに多くの時間を費やします。また、とりわけプロジェクトの後半でリリースへと押し進めるために、SWEとSETのテストを編成し、テスト結果を解釈して、テスト実行を指揮します。TEは製品の専門家であり、品質のアドバイザであり、リスク分析家です。
言い換えれば、SWEはソフトウエアの機能と品質に責任を持ち、SETはSWEが製品の機能をテストするのをサポートするコードを提供し、TEは素早くテストを行い、開発が気付いていない大きなバグを見つけるため二重にチェックし、ユーザーのシナリオに基づいたテストや性能テスト、セキュリティなどのテストを行う。
組織のレベルではGoogleはいくつかの分野に注力している。検索、広告、アプリ、モバイル、OSなどだ。このような分野のひとつにエンジニアリングプロダクティビティ(EP)がある。この分野は“縦横のエンジニアリングの規律”を持っているが、テストはその中でも一番力を入れられている。EPを構成するのは、
- 製品チーム – オープンソースの製品を含むGoogleのすべての製品のための生産性向上ツールの開発。例えば、コード分析やIDE、テストケース管理システム、テスト自動化ツール、ビルドシステム、コース管理システム、コードレビュースケジューラ、バグデータベース。
- サービスチーム – 信頼性やセキュリティ、国際化などを支援する。“ツール、文書化、テスト、リリース管理、トレーニング”などについて専門的意見を述べる。
- 同行エンジニアチーム –Google内のさまざまチームに借り出されるテスターチーム。何年もチームに同行してもいいが、“製品の知識と新鮮な着眼点を両立させ続ける”ためにチームを変更するように奨励されている。さまざまな領域の製品開発チームの中で活動するが、報告はEPにする。“テスターが情報を共有するためのフォーラムを提供し、テストについての優れたアイディアをEPが共有して、すべてのテスターが担当している製品に関係なく、最適な技術にアクセスできるようにする”ためだ。
このような方法でテストをすることでテスターの数を相対的に少なくできる。“一度に大量の機能をリリースすることがほとんどないからです。実際はこの反対が目的になってしまいます。コアの部分をビルドして可能な限り多くのユーザが使いやすい状態になったらその製品をリリースします。そして、フィードバッグをもらい次の反復を始めます。” と氏は言う。品質を保証するための他の要素は複数のチャンネルを利用することだ。氏はChromeを事例にして4つの異なるチャンネルを説明する。
- カナリアチャンネル – まだ日の目をみないコードのためのチャンネル
- 開発チャンネル – 開発者が使うチャンネル
- テストチャンネル – ベータ版のコードを準備するチャンネル
- ベータチャンネルまたはリリースチャンネル – Google内または一般に公開される製品を準備するチャンネル
リリース後にバグが見つかったら、テストを書いて各チャンネルでのビルド版を検証してそのバグが修正されていることを確認する。
これが、Googleが製品の品質を保証するためのプロセスと組織体制の概略だ。