読書メモ/"How Google Tests Software", 「テストから見えてくるグーグルのソフトウェア開発」

• [ Prev ]
• [ Next ]
• [ 読書 ]

---

邦題：「テストから見えてくるグーグルのソフトウェア開発」

・テスト技術者、およびTDD(テスト駆動開発)やテストファーストに意欲的に取り組んでいるエンジニア向けに３行でまとめる。
1. グーグルですら適切で合理的なテストケースの作成やテスト計画、テストの自動化、そして開発者にテストコードを書かせるのに苦労している。昔も、今も、そしてこれからも。
2. だから、テストやその自動化には「正解」なんて無い。グーグルですらそんなの知らない。だからグーグルではテストに対して様々な実験や検証が日常的に行われ、そこからイノベーションが生まれる。
3. では何を軸とするか？それはひたすら、「テストにより製品に価値を追加する」こと。テスト計画、自動化、開発者へのテストコードの啓蒙、それら全ては製品の価値に従属し、会社の利益につながる。

これで本書を読みたくなった人は、以下の文章を読む必要はありません。さあ、今すぐ上のリンクをクリックして本書を購入しましょう！特に、TDDに一度は夢を見て→現場導入を試みて挫折と絶望、を味わった人におすすめです。

※なお、技術的な技法や管理手法についてはほとんど書かれてません。テストコードの書き方やインフラの構築方法、あるいはテスト工程の管理方法などは期待しないほうが良いです。そもそも組織文化を変えたい、とか、JavaScriptが多用されたWebアプリ、あるいはAndroidやChromeOSなどハードウェアやOSレイヤーと結びついたソフトウェアに対して、どのようなアプローチでテストに取り組んでいるか、という話が多いです。もちろん、グーグルのテストエンジニアはどういう仕事をしていて、どんな日常なのかも書かれてます。

---

時間に余裕のある方向けの読書感想文

この本を読むまでは、グーグルでのソフトウェア開発はテストファーストが当たり前で、テストコードとその自動実行環境が完備されたバラ色の開発プロセスだと思っていました。
しかしこの本を読むと、現実はそうではなく、2007年ごろは急成長に伴う痛みの一つとしてテスターが圧倒的に不足していて、テストの自動化について数年がかりで（そして今もなお）開発現場に浸透させる努力が延々と続けられている現場だったことが分かります。
グーグルのエンジニアは、平均的なITエンジニアよりはスキルやモチベーションが高い筈です。それでもなお、テストの自動化であるとかテストプロセスの改善は茨の道だった、ということです。

自分は本書を読んで、絶望と希望の２種類の感情を抱きました。
まず絶望についてですが、本書を読むと、自分のようにテストコードを書くことを重視している人間にとってはある種の絶望を感じるかもしれません。自分が感じたことは、「グーグルですらこれほどの苦労をしている。それより遥かにリソースやスキルが制限されたシステム開発現場では、テストの自動化は絶望的なまでに難易度が高いのでは？」という諦めでした。
次に希望についてです。これには何種類か、前向きになれるポイントがありました。
一つ目は、諦めを裏返しにしたものですが、「グーグルですらこれほど苦労しているのだから、自分たちが苦労していても何ら不思議ではなかったのだ。」という、無力感に対する安心です。テストの自動化は開発組織や企業の文化に密接に影響します。そのため、規模が大きくなればなるほど、個人だけではどうにも出来ない無力感を感じることがあります。しかしそれは個人の力量が不足しているわけではなく、もともとどんなスーパーマンでも個人だけではどうにも出来ない性質のものなので、自分に対して無力感を感じる必要はない、という安心感が得られます。
二つ目はテストとその自動化について、正解は無い、ということです。テストコードはどう書くのが正解なのか？単体テストフレームワークは何を使うのが正解なのか？どこまでの規模のテストを自動化すれば正解なのか？どこまでのテストケースを自動化するのが正解なのか？テストコードの作成を現場に導入する方法は何が正解なのか？本書の中ではグーグルのテストエンジニアへのインタビューが多数掲載されていますが、その中で一貫して通奏低音として流れているのが、「それらに正解は無い」ということです。グーグルではテスト規模に応じてSテスト/Mテスト/Lテストという区分が導入されていて、平均的なそれらの割合もありますが、それはグーグルが自分たちのプロジェクトやその性質に応じて変化させています。自動化をどこまで導入するのかも、プロジェクトによって大分異なっているようです。グーグルでは何かの正解を盲目的にエンジニアリングプロセスに組み込んでいるわけではなく、自分たちで試してみて、自分たちにとってより良いものを使っています。
ではその時の「より良いもの」の指標とは何か？それが最後に感じた希望の三つ目、「テストは製品に価値を追加するものである」という大きなテーマです。
本書で登場する人たちは誰一人として、テストとその自動化を単なる品質問題としては扱っていません。テストは第一に、製品に価値を追加するものである、という大きな目的意識を共有していて、それがテストの自動化であったり、テストファースト文化の導入であったり、もろもろのテスト技術のイノベーションへと繋がっています。それは単にテストそれ自体の効率化のためではなく、その製品によりスピーディに価値を追加する（機能の追加、パフォーマンスの改善、そして開発効率の改善、もちろん品質向上も）ためです。したがって、テスターは「テストを仕事としている」のではなく、「製品を開発している」というスタンスで仕事をすることを要求されます。そしてそのための資源は（たとえグーグルであっても）有限であるため、何を自動化するか、どのようにテストを計画するか、何がパフォーマンスや開発効率のボトルネックになっていて、その中で最も重要なものは何か、ということを徹底的に考えぬいて、自ら検証し、その結果としてイノベーションが起きる仕掛けになっているようです。

