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

まだ、第7位！レビューしたい本は溜まっていく一方…

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

第6章 難題第7位 経営管理者にテストについて説明すること

テスト組織はコストセンターである。やたら人はいるが、何かを産み出しているわけではない。そのため、(無知な)経営層から見ると、「コストはかかってるが、結局、どんな価値を産み出しているのか？」というのが見えにくい(ようだ)。

経営層がテスト組織に対する理解をしていない場合どうなるかというと、不具合だらけのプロダクトが出来上がったときに、その責任をテスト組織に求めてきたりするし、景気が悪くなってきた時に内部のテスト組織を解体して(要はリストラして)、アウトソーシングに頼るようになったりする。

テスト組織を守るため、ひいては自分のポジションや雇用を守るためには、経営層への説明は、テスト実施と同じくらい、大事な仕事の一つだと思います。なので、それが出来る人がテスト組織を率いるべきでしょう。極論を言えば、テスト組織を率いる人は、プレゼン上手がなったほうが良く、優れたテスターである必要は無いと思っています(当然、知識は必要ですけどね。テスターとして優れてなくても良いってだけで)。

以下メモ

・(良いチームは)プロダクトよりもプロセスを重視する

・経営管理者がテストをプロジェクトの最後にスケジュールする場合、そのプロジェクトは最悪の失敗に陥る可能性がある

・経営管理者層から最もよく聞かれるコメントは、「なぜその点をテストしなかったのか」である

・欠陥品を納期通りに納入しても、欠陥品であることに変わりはない

・経営管理者がプロダクト指向である間に、テストプロセスを成熟させようとすると、苦戦をしいられることになる(今、僕が置かれている状況がまさにこれ…)

・（テスト組織にとって）重要な事は、同じ内容を繰り返し伝えるがために、無視される事のないようにすることである。もう一つ重要なことは、いつも不平を並べ立てるものとして見られないように、肯定的な内容を伝えることである

・テストの目的は欠陥を発見することなのか、それとも正しいことを証明することなのか、を定義しておきましょう

・品質にはすべての人が関わるべきだが、その責任は経営管理者にある

・成功を収めているテスト組織は、先週、先月、昨年にそれぞれ発見された欠陥の数を把握している。そのような組織では、欠陥を発見することにより、どれだけのコストが節減されたかを、経営管理者が認識できるようにしている。

第一印象いいもの同士

最近は、採用のお仕事とかもしているのですが、面接って本当難しいですよね

面接のときは、当然、経験やスキルも見るんですが、実は一番知りたいのは「勤勉さ」「素直さ」「優しさ(相手のことを想像できるか)」という、なかなか、わかりにくいモノだったりします。つまり、客観的に測ることが難しい指標を一番重要視しているのが現状。しかも、それらを、たかだが一時間の面接で見極めないといけないわけですから、ほとんど無理ゲーに近い。

どんな質問をしたら、その人の為人がわかるのか、あれこれ考えてるのですが、今のところ、「送別会の時に何をもらったか」と「最近、寄せ書きをもらったことがあるか？そこにはなんて書いてあったか？」が、一番、答えに近い気がしています。

送別会にもらう品も寄せ書きも、他者によるその人のエピソードが詰まっているので、割りと対象者のパーソナリティを客観的に測れるんじゃないかなと。だから、もし面接の時に持ってくるものを指定できるのであれば、寄せ書きとか送別の品を持ってきて欲しいなぁと考えてたりします。それか、紹介状ね。できれば現職の職場の人からの。紹介状すら書いてもらえない人は、ま、いろいろとダメでしょうし。

採用にもう少し権限を持てたら、このあたりやってみたい。応募する側は面倒くさいでしょうけど

あとよぉ、勤怠悪いやつってどうやって見極めたらええんや…。

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

このペースだと、「その12」くらいまでいきそうなイキフン

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

第5章 難題第8位 ツールを使用せずにテストすること

ツールがどれだけ充実しているかが、そのままテストチームの効率性とか高度性みたいなものに直結している気はする。言い方を変えれば、ツールが充実しているテスト組織ほど、「イケてる」組織ということです。

まぁ、あとは、結局ツールは道具なので、どれだけ使いこなせるかが大事ですよね。どれだけ良いツールを買ったとしても、使いこなせなかったら意味が無いし、場合によっては、効率が悪くなることだってありえます。なので、ツールを導入する際は、「そのツールで何が出来るか」も大事ですが、「そのツールを使いこなせる人材が組織に居るのか？」という視点も大事だなぁと思うわけです。例えば、組織の中に誰ひとりとして英語が読めないのに、英語のツールを買ってもしょうがないよねっていう。

