Sat, 01 Jun
『テストから見えてくるグーグルのソフトウェア開発』は何であって何でないか
最近やっと “How Google Tests Software
これを買うべき人: テストを日常的に書いている人と、テストを書く習慣がない人
というのは、さすがに煽りすぎだと思う。テストを書く習慣がない人は
- そもそもあらゆるテストが無いなら『レガシーコード改善ガイド
』あたりから
- アプリケーションにテストが無いけど、フレームワークなどの土台部分に支援がある環境なら、あんまり自作しないで、まずはフレームワークを学ぶところから
- 自分がテストを書く習慣がないだけで、まわりは書いてるなら、まずはまわりを真似るところから
はじめるべきであって、その段階で本書に行くのは、ちょっと遠回りすぎる。
組織の話
目次
技術的な話、例えば、おなじみの Test Sizes (1.5. テストのタイプ、2.1. SET の生活) や、Protocol Buffers をつかったサービスの定義と C++ コード例 (2.1. SET の生活) もでてくるけど、見所は組織面の話だと思う。
例えば、Google は “Focus Area” (FA) というものに組織が分かれていて、Chrome, Google Toolbar あたりは Client の、Maps, Google Earth あたりは Geo の VP やディレクタにレポートする (という言葉づかいを外資の人々はするけど、ようするに上司ってことですね)。一方でテストまわりの役職の人々はプロダクトのチームには所属せず “Engineering Productivity” という別の Focus Area を持ち、プロダクトのチームに必要に応じてかりだされる。
これについて本書は
1つのチームの中で、シニアマネージャはプログラムマネジメントや開発出身のひとになりがちで、テスト系からは出てこない。リリースの追い込みでは、優先順位はしばしば機能の完成やそのほかやっつけておわらせる仕事が、品質より優先される。この種の組織構造は、テストを開発に従属したものにする傾向がある。
と説明する。私は、こういう観点で組織について考えたことがなかったので、なかなか新鮮だった。プロダクトチームに所属させないことには、他にも、テスタの数を低く保つこと、プロダクト間を移動することで良いアイデアを会社全体に素早く広めること、などの利点があるらしい。
こういった感じで、Software Enginner in Test (SET), Test Enginner (TE), Test Engineering Manager (TEM) についてそれぞれ一章がさかれ、役割の違いや意図について説明されている。
Google と歴史の話
職種について説明する際に、前提として Google そのものについての話がでてくることがある。また、インタビューを通じて語られる歴史の話も、野次馬的な楽しさがある。
Googler なんていうとプログラマ界のエリートで、自動テストなんて言われずとも書くようなイメージがあるけど、少なくとも過去はそうでもなかったらしい。それを改善するために、例えば “Test Certified” プログラムというのがあって、これは個々のチームのテストの改善について、明確で少しずつ実現できるような、必要な作業のリストを提供してくれる。
- レベル1: 継続的なビルドとカバレッジの計測をする。テストを Small, Medium, Large に分類する。成功したりしなかったりする (nondeterministic な) テストの認識。
- レベル2: テストが失敗していたらリリースしない。スモークテストが成功することを submit (というのは Perforce 感が…Git の人は push と思えば大体あってると思います) 前に要求する。…
- レベル3: すべての些細じゃない変更にはテストを要求する。…
- レベル4: submit 前のスモークテストの実行の自動化。スモークテストは30分以内で終了する。成功したりしなかったりするテスト無し。…
- レベル5: すべての些細じゃないバグ修正にテストを追加する。既存の解析ツールを積極的に使う。…
リストはところどころ省略しているので、全体は本を読んでください。このプログラムを作った人々は、参加してくれたチームに、ビルド結果を赤と緑であらわす光るオーブを配ったり、かの有名な Teting on the Toilet をはじめたりと、色々とがんばっている。
その後の話
SET のような「Computer Science のできるテストの職」というのは別に Google に限ったものではなく、たとえば Amazon だと Software Development Enginner in Test がそれにあたると思う。ただ「アメリカの人はそうやっているのかあ。うちもそういう職種が必要だなあ。」なんて考えていると、最後の章はちょっとはしごをはずす内容になっている。
というのもここでは、プロダクトとテストの分離が「問題」として取り扱われ、SET, TE は発展的に解消されていく、という見通しが語られるからだ。
これらのふたつの役割は、Google において分離しつつある。SET はどんどん開発者に近くなっているし、TE はその真逆の、ユーザーに近くなっている。
当然それなりに理由はある。SET についてはテスト (あるいは Enginnering Productivity) はプロダクトチームの中においても一級市民として取り扱うべき、というのが背景にあるようだ。
SET はテストしやすさ、信頼性、デバッグしやすさなどを機能として提供する。もし我々がこれらを機能として、UI や他のコンポーネントと同じように取り扱うのなら、SET はこれらの機能を担当する開発者以外の何者でもない。
TE については、Web によって実現した少数ユーザーへの配信や、変更の容易さから、実際のユーザーをもっとテストに参加させ、TE はそれを設計・整理・管理するような立場になっていくだろうとされている。
まとめ
『テストから見えてくるグーグルのソフトウェア開発
開発者テスト・自動テストについてだけなら、もっと色々良い本があるとは思うんですが (あんまり読んでません)、ソフトウェアテスト全体について、ひとつの大企業のなかでどんなことが行われているか、というのはあまり類書が無い (“How We Test Software at Microsoft®