自分はTDDを学びましたので、テストの自動化についてはどちらかと言うと「エンジニアの不安を消し、設計を洗練させる」という視点で捉えていました。しかしグーグルは違うらしく、テストの自動化はもとよりテストのプランニングも含めて、それがどう製品の価値に結びつくのか？という視点で全社的に取り組まれています。ここに、開発者自身がテストコードを書くという強力な理由付けが発生します。テストが製品の価値を強化するのであれば、開発者自身が、自分が作成したコードに対してテストコードも作成する動機が生まれます。自動化されたテストコードが、製品の価値に結びつくからです。さらに、テストの自動化を推し進めるためのインフラやテストコード作成のノウハウ、さらに手動テストケースも含めたテスト計画やテストケースの作成などテストに関わるもろもろのエンジニアリングが「製品開発」の一部として評価されるようになります。

では、絶望と希望があるとして、それらは自分たちの開発現場にどれくらい活用できるものなのでしょうか？
それについては、一歩引いて考える必要がありそうです。なぜなら、本書はグーグルの話だからです。扱っている製品の規模や複雑さ、それに取り組むエンジニアの数とスキルとモチベーション、どれもが桁違いです。そのような環境での取り組みを、そのまま今の現場に持ち込めるはずがありません。グーグルですら、今の時点でのやり方に対してすでにいくつか疑問を感じ始めており、新しい取り組みが必要になりつつあると認識しているようです。
やはりそこにも「正解は無く」、軸に据えるべきは「製品の価値」だと思います。あくまでも私見ですが、現状のTDDの啓蒙活動はあまりにも開発者自身のメンタル的な部分にフォーカスされすぎており、組織文化の変革やそのキーパーソンとなる経営層への訴求力が弱いと感じています。もちろんTDDが品質保証にフォーカスされないよう、あえて開発者の不安を無くすためであるとか設計の洗練などに注目させているという事情はあると思います。しかし、それにより開発者がTDDに取り組むとしても、そのためのコストを組織として負担し、組織文化としてTDDを定着させる動機付けが弱いままです。
TDDや単体テストコードはあくまでも技法の一つであり、大きな枠では「テストの自動化」というそれ自体が難易度が高い開発テーマです。それに取り組むのは何故か？それに「製品への価値」、つまり「お客様への価値提供」という目的を大前提として据えて、初めて経営層に訴える力が備わり、組織文化の変革やイノベーションにつながっていくのではないか。本書を読んで、そのように強く感じました。

一旦安定領域に遷移した開発プロセスや組織文化は、高速道路を時速120kmオーバーで爆走しているダンプカーのようなものだと感じています。単に開発者個人の自己満足のためのTDDでは、巨大な慣性を持ったダンプカーに影響を与えるには力不足です。ダンプカーのエンジンは製品であり、そのユーザです。視点と目的をそこに移すことで、ようやくダンプカーの運転席に座ることが出来るのだと思いました。

以下、強く印象に残った文章の引用集

まえがき（アルベルト・サヴォイアより）
9p:
「
毎週金曜午後のビアパーティー（〜）では、テストの普及に弾みをつけようとして、私はテストを書いたデベロッパーたちにテスト賞を提供していた。
〜
残念ながら、ご褒美は機能しなかった。デベロッパーたちは、十分なテストをするには、テスト対象のコードの１行にたいして、２，３行の単体テストコードを書かねばならず、それらテストコードも機能コード自体と同じくらいのメンテナンスが必要で、同じくらいの確率でバグが含まれているということを認識していたのだ。そして、誰も驚きはしないことだが、デベロッパーの単体テストは十分ではないことが明らかになった。
」
→グーグルですらこうなのです。そして、グーグルのエンジニアが書いたテストコードですら、やはりテストとしては十分ではなかったようです。

まえがき（パトリック・コープランドより）
17p:
（ちょうどWebの世界全体がYouTubeなど動的な世界に遷移しつつあった時に）
「私達には、これらのアプリケーションを手動で適切にテストする能力はなかった。まして自動化は無理だった。」
→グーグルですらこれら動的なWebアプリのテストに尋常でない難しさを感じていたようです。

第１章　グーグルのソフトウェアテストの世界へようこそ

41p:
（グーグルでのテストの種類の話で）
「
グーグルでは、形態よりも規模を強調するために、コード、統合、システムテストという区別をせず、Sテスト、Mテスト、Lテストという表現を使う。
」

42p:
「
Sテストは、完全なフェイク環境でコードの1単位をテストする。
Mテストは、フェイク環境または実環境で複数の相互作用するコードをテストする。
Lテストは、フェイクではない実際の人員により実際の本番環境で任意の個数のコード単位の塊をテストする。
」

→これはかなり分かりやすいと思いました。どのレベルで、他との結合をどう処理するテストなのかというのが分かりやすいです。グーグルのエンジニアは多様なバックグラウンドを有するため、このようにグーグル独自のテストの区分を開発したことでコミニュケーションが大分改善されたようです。

第２章　SET(ソフトウェアエンジニアインテスト)

