【感想・ネタバレ】テストから見えてくるグーグルのソフトウェア開発 テストファーストによるエンジニアリング生産性向上のレビュー

ジェームズ・A・ウィテカー / ジェーソン・アーボン / ジェフ・キャローロ / 長尾高弘

[ブクログ · ★★★★★]

自由度が高く混沌としたテストの領域に対して、あのGoogleもチームごとに成熟度がばらばらで苦労しつつ、ツール開発などの試行錯誤を経て進化をしてきたことが知れ励みになる。
それぞれの人が違う思想を持って、違ったアプローチでテストを良くしようとしている。現時点で銀の弾丸はなく、自らの組織に適したアプローチを模索していく必要があるように感じた。そういう観点で本書に掲載されたプラクティスを参考にするのは価値がある。

[ブクログ · ★★★★★]

3年前の本だが今読み返してみても、変化の激しい中でのテストによるソフトウェア開発の支援方法やそのための組織構成など、参考になることが多い。また、紹介されているツールなども面白く試す価値が高そう。変化の激しい場での生産性向上を考える人にはおすすめしたい。

[ブクログ · ★★★★★]

大規模なインフラを活用したテストとか、テスターもコードはバリバリ書けますとかはさすがだなと思う一方、Sテスト（単体テスト相当）、Mテスト（結合テスト相当）、Lテスト（システムテスト相当）とか、手動テストをやってたりとか、意外と普通な一面もあると思った。
バグのあるコミットをした数分後には問題が通知されるとか、SIerでもそういうの当たり前にやっていかなければいけないと思うし、とても良い刺激を受けたと思う。あとは行動あるのみ。

[ブクログ · ★★★★★]

この本は改善を重ねた結果のテストの取り組み方としての組織のつくり方という部分が描かれていたり、また、採用に関しての話も面白かった。また自由に使える２０％タスクが現実的にはどのような形で運用されているのかというのも垣間見えた。

テストをする人を2種類に分けて考えるという考え方はなるほどと感じる部分があった。

[ブクログ · ★★★★★]

2006年頃から、Googleがどのようにテストに関するソフトウェア開発組織をつくり、どう運用してきたかという話。SWE, SET, TEという職制の話あと、人々と個々の製品へのインタビューという形式。

20%を使って、リポーティングを含めたテストの効率化のツールを開発したという話がいたるところで出ている。Googleがとてもツールを大事にしているか、動くものを大切にしているかがわかる。
一方できちんとROIに基づいて判断をしているあたりもさすが。

ぜひ見習いたいものだが、マネジメントを含めた人材の質が違いすぎるのが問題か、、、
しかし、ソフトウェアに携わる人は誰でも、この組織と競争しなくちゃいけない状況にあることを意識する必要がありそう。

テストについてだけでなく、Googleのソフトウェア開発について知りたい人にもお勧め。

[ブクログ · ★★★★★]

Google社内ではよくあるソフトウェア開発会社と異なり、製品開発チームと品質管理（テスト部門）が別組織として活動している。
別組織としてある事のメリットとしては以下のようなものが有るとのこと。
・製品間をテストのスペシャリストが移動することで、良いテスト手法を広めることが出来る
・テスタの数を抑えることが出来る。（製品開発序盤はテスタが必要とならない場合が多い）
・製品の価値を客観的に捉え、潰すべきバグの優先度を開発チームに周知することが出来る。

この時、Google内ではACC（Attribute Component Capability)という3つの値を利用して、製品の価値の優先度分析を行なっている。

SI企業ではPMOと呼ばれる進捗・課題・リスク管理を行う組織が製品開発部門のサポートに入ることはあるが、製品の品質向上をサポートする外部組織は聞いたことが無い。
ある程度大きなプロジェクトであれば製品開発当初からテスト部門が関わり、テストプランの作成、テスト環境構築、テストケースのチェックなどをサポートすることが必要なのではないだろうか。
Googleの様な高品質のプロダクトを生み出す秘訣がここにあると感じた。

しかし、巻末には、未来のGoogleにはテスト部門はそのうち無くなるのでは無いか？という記述がある。
品質の優先度を管理するメンバはよりユーザ側に立ち、製品のテストをコードレベルでサポートするメンバは開発エンジニアに近づいていくという理由からである。
これは、ある程度テストの手法・技術が社内で確立されたGoogleだから言えることではないかと思う。
その他の一般企業は先ずはテスト部門を立ち上げることから始めると良いのだろう。

[ブクログ · ★★★★★]

