テストから見えてくるグーグルのソフトウェア開発 の商品レビュー

ジェームズ・A.ウィテカー,ジェーソンアーボン,ジェフキャローロ【著】,長尾高弘【訳】

2013/11/23

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

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

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

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

2013/10/24

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

2013/09/17

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

2013/09/07

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

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

2013/08/20

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

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

2013/08/11

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

2013/08/09

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

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

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

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

2013/06/16

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

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

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

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

2013/06/15

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

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

2013/06/14

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

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

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

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