グーグルではSWE(ソフトウェアエンジニア)の他に、テストに関わるエンジニア職種としてSET, TE, TEMという職種があるようです。第２章ではSETについて紹介されています。

56p:
「
SETの面接では、「コーディングバー」はSWEの採用とほぼ同じで、さらにSET候補者は自分で書いたコードのテスト方法を知っていなければならない。SETは、テスト関連の問にも答えられなければならない。
想像されるように、SETは難しい職務であり、グーグルでSETが比較的少数なのは、グーグルが生産性を上げるための魔法の公式を編み出したからではなく、SETのスキルセットを持つ人がなかなかみつからないという現実にエンジニアリングの実践を適応させた結果だからかもしれない。
」

65p:
「
SETは、早い段階で統合テストを実行できるようにするために、各コンポーネントが必要とする依存ライブラリのモックやフェイクを作る。
」

「1つのマスターテストスイートですべてをエンドツーエンドで自動化しようという設計は、一般に誤りだ。
〜
自動化の内容が大きければ大きいほど、システムの発展とともにメンテナンスは大変になり、問題を起こしやすくなる。」

「エンドツーエンドの自動化にこだわりすぎると、テストは特定の設計に縛り付けられる。」

84p:
「
テスト自動化は、個別のテストプログラムを書くことよりもずっと奥が深い。〜テスト自動化は、実際にはそれだけで１つのソフトウェア開発の仕事だ。
」
「テストコードが役立つのは、開発を加速するような形で実行できる場合だけであって、開発がスローダウンするのでは意味がない。」

→グーグルでは、テストコードの開発が、製品コードの開発と同じレベルで開発プロセスやその哲学に組み込まれているようです。また、そのような啓蒙活動も継続されているようです。

96p:
「グーグルのテスト実行システムのメンテナーは、テスト実行環境をかなり網羅的にドキュメント化している。彼らのドキュメントはグーグルの「テストエンサイクロペディア」と呼ばれており、実行時のテストが使えるリソースは何かについて最終的な解答を与えてくれる。」

→実際の機能開発者がテストコードを書くときに陥りやすい罠やトラブルをきめ細かくサポートしてインフラに組み込むだけの労力が払われているのもグーグルならではでしょうか。もちろんその大前提として、それらの成果物が「製品の価値」に一役買っていることが重要だと思いました。

97p:
「グーグルのスピードと規模のもとでのテスト」
→細かい文章は載せませんが、グーグルでの継続的ビルドとテスト実行についてグーグル「ならでは」な点が紹介されています。グーグルの規模とスピードになると継続的ビルド・テストを単純に回しているとあっという間にキューが一杯になってしまい、さらに社内ライブラリの変更が入ると依存する製品コードのテストにも影響が出ます。そこで、独自にライブラリや製品の依存関係を計算し、ビルドキューを最適化するような仕組みが構築されているようです。こうしたエンジニアリング作業が認められ、実行されるのも、規模の問題としてそうした改善が確実に「製品の価値」に貢献しているからでしょう。

106p:
「2.2.1 テストサーティファイドプログラム創設者へのインタビュー」
→文章は載せませんが、拡大しつつあった当時のグーグルで、開発文化にテストを組み込み、開発者にテストコードも書いてもらう文化を浸透させ、いまも浸透させ続けているためにどんな試行錯誤が行われたか、行われているか、が紹介されています。組織文化を変えるためにどれほどの労力が注ぎ込まれたかが伺えます。

114p:
「グーグルでのさまざまな取組は、何週間、何四半期という単位で終わっていきます。ところが、テストサーティファイドはもう５年近くにもなりますが、近いうちに終わる気配はありません。」
→グーグルですら、優秀で士気の高い技術者を平均よりも圧倒的に質も高く量もあるグーグルですら、テスト文化を開発者に根付かせるのに５年かかり、しかも今も取り組んでいる現実が書かれています。

121p:
ここは「2.3 SETの面接」で、実際のコーディングでSETの候補者はこんなことを考える、というのが提示されています。
自分としてはわりとSETの候補者の考え方に近いな、と感じました。手を動かす前にアレコレ考えこんでしまうんですよね・・・。

第３章　TE(テストエンジニア)

3.2.1 テストプランの立案

ACC(Attributes, Components, Capability)という3軸からの視点で簡潔にテストプランをまとめる手法が紹介されています。
145p:
「テストに直接結びつかないテストプランは、時間の無駄だ。」
→グーグルの製品はリリースサイクルも早いため、初期に頑張って緻密なテストプランを組み立ててもあっという間に陳腐化してしまい忘れ去られてしまいます。グーグルですらリソースは有限なので、その中で合理的なテストプランの組み立て方をグーグルのテストエンジニアは考え、試行し、編み出したのがACCだそうです。ACCという3軸でシンプルに組み立てることで、余分なものが無い、本当に有用なものだけを組み込んだテストプランを必要最低限で作り、製品とともに歩んでいくためのノウハウが記述されています。

173p:
ジェームズ・ウィテカー「10分間テストプラン」
→面白い取り組みで、わざとその作業にかけられる時間をありえないほど低く見積もることで、余計なモノを省いた本当に本質的な作業だけに集中し、80%の完成度に短時間で持ち込む手法のようです。テストプランに限らず、他でも応用が効く面白い取り組みだと感じました。もちろん、「80%の完成度で十分合理的である」場合が前提となるでしょう。グーグルのスピードであれば、時間をかけて100%を目指すよりは限られた時間で80%の価値を届けるほうが優先されるようです。（さすがに銀行システムとか軍事システムだとそうは行かないと思います）