マガジン（雑誌）のような本です。WhittakerらがGoogleでいかにCoolなテストをやり遂げたかが書かれています。

ここに書いてあること全てをそのまま実践するのではなく、何故彼らはこうしたんだろうと考えて、ヒントとして受け取り自分たちに合ったテストを構築していくのが正しい読み方だと思います。

とてもたくさんの刺激と知恵を貰えました。

そっかー、STEはTEの倍いるのか……。

[ブクログ · ★★★★☆]

「3.2.1 テストプランの立案」が本質的でとても良かった。

ただ、ところどころにあるインタビューとかは若干読みやすさを損なう方向に行っている気はする。

この邦訳の刊行が2013年、原著は2012年なので、今現在のG社はもっとずっと先を行っているのだろうなぁ、と思う。SWE と SET は同じものになっていく、と最後に書かれているけどもうそうなっているのかも。

[ブクログ · ★★★★☆]

題名の通り、グーグルのソフトウェア開発を知ることができる本です。ソフトウェア開発の経験がある方であればエッセイ感覚で読めると思います。

より高いテストレベルのシステマチックな実行環境を構築したり、その実行速度を上げたりという活動を重視し、Software Engineer in Test という職種を設けているそうです。一方で、手動テストはなくならないという記述もあります。真っ当なエンジニアリングを行っているという印象です。

その他、テストに力を入れていない頃の昔話、幾つかの開発事例を題材としたインタビューなども面白いです。

[ブクログ · ★★★★☆]

グーグルのソフトウェア開発の内部を垣間見れる本。

プロダクトやまたテストがスケールするか、という点を当たり前のように考えているのは、ウェブ全体をそのスコープとするグーグルならではなのかと思った。

[ブクログ · ★★★★☆]

グーグルでもテストがボロボロの時があったんだなって言う正直なエピソードから、さすがグーグルと思うことまで、興味深いことが書いてあった。
サクサク読めるほどではなかったし、
スキルや風土の面で日本の企業でもできるかっていうと疑問だったけど、
テストの専門性を強化したいなら是非読んでおきたい本だと思った。

不要なドキュメントは書かないこと、
役に立たないテストは捨てるなど、
完璧性よりも効率を重視した記述が多かったのが印象的だった。

[ブクログ · ★★★★☆]

Googleのような開発・リリースのスピード感を得るにはやはりテストが重要だということを認識させてくれる書籍。テスティングフレームワークやCIなど手法自体は普及してきたが、実際にどうやってその手法をうまく利用するのか、一流エンジニア達の実際の運用を知ることが出来る貴重な書籍。

[ブクログ · ★★★★☆]

色々な人のインタビューも、事例も、それぞれ違うのに、どれも理想的。
考え方も技術も、テストに対する姿勢も、見習わなきゃいけない。

「テストチームの目標は品質を保証することではないし、そうであってはならない」

[ブクログ · ★★★☆☆]

グールグでのプログラマ、テスタのレスポンシビリティがよくわかる。また、マネージャの仕事内容もよくわかる。これらを総合すると、グーグルのソフト開発能力の源泉が理解できる。こういうことができない、もしくは理解できないと（要は現在のソフトに対するリテラシイが高くないと）、近い将来ソフト屋として存在意義を失う可能性が高いと思う。

[ブクログ · ★★★☆☆]

　サブタイトルにもあるとおり、Googleではテストファーストによりエンジニアリング生産性を向上させているというもの。正直、今の自分の知識では、本書の1/3も理解できなかったと思う。しかしながら、今携わっているシステム開発で、ちょうど受け入れテストを実施していて、想像以上に骨の折れる作業であることを痛感している最中に読んだため、Googleが進んでいることが際立って感じた。少なくとも、システム開発においてテストがいかに重要かという点は充分に学ぶことができた気がする。Chrome、Gmail、Youtube等に実際に携わっている人々のインタビューが収録されているから、その説得力は半端ない。

