『テスト担当者を悩ませる、10の難題克服法』 その2

前回に続きまして、以下の本の各論のメモ

テスト担当者を悩ませる、10の難題克服法

第1章 テストによって、テスト担当者もテストされる

ソフトウェアテストの担当者は、テストスキルと調整力が求められる。
仮に、調整が全く出来ないテスト担当者が居たとすれば、その人は、残業まみれの生活を送るはめになり、リリース後に障害が出た時のスケープゴートとなる運命にあるでしょう。

テスト技術者が抱える問題の多くは、人間関係であり、その問題を解決できるかどうか、優れたテスト技術者かどうかを決める要因だと思うのです

以下メモ

・テストはソフトウェア開発プロセスの最後のアクティビティである。そして、プロジェクトは必ずと言っていいほど予定よりも遅れるため、テストが手抜きにされる可能性は極めて高い

・よくある誤解 1
テスト担当者はリリースを遅らせている

・よくある誤解 2
開発者の中には、本末を転倒させて、部分的に完成したプログラムをテストに回す人がいる。テスト担当者が問題を見つけてくれることを期待してのことである。ずさんなコーディングをしながら、質の高いシステムを開発したとの名誉を期待してるのであろう。
(まぁ、大抵の場合、バグ修正のそばからバグを生み出す結果となり、蟻地獄になりますが)

・よくある誤解 3
リリース後に見つかった欠陥はテスト担当者の責任である。

・よくある誤解 4
開発者にはトレーニングが必要だが、テスト担当者にトレーニングはいらない
(なので、会社によっては追い出し部屋のような扱いをうける…) 　

・開発プロセスが予測可能であるならば、テスト担当者がテストを行い易くなる。なぜならば、開発プロセスの強味と弱味がわかっており、テスト担当者は弱みに焦点を当ててテストの労力をつぎ込むことができるからである

・顧客の参加度合いが強ければ、低コストで高品質なソフトウェアに繋がる

・テスト担当者が現在直面している最も困難な問題や挑戦的な課題は、他の人々との人間関係にあるように思われる

・テスト担当者は、従来、テストに関する教育をほとんど、またはまったく受けていない。しかし、テスト担当者は育成されるのであって、うまれるのではない

・経営管理者がテストに本気で関心を払っているかどうかを、テスト担当者の多くは予算を指標にして判断している。

・テスト担当者が悪いニュースの担い手である場合、テスト担当者は敵視される

第2章 テストの現状の自己評価

この先、一流のテスト技術者となり、また現在の組織で評価をされたいのであれば、まずは自分のスキルセットや、業務プロセス、組織内での立ち位置をなるべく客観的に把握する必要があります。

この章には、評価記入シートがあり、このシートを使うと「自分がどのレベルなのか」「現在の組織は、どれだけテストのことを重要視しているのか」を定量的に測れるようになってます(僕はまだやってないけど)。

以下メモ

・ある有名な児童小説の中に、「行き先がわかっていないのなら、どの道をいっても同じこと」という下りがある。
この教訓は、人生におけるあらゆる改善計画の基礎となる。

『テスト担当者を悩ませる、10の難題克服法』 その1

テスト担当者を悩ませる、10の難題克服法

本書の帯には「肝心なのはテストのヒューマンスキルだ」という文言が、デカデカと書かれている。
その言葉が示すように、この本では、ソフトウェアの技術的な話ではなく、テスト担当者が直面しがちな、組織的・社内政治的な問題への対処法や心構えのようなものが記されている。

テスト技術者は、様々な「誤解」と戦わなければならない。テスト技術者ほど、会社や組織によって、扱いが異なる職種も無いのではないだろうか。品質を守るための最後の砦となることもあれば、リストラ対象者の追い出し部屋扱いのときもある。

もし、あなたが優れたテスト技術者だったしても、今いる組織がそのスキルを十分に理解してくれるとは限らない。そんなとき、組織と社内政治の荒波をうまく泳ぎ切るためのヒントが、本書で得られるかもしれない。

なお、10の問題は以下の通り。ある程度、経験を積んだテスト技術者であれば、下記の「問題」の一覧を見ただけで、自分が今まで直面した問題の数々が思い浮かんで来るかもしれない。もしそうでなければ、あなたは、環境に恵まれた幸せなテスト技術者だと思います。

あ、各章の詳細は、また後日…

• 難題10位：テストに関するトレーニングを受けること
• 難題9位：開発者と良好な関係を築くこと
• 難題8位：ツールを使用せずテストすること
• 難題7位：経営管理者にテストについて説明すること
• 難題6位：顧客およびユーザとコミュニケーションを取ること
• 難題5位：テストの時間を確保すること
• 難題4位：投げ渡されたソフトウェアをテストすること
• 難題3位：動いている的を射ること
• 難題2位：どちらに転んでも損する状況と戦うこと
• 難題1位：「ノー」ということ

『テストから見えてくる グーグルのソフトウェア開発』 その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端末を強制的に有線でつなげたり出来るといいんですが(それで遅延が解決するのかどうかは要検証ですけど)