175p:
（リスク分析は行うが過度に複雑にはしておらず）「数字が１つぽつんとあってもほとんど何の意味もないので、実際の数字や数学にはあまり労力を注がない。単純に、AはBよりリスキーだということがわかっていれば、十分な場合が多い。」
→分析に時間をかけてリスクの絶対値を取る必要があるわけではなく、たくさんあるリスクの中でどれを優先すべきか、その目安となる相対値がある程度わかればよい、というスタンスのようです。恐らく、リスク分析それ自体を目的とするのではなく、あくまでもリーズナブルに製品に価値を追加し、ユーザに届けるという視点での「切り捨て」なのだと感じました。

グーグル独自のアイデア、っぽい印象も受けますが、ソフトウェアテストの世界では「リスクベーステスト」という考え方で立派に議論されているアプローチのようです。ソースは覚えてませんが、近年では銀行システムですら、テストカバレッジ100%を目指すのはもうコスト的に無理になってきて、クリティカルでない分野から徐々にリスクベーステストを取り入れているとかいう話を最近、どこかで目にした覚えがありました。

参考：

• リスク・ベース・テストの効果と限界
  • http://www.aerith.net/design/risk-base-test-j.html
• 基礎から学ぶソフトウエア・テスト - 基礎から学ぶソフトウエア・テスト（5）：ITpro
  • http://itpro.nikkeibp.co.jp/article/COLUMN/20060605/239986/
• リスクベーステストを考える: ソフトウェアさかば
  • http://sakaba.cocolog-nifty.com/sakaba/2010/09/post-b8e5.html

上記の参考リンクでは、リスクベーステストのデメリットとしてテストケースの漏れが指摘されていますが、本書中でもグーグルのテストエンジニアは、全体的にテストケースの漏れをユーザから指摘された経験があり、グーグルのエンジニアたちを持ってしてもすべてのテストケースはカバーできず、それゆえに漏れも生じてしまうのが現状のようです。

213p:
「メンテナンスモードの実例：グーグルデスクトップ」
→メンテナンスモードにする、だからこそ、慎重にテストを準備しておいて、メンテナンスモード以降での作業に割り当てる人員を少なくしておく、という話です。
グーグルらしいのは、そのためにPython + ctypesを駆使して新しいテスト用のインフラを構築し、さらに古いテストケースを洗い出して再構築し、カバレッジを維持しつつ、メンテナンスモードに入った製品として十分合理的なコストでテストを回せるように「開発」した、という点でしょうか。
こうした取り組みは単にメンテナンスモード以降の開発コストを押し下げるだけでなく、それで得られたディープなノウハウを水平展開することで十分お釣りが来ることを文化として理解していないと難しそうです。
このような省力化により余剰となったリソースをより重点的に取り組む分野に投入できる、つまり「製品の価値」を追加することが出来る、という大前提があるからこそ、こうした取り組みが評価されるのだと感じました。

237p:
「特異点：ボットの原点」ジェーソン・アーボン
→Chromeのレンダリング機能のリグレッションテスト用に構築された初期の"Bot"では、擬陽性が多すぎてほとんど意味をなさなくなっていたようです。
そこで、判定方法の改善にチャレンジして新しいアプローチを試みるのですが、グーグルらしいというところは実際に手を動かしてデモしてみせて、懐疑的な意見が出たら、あくまでも参考として本当はどうなのか更に実験を推し進め、結論まで持ち込んでいく点でしょうか。
頭で考えて議論するだけでなく、ホンモノのデータで検証していくところはなんというか、エンジニアというよりは科学者・研究者な感じを受けました。
何よりもそうした、（多分それなりの確率で）失敗に終わる作業について、無駄だから止めるのではなく、積極的に推奨して新しい芽を探していこうとするグーグルの体力と人材プールに圧倒されます。
同時に、それだけの体力と人材がそろっているグーグルですら、エンドツーエンドのテストであったりブラウザを使った複雑なテストの全てを完璧に自動化できているわけではない、というのも注目に値します。

255p:
「BITE with RPFの起源」ジェーソン・アーボン
→Chrome OS とも絡めたBITEとRPMの起源のお話です。Chrome OSという特殊性からこれまでのテスト・ツールをうまく活用できないため、新しいツールを作る必要があり、RPFが生まれたようです。
製品の機能だけではなく、テストに対するこうしたエンジニアリングが推奨され、実際にそれで時間をかけて成果も出ていて、しかもOSSで公にするのがグーグルのすごいところです。もちろんこうしたエンジニアリングが確実に「製品の価値」につながることが共有されているからこそ、でしょうか。

271p:
「テストのイノベーションと実験」ジェーソン・アーボン
→テストに関わるエンジニアリングについて、グーグルらしさがよく現れているエピソードです。
ジェームズ・ウィテカーの講演とアイデアに触発されたエンジニアが、日常の仕事をストップして（これが許されてしまうのがスゴイ）、ノリでうわーっと実装してみて、デモを見せて、「イケる！」と思ったら幹部に「こっちの仕事やるから上司変えるね(・ω<)」とメール一本、それで「オッケー」となるのがグーグル。

273p:
「アイデアを共有するという企業文化（ボトムアップの実験を支援する）と組織の柔軟性によって、テストイノベーションの豊穣な世界が築き上げられた。価値のあるものができるかどうかは、作って実際のエンジニアリング問題で試してみなければ決してわからない。」
→これが、グーグル「らしさ」なんでしょうか。