個人的には、自動化ツールとか旬だし興味があります。でも、僕のいるゲーム業界では、あまり話は聞きませんねぇ…。まぁ、ゲームは自動化とはあんまり相性良くないのかもな。
また、会社の偉い人たちは、「自動化」と聞くと、それこそクルマの自動運転みたいに、「何から何まですべてをコンピュータがやってくれて、人間は何もしなくても、バグを洗い出してくれるモノ」って勘違いしがちなので、コミュニケーション取るときは注意しなければならないことが多いです。現状、自動化は、あくまで、一部の項目を自動化するレベルであり、クルマで言えば、ギアの切り替えを勝手にやってくれるオートマ機能くらいのものです。ゲームだと、メモリリークとか処理落ちとか、特定のバグを見つけるのに使ったりしますね。どっかの記事で読んだ話ですが、ナムコの鉄拳では、ひたすらランダムキャラ、ランダムステージででCPU同士を対戦させて、処理落ちするところを洗い出してたらしいです。で、処理落ちした瞬間の画面を自動でキャプチャしてメールで配信してたとかだった気がする。素敵な自動化の仕組みを考えたものだなぁと関心しました。

以下メモ

・テストは単純な作業の繰り返しが、どうしても発生してしまう。そして、その退屈さがテスタの油断を産み、重大なバグを見逃してしまう。その課題に対する解決策は、作業にあった適切なツールを適切なプロセスと組み合わせて使用し、使用する人を適切にトレーニングすることである

・ツールだけでは何も解決しない。ツールをプロセスに組み込む必要がある

・テストに固有な特性の一つに、テスト担当者が同じことを繰り返し実行する、という点がある。

・手作業によるテストは…
1.正確性および信頼性が低い
2.退屈である
3.手間暇がかかる

・一部のテスト・タイプの中には、自動化が適さないものがあることを、理解することが重要である

・テストケースジェネレータ(ウチの組織にも導入してみたい)

・ツールの有効性はツールを使用する人と同水準でしか無い。

・ツールを有効活用するためには、優れた管理方法及び技術方法が不可欠である

・ツールの不足を自分の肉体的な能力で補おうとしてはならない。ツールの予算を認めないならば、テストできる量が少なく、テストの進捗が遅く、テストの効率が悪くなることを、経営管理者は覚悟をするべきである

・有効なプロセスと併用せず、トレーニングを受けていない人がツールを使用することは、悪いテストを早くすすめるだけである。

・1本の木をハンマーで切り倒すことは可能だが、約30日かかる。ハンマーを斧に取り替えれば、30分で切り倒せる。30日と30分の差がスキルである

・組織内で真剣にツールを使用しようとしているならば、プロセスに不可欠な一部としなければならない

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

引き続き、以下の本のメモ

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

第4章 難題第9位 開発者と良好な関係を築くこと

「品質は、後から付けるものではなく、最初から作りこまれなければならない」っていう言葉をどっかの本で読んで、まさしくその通りだと思うのですが、それを理解していない関係者は結構多い(企画やデザイナなら、まぁまだわかるが、プログラマにも居る)。そういう人たちは、品質とはテストチームが責任を追うべきものであると認識しているように思える。

高品質なソフトウェアは、関係者全員が品質に対する高い意識を持たないかぎり、なかなか達成されない。誰か一人でもいい加減な奴が居れば、品質はそこが基準となってしまう。

どうにも「QA(品質管理) = テスト」のイメージがあるので、テストを行えば品質が保証されるという誤解があるのかもしれない。
僕はそのような誤解をしている人に対しては、「QAチームは、観察と報告しか出来ません。言ってみれば、スポーツジムのトレーナです。対象の人の健康状態と、それを改善するための方法をお伝えするのが仕事です。大事なのは、実際に不健康なのはあなただし、それを改善するのもあなただということです。我々は医者ではないので、直接的に手を動かして、何かを改善することはできません。」というような話をして、QAチームの役割をイメージしてもらいます。

そして、観察と報告しかできないというQAの業務の性質上、その報告先の相手とは、良好な関係を築いている必要があります。簡単にいえば、こちらの意見の聞く耳を持ってもらうということです。ただ、QAの報告とは、大抵の場合が「悪いニュース」であるので、伝え方には充分気をつけないと、たんなる嫌味ったらしい奴らだと思われてしまい、誰からも評価されなくなってしまいます。

