『テストから見えてくる グーグルのソフトウェア開発』 その4

グーグルのソフトウェアテスト本のメモ、その4。とっくに読み終わってるんだけど、メモを書くのが遅れております…
4

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

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

要は、SETやTEの上司にあたる役職である。彼らが日々どんなことを考えているのか、実際のスタッフへのインタビューも交えて綴られている。人によって、自動化を重視してたりマニュアルテストを重視してたりで、同じ役職でも考えが違っていて面白い。

とはいえ、結局大事なことは、「サービスを知ること」と「スタッフを適材適所で配置すること」に尽きる気がした

以下メモ

• TEMとして成功するための最初のアドバイスは「自分の担当製品を知れ」であり、第二のアドバイスは「部下をよく知れ」である。自分の製品を良く知っているTEMならもっとも優先順位の高い仕事が何か、適切な対処を必要としている部分がどこかもわかるはずだ。部下をよく知っているTEMなら、適切なスキルをもっとも必要としている部分をそのスキルの持ち主に担当させることが出来るはずだ。

• 資源(要は人員)が足りなければ、責任が明確になり、プロジェクトのメンバーたちは仕事を自分のものと強く考えるようになる

• TEMは人に頼ることを避けなければならない。仮にスターテスターが居たとしても、彼を良いように使うだけではいけない。そのテスターをスターに押し上げたものがなんであれ、それをツールの形にまとめたり、パッケージとして他のテスターを同じようなスーパーテスターに育て上げたりしなければならない

• 害のあるプロジェクトに関わるのは避けよ

• TEMは部下たちのインパクト(要はプロジェクトに対する貢献度)を計測できるようにしておくこと

• TEMは、全体として自分の組織で見られるベストプラクティスの発掘に熱心で、それらを同僚に知らせることに積極的でなければならない

• プロジェクトに参加するときは、最初の数週間は話を聞くために費やすべき。例えば、最初の5分で抗生物質を処方する医者のような人を誰が信頼するであろうか。まずは、話すのではなく聞き、試すのではなく尋ねましょう

• 正しいスキルと正しい態度を持つ人々を集めよ

• チームのダイナミクスで必要なのは、デベロッパーチームとテストチームの関係である

• 何を解決すれば、私達テスターが対等なエンジニアとしての立場を確率出来るくらいのリスペクトが集められるのかを考えてみよう

• 採用は妥協するな。頭数を揃えるために良くない人を採用すると、もっと良い人が現れるのをまつよりも、必ず良くないこと

になります

• グーグルがしたことを真似ようと思っている会社は、スキル、人材の希少性、自動化、イテレート/統合の4つから始めるべきでしょう

• ユースケースの20%が利用の80%を占める。その20%だけを自動化し、他のものは手をつけるな。

• バグの検出ではなく、バグの予防に力を入れたことが会社に大きな利益をもたらしました

• 製品を作るのは簡単だが、高品質な製品を素早く作るのは大変なことです

• 価値を追加せよ

• 「ピラー(柱)」という考え方を使っている。ピラーにはシステムピラー(カーネル、メディアなど)、フレームワークピラー、アプリピラー、マーケットピラーなどがあり、それらで組織わけをしていた。部下であるテスターがどのピラーが得意なのかを

把握し、チームを組織した

• 時間の試練に耐えられない自動化を書くこと以上に、ひどい資源の無駄使いはありません。自動化はすぐに書けてすぐに実行出来ねばならない

• 自動化は変化に弾力的に対応することが難しい事が多い。なので、手動テストも大事である。

• 探索的テストは、製品を掘り下げてその内容を学習する最良の方法です

• 日々のビルドをじっくり見て、中身を分析する。そうすることで、製品全体を手当たり次第に探索していくのではなく、日々の変化に商店を絞って、ずっと生産的な仕事ができます

• チーム全体が成果物の品質の責任を負うようにする

• マシンに仕事の90%をやらせて、人間の知性は最後の10%だけに使うようにします

• ツールの目的は、プロセスを自動化して簡単にすることです。ただし、悪い振る舞いを自動化しないように気をつけましょう

• テストでは、コンピュータ科学的な側面よりもソーシャルな側面の方がずっと難しいということだ。

