テストの秘孔

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


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

  • iOS,Androidともに直近の3バージョンで場合分け
  • 各OSともキャリアによって場合分け
  • メーカによって場合分け(仮に5メーカとする)
  • 電波の強弱によって場合分け

と言った具合に、ぱっと思いつく限りでも、上記のパターンで分類することができ、たったの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のやってきたけど、ガラケースマホは、ネットワーク遅延のストレスが半端無くて面白くないです。なんか良い方法ないんすかねー。iPhoneandroid端末を強制的に有線でつなげたり出来るといいんですが(それで遅延が解決するのかどうかは要検証ですけど)

QAの、正直、しんどい

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

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


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


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


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

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

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


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

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


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


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


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

品質管理の世界の職種

僕はソフトウェア(主にゲーム)の品質管理業務に携わってますが、ひとくちに、ソフトウェアの品質管理業務といっても、いろんな職業・役割があります。

品管の世界にはどんな職種があって、どんな仕事をしているのか、僕が見てきた限りで挙げてみるテスト。

テスター

仕様書やテストケースを元に、手動で製品を操作し、仕様書と異なる挙動をした場合にレポートを制作するのが主な仕事。テストケース(どんな手順で対象のソフトウェアをチェックするのかを記したドキュメント)作成することもある。
ネット上では、「ひたすら村人に話続けたり、ひたすら壁にブツかってコリジョン抜けを調べる、地味で退屈な仕事」と認識されている。まぁ、そういう一面もあるが、当然、それだけではない。
製品に対する理解力、文章力、想像力、洞察力、器用さ、反射神経(特にゲームの場合は)などが求められる。
個人のセンスによって生産性が大きく異なるのが特徴。


テストリーダー

テスターの上位職。テストスケジュール作成、テスト結果の分析、テスターへの指示、テスターの指導などを行う。
開発中(つまりテスト中)のソフトウェアって生き物なので、テスト出来る個所とテストしても意味の無い箇所がコロコロ変わるのだけど、それらの状況を正確に把握して、無駄なくテストを実施するのが使命。
ちゃんと作戦を立てて、それでいて、目の前の状況を最優先にして、行動を選ぶセンスが必要。
例えて言うと、徳川埋蔵金の時の糸井重里みたいなもん(古い)。文献とか地質とか出土品を参考にして、どこを掘るのかを決める人。

テスターとしての基礎力はもとより、コミュ力、指導力、情報収集力、柔軟性などが必要となる。また、ソフトウェア開発のフローを知っており、コードが書けるとなおよし。


テストエンジニア

ITの力でテストを効率化する人。ソフトウェアテスト業界で、今、最もホットな職種の一つ。
発展途上・研究段階の分野であり、これといったスタンダードがまだない。まぁ、JenkinsつかってUnitTestを自動化したりするのがポピュラーか。あとは、ツールによる支援とかですかね。

プログラミングスキルは当然のこととして、先端分野なので、どうしても英語が必要になるシーンが出て来る。


QAコンサルタント

テストリーダが具体的にテスト業務を捌くことにフォーカスしているとするならば、QAコンサルタントは「品質」にフォーカスする。
「品質とは何か?」を定義し、それを良くするためにはどうしたらよいのかプランを立て、関係者を巻き込んでドライブしていくお仕事。課題発見力&解決力が必要となる。あとは、パワポスキルもか。テストチームだけでなく、開発チームとも深く関わる。

品管のことをよく知らない人に説明する際は、「スポーツジムのトレーナみたいなもの」と説明することが多いです。
「健康とは何か?」を定めて(適性体重なのか生活習慣なのか、答えは人それぞれ)、その定義した「健康」に近づくために、何をすればよいのかをアドバイスする人。

大事な点としては、品質に責任を負うのは、あくまで開発者側であり、QAコンサルタント職ではないということ。ここを取り違えると、バグを出し続けているのに、その責任をQAに押し付ける開発者を生み出すことになり、製品の品質も低下し、開発者のレベルも上がらず、開発側とQAの関係性も悪くなるという負の連鎖が生まれる。




以上。
オンラインゲーム風に言えば、テスターが基本職で、テストリーダ、テストエンジニア、QAコンサルはテスターの上位職って感じでしょうか。

あと、いずれの仕事も「仕事の成果が直感的にはわかり難い」ので、評価面談の時ちゃんと考えてアピールしないと、評価があがらない(給与が上がりにくい)印象。「売上を上げました!」とか「ユーザ数増えました!」とか「新しい製品作りました!」みたいな、誰の目にもわかりやすい成果は出ないからね。