285p:
「3.4 YouTubeのTE、アップル・チャウへのインタビュー」

287p:
「ツールも違います。一般に、グーグルでは市販ツールを使いません。グーグルの文化では、ツールは非常に高く評価されています。そして、20%ルールがありますから、誰もがグーグルの社内ツールセットに貢献する時間を作ることができます。」
→もう20%って「自由な時間」ではなくて、立派な「R&Dとして全社的に最初から業務時間として組み込まれたプロジェクト」だよね、と感じました。

287p:
「自動化しにくいソフトウェア機能は、他社と同じようにテストしにくいとかうまくいかないといったことがありますね。
〜
完璧な会社はありませんし、完璧な製品を作る会社もありません。」
→そう、グーグルですらそうなのだ、と感じました。

第４章　TEM(テストエンジニアリングマネージャー)

301p:
「4.3 インパクト」
→テストは重要視されていますが、だからといって「聖域」扱いはされていないようです。機能コードと同様に、生産性を上げて開発を革新的にスピードアップして顧客に素早く価値を届けるための、立派なエンジニアリングであり、それゆえに漫然とテストしてバグを潰すだけでなく、開発や製品全体に良い影響を及ぼすようなクリエイティビティが要求されるようです。
そして、テストやその自動化という領域でそれを実現するには単に機能コードを書くだけでなくその効率的で適切なテストコードを書ける必要があり、さらに製品全体の隅々まで仕様を把握するという非常に難易度が高いエンジニアリングであり、それゆえに(グーグルですら)人員も限られているようです。

304p:
「4.4 Gmailチームのアンキット・メータへのインタビュー」

306p:
「〜しかし、多くのコードが書き換えられ、十分スピーディーに修正できなかった週がありました。
プロセス全体がボロボロで、Gmailの変更に弾力的についていけなかったのです。これは、究極のインパクトが小さい割に労力を食いつぶし過ぎるものに過度に投資していたということです。」
→面白いのは、そこからこのTEは、Gmailで問題となっているのは遅延であり、それを解決することでチームからの尊敬を得て良好な関係を築けると考え、スペックの古いマシンをあつめて数ヶ月に及ぶ負荷テストを実施して問題をあぶり出し、最大の問題となっていた遅延関連のリグレッションテストを数時間のうちに見つけられるような体制を整えたところです。
このように、仮定を作って実際に検証するというエンジニアリング行為を通じて、テストが製品開発に対して良好な影響を及ぼしているのがグーグルのテストプロセスの特徴のようです。

308p:
「たとえば5つの課題に取り組んでいて5つすべてについて80%の力しか注ぎ込めていない場合には、1歩下がって優先順位をつけます。
そして課題を2, 3個に絞込み、100%の力を注ぎ込みます。」
→グーグルであってもリソースは有限であるため、本書中では、TEやTEMなど上級職になるにつれ、インタビュー中ではこのような仕事の優先順位付けやリソース配分への話が増えます。

310p:
→「Gmailで得られた教訓のなかで、新しい製品でもっとも役に立つと感じているのはどういうことでしょうか？」
〜
「
・アプリケーション自体と同じ言語でテストを書け。
・機能を書いているデベロッパーに、責任をもってその機能のテストが実行されるようにさせよ。
・シームレスにテストが書けるようなインフラストラクチャに力を注げ。テストを省略するよりも書いたほうが簡単だというようにしなければならない。
・ユースケースの20%が利用の80%を占める（小差はあるが）。その20%だけを自動化し、ほかのものには手を付けるな。その他は手動テストパスに残しておけばよい。
〜
・イノベーションはグーグルのDNAの一部だ。テストチームは、重要な問題を見分けてイノベーティブなソリューションを考えだし、イノベーターと目されるようにしなければならない。
」

「新しいプロジェクトで若いTEやSETが陥りがちな罠で何か気づいたことはありませんか？」
「はい、彼らは背伸びをします。彼らは、テストの目的やテストプロセス全体の中でのテストの意味などをきちんと考えずに、大量のテストを書いてしまいます。
彼らは、テストを書くたびに、そのメンテナンス契約を結んでいるということに気づかないことが多いのです。テストはデベロッパーの仕事であって、自分たちはデベロッパーのワークフローにテストを入れることに全力を集中するのだということを、SETはいつも忘れないようにしなければなりません。
」

→これがグーグルでのテストエンジニア像のようです。

312p:
「〜Gmailのために大きな利益をもたらしたテストの大きな達成はありましたか？」
「JavaScriptの自動化です、私たちはGmail自体に自動化サーブレットを焼き込みました。それにより、デベロッパーたちはフロントエンドと同じ言語でエンドツーエンドテストを書けるようになりました。
〜
もう１つはロードテストです。
〜
そして、数ヶ月をかけて代表的なユーザーモデルを構築するために本番システムの利用状況を分析しました。
〜
最後に、バグの検出ではなく、バグの予防に力を入れたことが会社に大きな利益をもたらしました。
」

→単にテストのために数ヶ月かけて調査や分析を行うのではなく、それが製品の価値に結びつき、会社の利益につながる、という視点で行動しているのが注目です。

4.5 AndroidのTEM、ハン・ダンへのインタビュー