• 開発チームに孤立無援のテスターが組み込まれているのではなく、テスターのグループが一緒に座って互いのアイデアを消化しあうように

• 優れたマネージャになる秘訣は、単純に部下をその人に合ったプロジェクトに配置すること

• 変更が難しい部分のテストに、まずは力を注ぎましょう

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

• すべてのエンジニアのワークフローに品質を入れよ

• テストは、品質そのものではない。品質は最初から組み込まれていなければいけないものであり、あとから付け足されるべきものではない

• テストの価値は、成果物ではなく、テストという活動自体にある

• 若手のデベロッパーや大学新卒の新人にとって、テスト開発は最初の仕事として、間違いなくもっとも良い

• 私達の考えでは、テストエンジニアリングはテストデザインという仕事に変身する

どんだけ野球うまくても、そこにあぐらかいてたら、そらあれよ。清原みたいになるよ。の件

数カ月前に、プロアスリートが引退後に何をやってるのか、みたいなテレビ番組をやっていた。

たとえば、プロ野球選手とか、20代の半ばくらいで引退を言い渡されることなんて珍しくない。しかし、小さい頃から引退するその日まで、文字とおり野球しかしてこなかったわけで、そんな人が、いきなり社会に放り出されても、生きていく術なんてわからない。だから、結局、トラックの運転手だとか、引っ越し業者だとか、飲食店だとか、好むと好まざると体が資本の業界で働かざるを得ない。みたいな、内容だった(でもって、そういう人が、あまりにも多いものだから、最近はプロアスリートのセカンドキャリアをコンサルするような人も出てきているのだという)

そして、これは、普通の社会人にも言えることな気がするのです。今、自分がやっている仕事が、ガラパゴス的なやつなのか、そうでないのかは、常に意識しておいた方がいい。

その会社だけのノウハウというものは、どこにでもあるだろうし、そして、それは必ず習得しなければいけないものだけれども、それだけを習得して満足していては、いざ、会社が潰れたり、自分が会社を辞めざるを得ない状況になったときに、とても困る事になる。

テスト技術者にとって、テスト対象のサービスを愛することは大事だし、サービスの仕様に詳しくなることは仕事をやる上で必要なことだ。しかし、それだけに注力するのは、リスクがでかい。そのサービスのマイナーな仕様を理解するよりも、もしかすると、英単語の一つでも覚えたほうが、将来のキャリアには繋がるのかもしれない。

テストの仕事って、どうしてもガラパゴス化し易いし、だからこそ、その小さな組織内では優位性を持てたりもするし、優位性が持てれば居心地がよくなったりするけど、そこに安住してると、長期的には良くないよなぁと思った今日このごろなのでした。

テストの秘孔

ソフトウェアのテストって、その気になれば、いくらでも工数をかけることが出来る。

例えば、スマートフォンのアプリで、10項目しか無いテストケースが合ったとしても、その気になれば

• iOSとAndroidで場合分け

• iOS,Androidともに直近の3バージョンで場合分け

• 各OSともキャリアによって場合分け

• メーカによって場合分け(仮に5メーカとする)

• wifiとLTEと3Gで場合分け

• 電波の強弱によって場合分け

と言った具合に、ぱっと思いつく限りでも、上記のパターンで分類することができ、たったの10項目のテストケースが、10x6x3x5x3x2と5400のケースになってしまうわけです。

そのため、テストは「やるべきこと(=バグが流失した時のリスクがでかい機能のテスト)」と「やったほうが良いこと(=今まで問題がなかったけど、バグるとちょっとまずい。or バグると少しリスクがある機能のテスト)」に分けることが出来ると僕は考えています。「やるべきこと」は、必ずやるとして、「やったほうが良いこと」をどれだけ効率よく効果的にカバーするのかというのが、テスト組織にとっての、常に考えなければいけない課題だし、そして、それが出来る人が、良いテスト技術者だと思うのです。

僕が見てきたテスト組織の中には、「やったほうが良いこと」が多すぎて、テスト実施者が疲弊してしまっていることも、よくありました。いたずらにテストの項目を増やし、しかし人員は増えることなく、結局今いるスタッフがひたすら残業して項目を消化していく状況です。

