ジェフ・キャローロのレビュー一覧
-
-
-
-
-
Posted by ブクログ
2006年頃から、Googleがどのようにテストに関するソフトウェア開発組織をつくり、どう運用してきたかという話。SWE, SET, TEという職制の話あと、人々と個々の製品へのインタビューという形式。
20%を使って、リポーティングを含めたテストの効率化のツールを開発したという話がいたるところで出ている。Googleがとてもツールを大事にしているか、動くものを大切にしているかがわかる。
一方できちんとROIに基づいて判断をしているあたりもさすが。
ぜひ見習いたいものだが、マネジメントを含めた人材の質が違いすぎるのが問題か、、、
しかし、ソフトウェアに携わる人は誰でも、この組織と競争しなくちゃいけない状況にあることを意識する必要がありそう。
テストについてだけでなく、Googleのソフトウェア開発について知りたい人にもお勧め。 -
Posted by ブクログ
ネタバレGoogle社内ではよくあるソフトウェア開発会社と異なり、製品開発チームと品質管理（テスト部門）が別組織として活動している。
別組織としてある事のメリットとしては以下のようなものが有るとのこと。
・製品間をテストのスペシャリストが移動することで、良いテスト手法を広めることが出来る
・テスタの数を抑えることが出来る。（製品開発序盤はテスタが必要とならない場合が多い）
・製品の価値を客観的に捉え、潰すべきバグの優先度を開発チームに周知することが出来る。
この時、Google内ではACC（Attribute Component Capability)という3つの値を利用して、製品の価値の優先度分析を行なっている。
SI企業ではPMOと呼ばれる進捗・課題・リスク管理を行う組織が製品開発部門のサポートに入ることはあるが、製品の品質向上をサポートする外部組織は聞いたことが無い。
ある程度大きなプロジェクトであれば製品開発当初からテスト部門が関わり、テストプランの作成、テスト環境構築、テストケースのチェックなどをサポートすることが必要なのではないだろうか。
Googleの様な高品質のプロダクトを生み出す秘訣がここにあると感じた。
しかし、巻末には、未来のGoogleにはテスト部門はそのうち無くなるのでは無いか？という記述がある。
品質の優先度を管理するメンバはよりユーザ側に立ち、製品のテストをコードレベルでサポートするメンバは開発エンジニアに近づいていくという理由からである。
これは、ある程度テストの手法・技術が社内で確立されたGoogleだから言えることではないかと思う。
その他の一般企業は先ずはテスト部門を立ち上げることから始めると良いのだろう。 -
-
-
-
-
-
-
-
-
Posted by ブクログ
サブタイトルにもあるとおり、Googleではテストファーストによりエンジニアリング生産性を向上させているというもの。正直、今の自分の知識では、本書の1/3も理解できなかったと思う。しかしながら、今携わっているシステム開発で、ちょうど受け入れテストを実施していて、想像以上に骨の折れる作業であることを痛感している最中に読んだため、Googleが進んでいることが際立って感じた。少なくとも、システム開発においてテストがいかに重要かという点は充分に学ぶことができた気がする。Chrome、Gmail、Youtube等に実際に携わっている人々のインタビューが収録されているから、その説得力は半端ない。
「テストは、イノベーションと開発のペースを遅らせるような摩擦を作るものであってはならない。」
「グーグルテストは、大軍ではなく、優れた戦術と高度な武器で百戦百勝を実現する少数精鋭の特殊部隊なのだ。軍の特殊部隊と同様に、グーグルテストの特徴はこの人材の少なさにある。ラリー・ペイジが『希少性は明確性をもたらす』と言っているように、人数が少ない分、私たちは必然的に優先順位をうまく付けなければならなくなる。」
「グーグルでは、形態よりも規模を強調するために、コード、統合、システムテストという区別をせず、Sテスト、Mテスト、Lテストという表現を使う。」
「グーグルのSWE(ソフトウェアエンジニア)は、顧客のもとに届けられるコンポーネントの開発に責任を負う機能デベロッパーだ。彼らは機能コードとその機能コードのための単体テストコードを書く。
グーグルのSET(ソフトウェアエンジニアインテスト)は、単体テストに関してSWEを助け、SWEがSテストより広範な品質問題を評価するMテストを書くときに使う大規模なテストフレームワークも各テストデベロッパーだ。
グーグルのTE(テストエンジニア)は、品質に関係するあらゆる問題でユーザーの立場で動くユーザーデベロッパーだ。」
「グーグルはコードレビューを開発プロセスの中心に置いている。コードを書くことよりもレビューすることの方がずっと大切なこととして大々的に取り扱われる。」
「ACC(アトリビュートコンポーネントケーパビリティ)は、製品の3つの側面を通じて立案者を導いていく。すなわち、?製品の目的と目標を説明する形容詞と副詞、?製品のさまざまな部分や機能を表す名詞、?製品が実際に何をするのかを示す動詞の3つだ。そして、これらの機能が働いていること、書いたコンポーネントがアプリケーションの目的、目標を満たすことをテストで確かめていく。」
「グーグルはイノベーティブな会社として知られるが、テストチームは確かにその評価にふさわしい。グーグルの社内で生み出され、使われているテスト実践やツールの数(そしてその多くは社外にも公開されている)は、このイノベーティブな精神がテストチーム同士を固く結びつけていることをよく示している。」
「私は自動化には懐疑的になってきているんですよ。テスターは自動化の大きなビジョンに情熱を傾け、自動化の作成に何カ月もかけますが、結局製品かプラットフォームが変わって、してきたすべてのことが否定されてしまいます。時間の試練に耐えられない自動化を書くこと以上にひどい資源の無駄遣いはありません。私の考えでは、自動化はすぐに書けてすぐに実行でき、非常に限定的な問題を解決するものでなければなりません。自動化されたテストの目的がすぐに理解できないようであれば、それは複雑すぎます。単純にして、範囲を限定し、何よりもまず、価値を追加するものにしなければなりません。」
「（グーグルに入ったころと比べてテストでもっとも大きく変わったことは？）
まず第１に、平均的なデベロッパーが以前よりもテストプロセスに関わり、自動化を書くようになったことです。彼らは単体、API、統合、フルシステムテストの知識を持っています。…第２に、テスト専門の職務に数百もの最高のエンジニアたちを引きつけられるようになりました。私は、この２つは関係があると思っています。これはテストを尊重する文化であり、テストを行うことは、そのために評価を受けることになったのです。」
しかし、一方、テストファーストも行き過ぎると問題となることも認識している点が追う立場の我々も考えなくてはならない点である。
「グーグルのように開発とテストを分離していると、職務によるつながりが強くなり、テスターが製品に一体化しにくくなってしまう。」
-
-
-
-
Posted by ブクログ
CI、テストコードといった考え方は比較的一般的になってきたと思うが、
SET(Software Engineer in Test)、TE(Test Engineer)、TEM(Test Engineering Manager)といったレベルで専門化までしているのは先進的と感じる。
大手SI企業のエンタープライズ向けシステム構築でここまでやっている企業はあるのだろうか？また、今後このような方向に進めるべきなのだろうか？
ソフトウェアの品質は常に問題にあるトピックであり、具体的にどのように品質を向上させるか（それに伴いどこまでコストがかかるか）は、考え続ける必要がある。
一般向けプロダクトを作る作る仕事をしていないせいか、正直今ひとつピンと来なかったのも事実であり、この感覚が危険なのかもしれない。 -