Androidは、外部開発者からのコントリビュートも多いのが特徴です。機能の変化も激しいため、Androidのテスト現場では自動化に対するスタンスであるとか、テストへの考え方が他と異なる点が多いようです。

316p:
「新任のテストマネージャーに忠告するなら、言いたいのはこれです。自分たちがしているすべてのことを通じて価値を追加せよ、そして、価値追加のプロセスを反復可能にせよ、ということです。」

317p:
「私は自動化には懐疑的になってきているんですよ。テスターは自動化の大きなビジョンに情熱を傾け、自動化の作成に何ヶ月もかけますが、結局製品かプラットフォームが変わって、してきたすべてのことが否定されてしまいます。
時間の試練に耐えられない自動化を書く以上にひどい資源の無駄遣いはありません。私の考えでは、自動化はすぐに書けてすぐに実行でき、非常に限定的な問題を解決するものでなければなりません。
〜
単純に指定、範囲を限定し、何よりもまず、価値を追加するものにしなければなりません。
」
→とはいえ、自動化を否定しているわけではなく、自動化が効果的である部分については活用している話もありました。要は、Androidというプロジェクトの特性として、自動化の比重が他と違う、ということでしょう。

319p:
「デベロッパーにはどんなことを要求するのですか？」
→「すべてのコード行に先立ってテストが作られており、テストに先立って仕様が作られているというお伽話の世界があるようですね。
〜
しかし、現実的には、存在するシステムのなかで仕事の方法を見つけなければなりません。仕様を求めても、仕事の方法は得られないのです。
〜
私は、1日のCLの数が数百という世界に住んでいます。そう、「１日の」と言ったのです。
〜
泣き言を言ったり要求していたりする時間はありません。ひたすら価値を生み出すしかないのです。」

→実際半年や1年のスパンで大量の機能追加が行われているため、おそらくAndroidにおいては自動化テストがうまく効果を発揮できない状況と思われます。さらにGoogleだけでなくOSSとして外部からのコミットもあるため、「１日の」CLが数百という数になるのでしょう。そうなってくると、Google社内だけで完結するテスト自動化の貢献がうまくはまらなくなり、自動化の枠を超えた手法が求められているのかもしれません。

4.6 ChromeのTEM、ジョエル・ハイノスキーへのインタビュー

325p:
「Chromeは、ブラウザーを起動し、URLに移動し、ブラウザーの状態、タブやウインドウの情報を問い合わせられる自動化プロキシと呼ばれるAPIを持っています。
私たちはこれにPythonインターフェイスを付け、Pythonスクリプトでブラウザーを駆動できるようにしています(〜)。〜そして、私たちはデベロッパーとテスターが同じように参加して書いたPyAutoという大規模なテストライブラリを作り上げました。
」
→WebDriverにも使われているのかな？しかし、やはりこのようなエンジニアリングを組み込むことが「価値」につながる、という文化が重要でしょう。

327p:(Chrome OSのテストについて)
「もともとLinuxカーネルをテストするために設計されたAutotestというオープンソースのテストツールがありますけれども、実際のChromeOSハードウェアで包括的な自動テストスイートを動かすために、このAutotestを改造して使っています。
〜
また、当然のことですが、Chrome OS上で動作するChromeブラウザーを使った自動化のそうさには、PyAutoが多用されています。
」
→PyAuto、面白そう。

4.11 エンジニアリングマネージャーのブラッド・グリーンへのインタビュー
353p:
「あなたのチームはデベロッパーテストのための指標に関して多くの仕事をしています。どんな指標が効果的ですか？」
→
「私はこの分野でもう４年も失敗してきていますので、色々なことを学びました。なぜ失敗と言っているかというと、私たちはコードやテストの品質を測れて、チームが絶対的なガイドとして利用できるような魔法の指標を見つけようとして膨大な労力を注ぎ込んできましたが、大切なのはコンテキストなので、指標を一般化するのは難しいのです。
〜
役に立つ計測値はありますが、テストの実装には微妙なニュアンスがあり、アプリケーションコード自体と同じくらい技の部分があるのです。
〜
ここから万だのは、テストでは、コンピュータ科学的な側面よりもソーシャルな側面の方がずっと難しいということです。よいテストが必要なことは誰でも知っていますが、私たちの大半にとって、チームにテスト作成を実践させるのは至難の業です。
」
→グーグルのエンジニアが4年間も試みて、失敗している、という事実は注目です。さらに、ソーシャルな側面が難しい、という点も注目です。

4.12 ジェームズ・ウィテカーへのインタビュー

361p:
「不足は最適化を導きます。」
→グーグルですら、テスターが足りていなかった。だがそれこそが、テストとその自動化の最適化を前進させる原動力となったのかも。人手不足ではあるが、それでも状況を前進させるだけの情熱とスキルを持つエンジニアが居たことも良かったのだと思います。

「入社した時、パトリック・コープランドが２つのアドバイスをくれました。第１は、ただ学ぶだけのために少し時間を割けということです。
〜最初の数ヶ月は、パトリックが教えてくれた通りのことをしました。話すのではなく聞け、試すのではなく尋ねよといったことです。
」
「第２のアドバイスは〜基本的にこういうことを言ったのです。「ねえ君、君がグーグル社外で評価されていることは私も知っている。でも社内では、まだ君は何も達成したわけではないんだよ」。
〜
歩きまわって考えを変えさせようとしてもグーグルでは出世できません。
」
→グーグルだから、とかではなく、異なる企業・異なる文化の中に入っていく時のポイントかも。

