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

作者: ジェームズ・ウィテカー,ジェーソン・アーボン,ジェフ・キャローロ,長尾高弘
出版社/メーカー: 日経BP社
発売日: 2013/05/23
メディア: 単行本
この商品を含むブログ (9件) を見る

第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