開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？

グーグルでTest Engineering Directorを務めるJames A Whittaker氏が書いたエントリを紹介した先日の記事「グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？」が非常に好評で、「続きがあれば読みたい」というコメントをいただいていました。

Whittaker氏がそのエントリの続き「How Google Tests Software - Part Threeを公開していますので、ご要望に応えて紹介することにしましょう。

品質は開発の問題であってテストの問題ではない

品質とはどのように実現するものなのか？ という問いに対して、Whittaker氏は次のように書いています。

The simple solution to this conundrum is to stop treating development and test as separate disciplines.
（略）
Quality is not equal to test; it is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other.

この難問に対するシンプルな答えは、開発とテストを分けて考えるのを止めることだ。（略）品質を確保することとは、テストを行うことと同じではない。それは開発とテストをそれぞれの区別が付かなくなるまで融合させていくことなのだ。

そして、開発とテストの融合こそ、グーグルのゴールであると。

At Google this is exactly our goal: to merge development and testing so that you cannot do one without the other.

その理由は、開発者がいちばんうまくテストをでき、バグのないコード書くインセンティブを持っているからだ。

Who better to do all that testing than the people doing the actual coding? Who better to find the bug than the person who wrote it? Who is more incentivized to avoid writing the bug in the first place? The reason Google can get by with so few dedicated testers is because developers own quality.

実際にコードを書いている人たち以上にうまくテストできる人がどこにいる？ コードを書いている人以上にうまくバグを見つける人は？ バグのないコードを書きたいと思っている人は？ グーグルがわずかな専門テスターだけで済んでいる理由は、デベロッパーが品質に責任を持っているからなのだ。

バグは発見するよりも作り込まないことが重要で、品質のためにテスターを多く投入するというのは解決にならないとWhittaker氏。

Quality is a development issue, not a testing issue. To the extent that we are able to embed testing practice inside development, we have created a process that is hyper incremental where mistakes can be rolled back if any one increment turns out to be too buggy.

品質とは開発の問題であって、テストの問題ではない。これを推し進めて、私たちは開発の中にテストを組み込んでいる。ハイパーインクリメンタルなプロセスを作り、だれかがバグを組み込んでしまったらそれ以前の状態にまでロールバックできるのだ。

グーグルが徹底して開発プロセスの中で品質を作り込んでいるようすがよく分かります。

テスト駆動開発と継続的インテグレーション

ここでこの記事を終えてしまうと、単に翻訳して紹介するだけになってしまって申し訳ないので、少しだけ追加を。

開発しながらテストする手法ですぐ思いつくのは「テスト駆動開発」（Test Driven Development、TDD）です。しかしこれは開発者ごとに受け持つユニットテストが中心になるでしょう。品質を作り込むのなら、開発途中でもつねに統合テストまで行いたくなるはず。そこで、開発中のユニットを頻繁に統合してテストを行う手法として知られているのが「継続的インテグレーション」（Continuous Integration）。

先日、開発者がオラクルによる拘束を嫌って「Hudson」から「Jenkins」へと名前を変えたことで知られる「Jenkins」は、その継続的インテグレーションのためのツールとしてよく知られています。開発者は日本人の川口耕介氏。以下は2008年10月に公開された、川口氏自身によるHudson（現Jenkins）とはなにかの紹介。勉強になります。