第５章 グーグルのソフトウェアテストの未来

371p:
「テストの価値は、成果物ではなく、テストという活動自体にある。
〜
テストケース、テストプラン、バグレポート、いずれもソースコードより重要なものはない。
〜
テストのすべての成果物は、ソースコード、そして製品にどのくらいのインパクトを与えられたかによって価値が決まる。」
→テストはそれ自体が目的なるわけではなく、製品の価値に従属する、という意識が強く感じられます。

「製品をリリースしたら、誤りを見つけることに貪欲なテストプロセスに見過ごされた問題がユーザーに見つけられてしまうというようなことがどれだけ頻繁に起きているだろうか。
答えは、ほとんどいつもだ。」
→グーグルですらこのような状況で、だからこそ、次の取り組みを試しつつあるようです。

本書中で登場した主なOSSプロダクト

• bite-project - Browser Integrated Testing Environment - Google Project Hosting
  • https://code.google.com/p/bite-project/
• PyAuto: Python Interface to Automation - The Chromium Projects
  • http://zoomq.qiniudn.com/ZQScrapBook/ZqFLOSS/data/20120706150852/
    • （chromiumのサイトからは削除されたらしく、これはバックアップサイト？）
• Manual Setup - The Chromium Projects
  • http://www.chromium.org/developers/chrome-endure-endurance-testing-framework/setting-up-chrome-endure/manual-setup
    • chromiumのサイト中では手動セットアップのドキュメント中で触れられているのみ？
• Autotest - Fully automated testing under linux
  • http://autotest.github.io/

参考記事（外部）

日本でのTDD普及活動や、マイクロソフトでのテストプロセスの記事が見つかったので参考としてメモ。

• 「愛せないコードを書くには人生はあまりにも短い」というタイトルで TDD について講演させていただきました #TddAdventJp #devlove2012 - t-wadaの日記
  • http://d.hatena.ne.jp/t-wada/20121217/develove2012_tdd
• 軽量なテスト駆動開発を目指して #TddAdventJp - やさしいデスマーチ
  • http://d.hatena.ne.jp/shuji_w6e/20121215/1355590710
• 「自動受け入れテスト」を考えてみる - 日々常々
  • http://d.hatena.ne.jp/irof/20130507/p1
• 晴読雨読＠エンジニアライフ: 実践テスト駆動開発――テストに導かれてオブジェクト指向ソフトウェアを育てる
  • http://el.jibun.atmarkit.co.jp/bookshelf/2012/11/post-a409.html
• テスト駆動開発の進化 - Digital Romanticism
  • http://d.hatena.ne.jp/digitalsoul/20120920/1348104079
• マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか？」 JaSST'12 Tokyo － Publickey
  • http://www.publickey1.jp/blog/12/_jasst12_tokyo.html
• マイクロソフトでは「開発プロセスのすべてにテスターが関与している」 JaSST'12 Tokyo － Publickey
  • http://www.publickey1.jp/blog/12/_jasst12_tokyo_1.html

グーグル社員ではない私たちはどうしよう？

最後に、これが一番重要になりそうですが、グーグル社員ではない私たちはどうすればよいのか？です。
自分たちの置かれた状況に応じていろんな考えが出てきますが、個人的には、本書は「何が何でもテストコードで自動化しよう」という衝動に対するアンチテーゼとして、現実的なアプローチを推奨する苦い良薬になると思います。
日本におけるテストコードの啓蒙では、特にWebの世界では、TDDを中心として「開発者の不安を最小化する」であるとか、「設計を改善する」という視点でのアプローチが多い用に感じています。確かにそのとおりなのですが、そもそも「不安」というのはどこまで行っても無くなり消えることはありえないものではないでしょうか。人間は生物として、本質的に常に「不安」を欲してその存在を感じていたい生き物なのではないかなーとか格好つけて言ってみたり。
そうしたメンタルであったり設計技法であったり、あるいはテスト自動化のメリットであるリグレッションテスト自動化であったり、そうしたアプローチを採っている限りでは、どうしても開発者やTDD推進者の自己満足に終わってしまいそうです。しかも、不安は消えることが無いとすれば、単体テストだけでは不安、DB接続やビジネスロジックの結合テストも、Webブラウザを使ったエンドツーエンドのテストも何もかも自動化しないと不安、でもエンドツーエンドに近づくに連れてWebブラウザやUIなど、自動化の難しい部分が出てきて、そこのテストが書けない不安がさらに不安を呼ぶ・・・とかになってませんか？

本書は、「グーグルですら」それらに対して満足な回答を用意できていない、と語っています。

況や我々をや。

グーグルですら、現実は無情のようです。だからこそACCを使ったリスクベースのテストプランを組み上げたり、どうしても自動化が難しい部分は手動のテストケースとして残しておいたりしているようです。

これは非力な私達にとっては福音でもあります。まずこの世界に完璧など無いことをグーグルは示してくれたので、私達も"100%"に拘る必要は無いのです、多分。そして、テスト自動化の技法についてはグーグルが実験と検証を重ね、一部はOSSとして公開されていますし、WebDriverという形でブラウザにも組み込まれています。我々は、それらの美味しいところだけをパクれば良いのです、多分。

そして一番学ばなければならないのは、「製品の価値」を第一に据えてテストをそれに従属させる、禁欲的とも言える姿勢なのかもしれません。