もし、テスト組織が残業ありきになっているとしたら、その組織は、テスト項目の重み付けが出来ていないわけで、すなわち、テストやテスト対象に対する「ノウハウ」や「知識」が存在していない状況になっていると思います(良いテスト技術者が存在していないとこうなる)。
「それは、本当に、限られたリソースを使ってやるべきことなのか？」というのは、常に自問するべきだし、仮にやらなければいけないことだったとしても、それは本当に自分たちがやるべきなのか、他の誰か(たとえば開発者やデザイナや企画者が責任を持つべき部分というのもある)がやるべきなのか、外部のベンダーにアウトソーシングするほうが良いのか、などなど、テストをする内容によって、最適な手段は変わると思うのです。

テストを実施するときは、つねに、そのソフトウェアサービスにとって、どこが秘孔となるのかを見極める努力が必要だと思うのでした。

『テストから見えてくる グーグルのソフトウェア開発』 その3

グーグルのソフトウェアテスト本のメモ、その3

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

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

テストエンジニアとは何をする人なのか。エンジニアやソフトウェアエンジニアインテストとは、どう役割が違うのか。どのような素質が必要となるのか。そういったことが書かれている。
しかし、やるべきことが職務としてかっちりと決まっているわけではなく、担当する製品によっても、業務内容は大きく異なる印象を受けた。コーディングをする人もいれば、しない人もいる。ただ、コーディングをしないからといって、素養が要らないわけではない。TEはユーザとしても一流であり、かつ、内部構造のことも誰よりも知っていなければいけないからだ。

ユーザとしての目線、そして、開発者としての目線から、ソフトウェアのリスクを取り除くことが、求められる役割である。

以下メモ

・TEが注目するのは、ユーザへの影響とソフトウェア製品のミッションに対するリスクである

・コーディングもある程度は求められる。TEはデベロッパが尊敬するような技術的スキルと、ユーザのためにデベロッパを抑制するという要素をミックスしたものである

・開発サイクルの初期からTEがチームに加わることは無い

・TEは究極的には、設計のまずさ、わかりにくいUX、バグ、セキュリティやプライバシーの問題などから、ユーザや会社を守ることを職務としている

・TEは仕事柄広い範囲の人々とやり取りをすることが多いため、チームで最も有名なメンバーになっていることが多い

・TEの仕事をうまく行うためには、洞察力とリーダシップが必要となる

・TEは柔軟な態度で、製品チームの文化や現在の状況に、すぐに溶けこまなくてはならない

・ACC＝アトリビュート・コンポーネント・ケーパビリティ。これはグーグルのテストのベストプラクティスをまとめたもの

・アトリビュートは、システムの形容詞に相当する。形容詞とは、すなわち、製品の存在価値のこと。たとえば、クロームならば「高速で安定したセキュアな製品」となる。そして、テストをする際は、それらの性質のことを忘れてはならない

・コンポーネントは、システムをつくり上げるために不可欠な部品(＝コード)のこと

・ケーパビリティは、ユーザからのコマンドを受け付けた時に、システムが実行する動作を表している。すなわち、入力に対する応答。

・ACCの原則
文章は書き連ねず箇条書きにする。
売り込まない飾りなし。
テストプランは、どのようなテストを書く必要があるのかがわかるようなものでなければならない

・テストのプロとして、製品を理解していないというのはありえないこと

・ケーパビリティは、一般にユーザのためのものであって、ユーザから見てシステムがどのようになっているのかが伝わるように書く

・ケーパビリティで最も大切なことは、テストできることである

・ケーパビリティを書くコツ

• ケーパビリティは行動として書かなければならない
• ケーパビリティはある程度抽象的にしておいて、具体的な解釈は、各テスタに任せる方がカバレッジが上がる

・テストケースは固定的なので、繰り返すうちに必ず飽きる。一方、ユーザストーリなら、十分な自由が与えられているので、テストが面白くなり、退屈さから生じるミスも減る

・リスクを数値化するのは難しい。グーグルでは、リスクを「頻度」と「インパクト」の2つに煮詰めて考えている

・リスクは絶対的な数値ではなく、定性的な数値として評価したほうがリアルである。