エクセルで数値をでっち上げて、パワポで綺麗に見せる技術は、品質管理で働く人にも必須でございますよ、旦那。

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

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


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

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

第1章 グーグルのソフトウェアテストの世界へようこそ

ざっくりとグーグル内のデベロッパは、「ソフトウェアエンジニア(SWEと著書では略される)」「ソフトウェアエンジニアインテスト(SET)」「テストエンジニア(TE)」にわけられる。そして、プロダクトの品質を担保するのはSWEの仕事であり、TEやSETが責任を追うものではない。
SETやTEが、具体的にどんな仕事をしているのかは、2章以降で語られる。

以下メモ
マイクロソフトがテスターの地位を上げた。マイクロソフトもテストに関する本を出している、が、グーグルとのアプローチは全然違う

ソースコードの品質はSWEが責任を追うものである。

・品質とは、開発とテストを互いに区別できなくなるまで融合することで実現される

・品質とは見つけるものではなく、守るもの

・SWEの仕事とは、ユーザが触れるプロダクトを作ること

・SETの仕事とは、SWEが品質を保つために必要なツールを作成したり、自動化をしたりして、SWEが効率よく高品質なコードを書くためのサポートをすること

・TEの仕事とは、テスト結果の解釈やテストの実行を指揮すること。ユーザ寄りの目線でテストをする。

・SETやTEは組織横断型であり、特定のチームに所属するわけではない。その理由として、テスト分野のイノベーションを会社内に浸透させるには、イノベータがいろんなチームで仕事をすることが望ましいためである。また、チーム間の異動が多いため、仕事に飽きが来ることがなく、モチベーションを高く保つことができる。

・一般的なテストの用語の、ユニットテスト結合テストシステムテストを、グーグル内ではそれぞれS,M,Lテストと呼んでいる

・テストは可能な限り自動化されているが、手動のテストもそれなりにやっている。ただ、常に自動化の余地が無いかどうかはチェックしている。「人間の思考の一歩手前まで、自動化」がポリシー



第2章 SET(ソフトウェアエンジニアインテスト)

SETとは、いったい何者でどんな仕事をしているのかが語られている。

SETとは、素養としてはデベロッパであり、コードを書くことが求められる。と同時にテスターとしての素養も必要であり、各種関数やコンポーネントが、どんな使われ方をするのか想像を巡らせ、どのようなテストをクリアすれば、そのコードが安全といえるのかを理解している必要がある。
SETはテストの自動化を支援し、テスト駆動開発のお作法のようなものをSWEに教育し、SWEが効率よく高品質なコードを書くためのサポートをするのがミッションである。


以下メモ
・シンプルを保てば、安全は保たれる

・グーグルではテスト駆動開発を実践している

・SETの昇進コースはSWEと同じ

・品質は、ソフトウェアが重要になるまでは重要ではない。したがって、SETは優先度の高いプロジェクトにコミットされる

・SWEは関数単位、コンポーネント単位の比較的狭い視野で判断を下す傾向にあり、SETはシステム単位の広い視野で判断を下す傾向にある

・SETは広い視野で製品を見ているというアドバンテージがある。そのため、コードの再利用パターンや、コンポーネントのやり取りの設計が得意である

・テストを自動化する際は、「何を自動化するのか」をまず考える。規模が大きければ良いというものでもない

・SETの仕事を一言でいうと「テストのし易い環境を作る」ということ

・グーグルでは、コードを書くことよりもレビューすることのほうが、ずっと大切なこととして扱われる

・「テストの自動化」とは、テストプログラムの実行、結果の分析、格納、レポーティングのことである

・Sテスト(ユニットテスト)は、コードの品質向上に役立つ。Mテスト(結合テスト)、Lテスト(システムテスト)は製品の品質向上に役立つ。製品の品質を見る際は、「使いやすさ」や「スピード」といった目に見えない機能も無視してはならない

・プロダクトの種類によって、SMLの比率を変えている。ユーザに近いプロダクトは、MとLが多め。インフラ系やデータ操作が中心のものはSが多め

・テストは、結果だけでなく、「どこで失敗したか」がわかるような仕組みにしなければならない

・バグデータベース:buganaizer

・ブラウザ自動化:selenium,WebDriver

・社内ツールとかはDDD(欠陥駆動開発、Defect Driven Development)でやってもいいかもしれない。
DDDとは、実際に使ってるユーザが困ってるバグから治していくというスタイル。ということは、誰も気にしないバグは直されない