以下、長ったらしい自分語り。

---

大体2007年ごろからTDDを学び始めた記憶がありますが、やっぱり単純な外部I/Oを持たない、純粋に計算だけのコードは、そりゃあテストは簡単なんですよ。
しかし現実のコードはファイル・DB・ネットワーク、そしてOSとやり取りするわけで、じゃぁどうやってそうした外部との入出力が発生するコードのテストコードを書くのか？あるいは既存のガチガチに密結合したコードに対してテストコードを埋めていくのか？というのをぼちぼち調べたりしてました。
で、出向型のSEとしてあっちの現場・こっちの現場で経験を詰んでいくわけですが、ぶっちゃけ、自動化された単体テストコードが1行でもあった現場は皆無でした。
当時、TDDに光明を見出しつつあった自分はまぁアレコレと動いたりしてみたのですが、やっぱり、あちこちの現場に出向いて「余所者」として作業してるだけでは結局限界を感じました。
組織の中に入って、数年のスパンでじっくりと動かないと、組織文化や風土は変えられないな、と感じました。
その辺りから、TDDに執着するのをやめました。
TDDは「思想」とか「哲学」との結びつきが強すぎる、と感じました。
本質は、「テストの自動化」、この一点に絞るべきと思いました。
アジャイルとかもろもろの思想哲学を引き剥がして、単純に「テクニック」「技法」として「テストの自動化」を考えた方が、もっとドライにテストコードと向き合えると思いました。
「思想」とか「哲学」になると、執着が発生して"100%"を目指し、それ自体が目的化してしまいがちです。
そうではないはずで、もっとライトに、例えば「Webフロントは面倒くさいから自動化しない」とか判断しても問題ないはずです。そこには正解なんてなくて、「テストの自動化」というおのは単なる技法でありツールなのだから、「TDD」なんて大仰な物言いはせずに、もっと単純に「開発とかテストが楽になる」という視点だけで、導入できるとこだけ導入する、という割り切りでも良いはずです。プロジェクトの特性に合わせて、自由にその辺のさじ加減を判断して良いはずなんです。
多分、当時の日本におけるTDDの啓蒙活動でもそういう緩さを話してくれる人は・・・多分居たのだと思いますが、どうも、現実と合ってないな、と感じることが多々有りました。

さらに、テストコード自体の作成の難易度も、自分には実際に現場展開するのは非現実的だと感じました。
明らかにテストコード自体の行数の方が肥大化します。単にビジネスロジックを書くだけの知識では不足し、単体テストフレームワークの知識やモック手法、言語ごとに存在するピットフォールなど、幅広い知識とノウハウ、スキルが必要とされます。
ファイル・DBはまだ良いのですが、OSのシステムコールと対話するところなど特にそうです。もしそれをmock化しようとすると、もうOSのAPIを全部その言語の世界観にそったmockオブジェクトに変換して、DIコンテナでインジェクトするほか無いではありませんか。
さらにそれにくわえて、継続的インテグレーションに組み込もうとするとコンパイル環境・テスト環境と、これら個別の言語ごとのmock化のノウハウをすべてシームレスに結合しなければなりません。

・・・そんなわけで、2009年末ごろにニート化して以来、TDDについては積極的に関わりませんでした。
2010年ごろから、テストコード周りの記事を書くときに"TDD"という表現ではなく「(単体)テストの自動化」という表現を意識して使っていました。それは、テストコードの作成はあくまでもツールであり技法であり、TDDのように哲学的背景を有する開発プロセスとしては重すぎるため、そうしたニュアンスを削っておきたい、というのを意図しています。

2011年にニートを辞めて、しばらくして社内ツールの開発に入り始めて、今も入っているのですが、1年以上に渡る開発で少しずつ少しずつ、テストコードを潜り込ませています。全部を自動テストに組み込むのは最初から諦めていて、「ここだけはデグレすると不味い、テストコードが無いとヤバイ」という箇所を作ったり直したりするたびに、本当に重要な箇所だけに絞って、少しずつ、少しずつテストコードを書いてます。

そして今、本書を読んで、改めて自分の直感は間違ってなかったんだな、と思いました。
グーグルですら、テストの自動化は難しい。
グーグルですら、開発者にテストコードを書いてもらう文化の導入は茨の道だった。
グーグルですら、100%のテスト自動化は諦めている。

テストコードを書けないのは個々人のスキルの問題ではない。テストの自動化が難しいのも同じ。
グーグルですら、困難な道のりで、恐らくテストの自動化については純粋にソフトウェア開発としての難しさが有り、テスト文化については人間的な側面がある。
そして、どうにもTDDの啓蒙として「開発者の不安を～」とか「設計が洗練される～」というのに違和感を感じていた箇所が、本書のグーグルのテストエンジニアの一貫したスタンス、「製品の価値」を第一としてそれにテストを従属させる、というのではっきりしました。
結局、「会社の利益」＝「製品の価値」を第一に据えることで、テストの意味がはっきりするのだと。

なので、改めて、2007-2008年当時の自分のTDDへの関わり方は、どう頑張っても現場に定着させることは出来なかったんだな、と感じました。

多分、本書はTDDやテストコード作成を組織文化として定着させたいエンジニアにとって、非常に有意義な内容の筈です。ぜひ一読をおすすめしたいです。

---

• [ Prev ]
• [ Next ]
• [ 読書 ]

プレーンテキスト形式でダウンロード