テストから見えてくる グーグルのソフトウェア開発 を読んだ
会社の本棚で見つけ、興味のあるタイトルであったので読んでみた。
SET(Software Engineer in Test) が主題となる本だが、それ以外にもSWE(Software Engineer)、TE (Test Engineer)、TEM(Test Engineer Manager) 4つのGoogle内部での職能についいて触れられていて、またキャリアを積んでいる実際のメンバーに対する対談記事が書かれている。
SET視点として、Chromeなどのソフトウェアビルド後に出てくる問題に対し、技術的・人的にどう解決しているかが書かれていて、テスト手法・ツールの作成について書かれている。SWEとの付き合い方・協調のしかたについて取り上げられていたのが印象的だった。
テストのサイズ分類が特に目についた。Sサイズ・Mサイズ・Lサイズの大きさでテストを分けるようにしていて、Sサイズは単体で終了するテストサイズ、Mテストはモジュール依存で終了するサイズ、Lサイズは各ライブラリ・パッケージが協調してテストできるサイズとなっている。
TE視点としては、SETが作成したテスト用のコード・ツールを管理、利用する立場を取る。TEとして生きるには特性が必要らしい。これがおかしいんじゃないか？と思ったり、疑問に思う能力、など。TEはテストをするのが目的ではなく、製品を扱っているという認識が大事であると書かれていた。
テスト項目の管理にはGTA(Google Test Analytics)を利用しており、スプレッドシートによる管理から脱却した旨の記述があった。
ACC、Attribute、 Component、Capabilityという単位でテストに必要な要素を抜き出し、単純なテスト項目として書き出す、というのを防いでいるようだ。Androidのテスト作成時に利用された。
TEM視点として、TEの取りまとめ、テスト計画の管理など、Managerとしての役割を求められる点が書かれていた。効率の用意テスト、モチベーションに気を回しているな、と文章から読み取れた。
他、なんでも自動化すればよいわけではなく、投資に見合わなければ撤退すること(資金を引き上げる、と文中では書かれていた)、自動化が役に立つところ(URLリソースごとのスクリーンショットを取って差分があったら検出する)、など。20%ルール(1週間に1日つかって自由に自分のプロダクト開発、研究に当てて良いGoogleのルール)でSET、SWEの垣根を超えてアイディアを出し合ったり、社内の勉強会で知見を共有して広めたり、実際のアイディアをコードに落とし込んで社内や上司にプレゼンしたりなど、行動指針として考えないとな〜と思う取り上げ方が多かった。外部ベンダーをうまく使う方法も書かれていて、自分で用意できない、多くのハードウェア・ソフトウェアのバージョンに依存するテストについてはクラウド上のリソースを利用しようというのも目立った。
原著は2011年に書かれたもので、すでに7年経過していて、且つ本で取り上げられたソフトウェアの中には、Chrome Extensionにスクリーンショットを取ってバグを報告するもの(BITE)があるが、2013年を最後にcommitが入っていない。
Google Testing Blogは現在も新しいエントリが追加されている。今の彼らはどうしているのか気になったときに改めてTesting Blogを読みたい。
考えを改めるきっかけになり、読んでよかった。