・値を選ばせるときは、偶数を選ばせる。というのも、奇数だと、中央値が選ばれがちだから

・リスクの「頻度」と「インパクト」を表にしたものを、リスクマップとよんでいる。グーグルでは、リスクマップを各ステークホルダに作ってもらうことが多いが、このとき「作って！」とお願いするのは、あまりうまくいかない。賢い方法としては、まず、こちらが作ったシートを提出して、「これでいいかな？」と聞くことだ。彼らは仕事はやりたがらないが、口出しはしたいのである

・文章によるテストプランは、あまりいらない。文章は時間が経つと内容に意味が無くなってくるから。テストプランを作るなら、ケーパビリティとリスクマップで十分である

・ツール：GTA(グーグルテストアナリティクス)

・リスク分析、リスクマネジメントが、テストのやり方を進化させていくためのテーマ(なのかもしれない)

・グーグルのTEはテストによるリスク緩和を促進する

・TEは、手動テスト、探索的テスト、ドックフードユーザ、βユーザ、クラウドソーシングといったツールを使える

・TEはすべてのリスク領域を理解し、自分が使えるすべてのツールを駆使して、リスク緩和策を作らなければ行けない

・ハイリスクコンポーネントに含まれるすべてのバグには、リグレッションテストを用意しなければならない

・「狼が来た」と言い過ぎるTEは、いずれ耳をかしてもらえなくなる

・探索テストを効率的にやる考え方として「ツアー」という概念がある。詳しくは、Exploratory Software Testingという本を参照のこと

・テスターが多い場合は、とりあえず、ツアーのガイドを書いてテスターに渡すのも効果がある

・ツール：GTCM

・バグの増加率がチームのバグ修正能力を超えると、開発チームは機能の追加を停止するべき

・ツール：Issue Tracker

・用語：スタックトレース→プログラムの実行過程を記録すること。

・ソフトウェアのテストを体系的に教えている大学はほとんどない。そのため、コーディングスキルを備えている人は少なく、採用が難しい

・グーグルが求めるTEの素養とは、技術を知っているだけでなく、ユーザのことを考えられ、システム、エンドツーエンドの観点から製品を理解できることである。また、彼らは、容赦なく、交渉に優れ、創造的で、曖昧さを処理できる

・グーグルでのリーダーシップとは海賊のリーダーシップである。海賊を動かしているのは、海賊という生き方であり、金でも恐怖でもない

・グーグルでは、指導とマネジメントとは、部下に命令を下すことではなく、部下をメンタリングし先導することだ

・ツール：BITE(Browser Integrate Test Enviroment)
起動すると、バグの箇所を強調表示したスクリーンショット、操作ログ、環境情報をまとめて送信するシステム

・BITEを使った多人数による探索テストをやっている
具体的には、サーバが各テスタにテストすべき内容とそのURLを送る。その項目のテストが終わったら、不畳サーバからURLとテスト内容が送られてくる。不具合が見つかったら、BITE経由で報告

・アトリビュート(「早い」とか「セキュア」とか)に注目してテスタにテストを割り振ると、うまくいくことが多い

・コストゼロのテストを目指している。具体的には

• コストがほとんどかからない
• 瞬間的にテストの結果が出る
• ほとんど、あるいは、全く人が介在する必要がない
• 柔軟性が高い。大きいテストも小さいテストもできる

・製品チームにアサインされた時に、まずやることは、自分自身がユーザとなって製品に触れること。
その後、ドキュメントを読む。なんでもかたっぱしから読む。
その後、バグの数やタイプを調べる。
それが終わったら、今度はチームについて。どのようにコミュニケーションをとっているのか。テスターに何を求めているのか。

・TEの影響度をどのように計測しているのか？→残ったまま顧客にみつかってしまったバグの数

・高水準なスモークテストは最小限に抑え、出来る限り小さなテストを書くべきである

・ツール：pdiff

今週気づいたこと

スマホアプリの品質管理の効率って、なんだかんだ言っても、結局は、所持してる端末数と無線LANの品質によるよねっていう。

テスター一人につき端末は3～4台は欲しい。あと、業務で使う無線LANがゴミだと、一日の業務のうちの30～1時間はダウンロード待ちに使ってる気がする。