「テストは、イノベーションと開発のペースを遅らせるような摩擦を作るものであってはならない。」
「グーグルテストは、大軍ではなく、優れた戦術と高度な武器で百戦百勝を実現する少数精鋭の特殊部隊なのだ。軍の特殊部隊と同様に、グーグルテストの特徴はこの人材の少なさにある。ラリー・ペイジが『希少性は明確性をもたらす』と言っているように、人数が少ない分、私たちは必然的に優先順位をうまく付けなければならなくなる。」
「グーグルでは、形態よりも規模を強調するために、コード、統合、システムテストという区別をせず、Sテスト、Mテスト、Lテストという表現を使う。」
「グーグルのSWE(ソフトウェアエンジニア)は、顧客のもとに届けられるコンポーネントの開発に責任を負う機能デベロッパーだ。彼らは機能コードとその機能コードのための単体テストコードを書く。
　グーグルのSET(ソフトウェアエンジニアインテスト)は、単体テストに関してSWEを助け、SWEがSテストより広範な品質問題を評価するMテストを書くときに使う大規模なテストフレームワークも各テストデベロッパーだ。
　グーグルのTE(テストエンジニア)は、品質に関係するあらゆる問題でユーザーの立場で動くユーザーデベロッパーだ。」
「グーグルはコードレビューを開発プロセスの中心に置いている。コードを書くことよりもレビューすることの方がずっと大切なこととして大々的に取り扱われる。」
「ACC(アトリビュートコンポーネントケーパビリティ)は、製品の3つの側面を通じて立案者を導いていく。すなわち、?製品の目的と目標を説明する形容詞と副詞、?製品のさまざまな部分や機能を表す名詞、?製品が実際に何をするのかを示す動詞の3つだ。そして、これらの機能が働いていること、書いたコンポーネントがアプリケーションの目的、目標を満たすことをテストで確かめていく。」
「グーグルはイノベーティブな会社として知られるが、テストチームは確かにその評価にふさわしい。グーグルの社内で生み出され、使われているテスト実践やツールの数(そしてその多くは社外にも公開されている)は、このイノベーティブな精神がテストチーム同士を固く結びつけていることをよく示している。」
「私は自動化には懐疑的になってきているんですよ。テスターは自動化の大きなビジョンに情熱を傾け、自動化の作成に何カ月もかけますが、結局製品かプラットフォームが変わって、してきたすべてのことが否定されてしまいます。時間の試練に耐えられない自動化を書くこと以上にひどい資源の無駄遣いはありません。私の考えでは、自動化はすぐに書けてすぐに実行でき、非常に限定的な問題を解決するものでなければなりません。自動化されたテストの目的がすぐに理解できないようであれば、それは複雑すぎます。単純にして、範囲を限定し、何よりもまず、価値を追加するものにしなければなりません。」
「（グーグルに入ったころと比べてテストでもっとも大きく変わったことは？）
　まず第１に、平均的なデベロッパーが以前よりもテストプロセスに関わり、自動化を書くようになったことです。彼らは単体、API、統合、フルシステムテストの知識を持っています。…第２に、テスト専門の職務に数百もの最高のエンジニアたちを引きつけられるようになりました。私は、この２つは関係があると思っています。これはテストを尊重する文化であり、テストを行うことは、そのために評価を受けることになったのです。」
しかし、一方、テストファーストも行き過ぎると問題となることも認識している点が追う立場の我々も考えなくてはならない点である。
「グーグルのように開発とテストを分離していると、職務によるつながりが強くなり、テスターが製品に一体化しにくくなってしまう。」

[ブクログ · ★★★☆☆]

テストについての考え方を学べたが、インタビューなどはわりと読むのが面倒くさかった(わりと冗長なないようだった)

テストのベースとなる考え方を作れるので、オススメ。

[ブクログ · ★★★☆☆]

読み終わったー＼(^o^)／
Googleでのテストの考え方、実施手法などの事例集。
コードが書けるテストデベロッパーが必要そうです

[ブクログ · ★★★☆☆]

テストに関わる仕事の地位向上に寄与し、その分野のスーパースターまで生み出しているGoogleの文化は素晴らしい。開発手法も増えてテストの重要性も上がっていくなかで、まだまだテストに対する意識や重要性の認識が低い気もするため、 良い動きであると思う。

[ブクログ · ★★★☆☆]

CI、テストコードといった考え方は比較的一般的になってきたと思うが、
SET(Software Engineer in Test)、TE(Test Engineer)、TEM(Test Engineering Manager)といったレベルで専門化までしているのは先進的と感じる。

大手SI企業のエンタープライズ向けシステム構築でここまでやっている企業はあるのだろうか？また、今後このような方向に進めるべきなのだろうか？

ソフトウェアの品質は常に問題にあるトピックであり、具体的にどのように品質を向上させるか（それに伴いどこまでコストがかかるか）は、考え続ける必要がある。

一般向けプロダクトを作る作る仕事をしていないせいか、正直今ひとつピンと来なかったのも事実であり、この感覚が危険なのかもしれない。

[ブクログ · ★★★☆☆]

深い内容であったので、本全体の十分な理解にはつながらなかったが、Google のエンジニアとしての考え方を知れたのでその点には満足している。