たとえば、品質が悪いソフトウェアのテストをすることになっても、「バグだらけだぞ。なにしてんねん。はよ直せや」というのではなく、「見たところ多数問題があるようです。このままリリースするとリスクがあると思うのですが、問題ないでしょうか？」くらい落ち着いた口調で、かつ相手に判断を委ねる形式で伝えておけば、開発者との関係性は悪化するリスクは抑えられるはず(リリース判断をQAチームが持ってない場合もよくあるし)。

あと、開発者と仲よかったら、デバッグツールも作ってもらえるしね。

以下メモ

・組織内のだれもが、テストに参加すべきである。なぜならば、テスト結果には共同して責任を追わなければならないからである

・コミュニケーションが悪いことはプロジェクトが失敗する主要な原因の一つである。また、コミュニケーションのチャネルが詰まっていることは、テストにとって決定的に有害である。

・チームは息を合わせて仕事をするものである。他方、グループは必ずしも、力を合わせて仕事をするとは限らない

・チームワークが最も肝要であり、他の関係者ぐぁの視点に立つことも同様に重要である

・自分たち(テストチーム)が成功するためには、他の人たちからの助けが必要であることを理解する

・敵対的な関係から、win-winの関係に移行するために必要なことは、内面的に目覚めることと時間である。

・テストに関連して、人にやる気をなくさせる最も確実な方法の一つは、成果物ではなく作成者を批判することである

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

続・以下の本のメモ

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

第3章 難題第10位 テストに関するトレーニングを受けること

僕も複数の会社で働いてきたが、ソフトウェアテストに関して、体系的なトレーニングを実施している会社は無かった。

大抵の場合は、配属されて3日めくらいに一番簡単なテストケースを渡されて、「これを上から順番に消化していってね。もし、わからないことがあったら聞いてください」という感じでした。また、デバッグツールの使い方も時間を割いてレクチャされることはなく、「○○をするにはどうしたらいいんでしょう？」と質問して初めて、それを実現するツールの存在と使い方を知ることになるのです。

そして、それなりのテスターを養成するには、それで充分という現実もあったりします。テストは、テスト対象のシステムを使えさえすれば、務まる仕事がそれなりにあるからです。世の中のテストベンダーが繁盛している理由の一つが、安い賃金で人を集めて、特別なスキルを持たない人でも、役に立てる仕事を供給できるからであり、それがソフトウェアテストの特性の一つかもしれません。

ただ、効率的で効果的なテストを設計し実施するためには、コンピュータサイエンス的な面や、ソーシャルスキル面で、ちゃんとしたトレーニングをした方が良いと思います。まぁ、経験でカバー出来る面も大いにあるけど(そして、大抵のテストリーダは経験ありきで、キャリアを積んでいる)、それは、前近代的な「背中を見て学べ」的な職人の世界みたいなもんで、学習の効率があまり良くないし、個人の特性に大いに左右されてしまいます。

自社のテストチームを永続的に結果を出せるチームにしたいのであれば、トレーニングプログラムの開発は必須だと強く思います。

以下メモ

・テストに関して一般的に信じられていることに、システムを動かせる人は、誰でもテストを行える、ということがある。

・テスト実施について、組織内ではたくさんの誤りがなされてきたが、その中で最たるものは、誰でもテストを実施して重大な欠陥を見つけられる、という誤った想定である。

・テスト担当者は欠陥が発生する可能性のある源を認識していなければならない。それらの欠陥の発生源は、摩訶不思議な深淵に潜んでいるのではない。トレーニングを受けたテスト担当者はそういった点をよく知っており、それは次第に増えていく知識の一部なのである

・テスト技法に関する適切なトレーニングを受けなければ、テストを実施して誰でもわかる欠陥を見つけることは出来ても、システム障害の原因となりうる微妙な欠陥を見逃してしまうだろう

・テスト技法について公式にトレーニングを受けたことのあるソフトウェアの専門家は1%にもみたない

・テストの対象となる3つの属性がある。機能と構造と品質である。

・実施するテストの品質と範囲は、リスクをどれだけ洗い出して緩和したいのか、およびソフトウェアの機能と構造をどれだけテストしたいのか（カバレッジ）に、左右される。

・トレーニングを受けたテスト担当者は、テスト計画を記述する方法、テストケースを作成する方法、適切なテスト環境を構築する方法、テストを実施する方法、テスト結果を評価する方法などを習得している。

・緊急なことが重要な事よりも優先されていることは、よくある(テスト担当者がトレーニングを受ける時間を捻出できない理由）

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

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

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

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

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

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

以下メモ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以下メモ

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

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

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

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

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

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

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

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

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