コンシューマゲーム、オンラインゲーム、ガラケーのゲーム、スマホのゲームと、いろんなQAのやってきたけど、ガラケーとスマホは、ネットワーク遅延のストレスが半端無くて面白くないです。なんか良い方法ないんすかねー。iPhoneやandroid端末を強制的に有線でつなげたり出来るといいんですが(それで遅延が解決するのかどうかは要検証ですけど)

QAの、正直、しんどい

QAやってると、ツールもそろってなければ、関係者(開発者とか企画とか偉い人とか)の品質やQAに対する意識が低い環境で仕事をやらざるを得ない時があります。

今までは、「ツールを揃えよう！」とか「コミュニケーションで、みんなの意識を変えよう！」って頑張ろうとして、結局うまく行かず不満を貯めこむことが多かったのですが、これからは、ちょっと、考え方を変えることにしました。

例えば、僕が医者だったとして。
エリート医師の集まる最先端の病院・研究所でやる医療と、水も電気もなく、医学ではなく霊的なものを信じている村落のような場所で行う医療とで、「どっちのほうが良い」とか「どっちのほうが偉い」とかって、簡単には決められないと思うんですよね。
確かに、後者の村落の方は、非効率的だし、高度な治療はできないだろうし、医療行為とは関係ないところで邪魔が入ったりしそうだけど、でも、医者としてやれることって、ちゃんとある気がします。「こんなんじゃ、何もできねーよ」と文句を言い、何もしないのも一つのスタンスとは思いますが、目の前の出来ることをやりつつ、そして可能ならば、道具を揃えたり、周りの意識を変えたりして、現状を改善していく方が、自分自身も前向きな気持ちになるんじゃないかなと。

QAに話を戻すと、そりゃ、僕だってグーグルのような環境でQAやってみたいですけど、今、僕が居るのはそうではないわけで。とはいえ、環境に文句言うのも虚しいし、かといって、すぐに環境を変えたり移動したりも難しそうだから、現状を受け入れてやれることをやってみる方が、ストレスたまらない気がしたわけです。いやまぁ、改善は常に考えますし、どうしようもなければ、移動も考えますけどね。

以上、どんな環境でも、同じテンションで仕事が出来るようにするための、個人的な考え方でした。まる。

実力者はみんなジーターみたいな人格者だったらいいのに、の件

僕の中で「デニス・ロドマン問題」って呼んでる問題があるんですけど。

具体的に言うと、「有能で組織に利益はもたらすが、素行が悪くチームメンバには悪影響ももたらす存在と、どのように接するのか」という問題です。あ、デニス・ロドマンが何なのかは、適当にググってください。元NBAの選手です。スラムダンクの桜木のモデルにもなったらしい。

このような問題に答えはないと思うし、自分がそいつの同僚なのか部下なのか上司なのかクライアントなのかによっても変わってくると思いますけどね。

よくあるパターンとしては、実力はあるけど、口が悪い人。無能が許せず人前で他者を罵倒し、周囲を委縮させるタイプ。たたき上げのマネージャに多い。利益は産むし、組織の上層部からは信頼を得ている、けど、周囲の人間は疲弊していく。

実際、どうすればいいんでしょうね。
道徳的な説得とか通用しないだろうしなぁ。
強硬策としては、音声レコーダ持ち歩いて言動を録音しといて、しかるべきところに持っていくとかでしょうか。まぁ、組織によっては握りつぶされて、自分の居場所がなくなる可能性もあるけど。
あとは、「お前とお前の家族、夜道には気をつけろよ」ってやんわりと言うのもありかなと思ってます。今のご時世、その気になれば、合法的な範囲or違法だけどバレ難い方法とかで、いくらでもいやがらせできますからね。攻撃をする人間は、たいてい、自分が攻撃されることを想定していない。
あとはまぁ、見て見ぬふりってのもあるよね。時間が解決するというか、そいつがそのうち組織から居なくなるかもしれないし。

なお、僕のアプローチは、「とりあえず、そいつと飲みに行ってみる」です。無法者とは、リングの上で戦うのではなく、あえて場外乱闘を仕掛けていくスタイル