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

続き！ようやく折り返し

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

7章 難題第6位 顧客およびユーザーとコミュニケーションを取ること

社内システムとか、受託開発をする際は、顧客やユーザの意見はちゃんと聞きましょうね、という内容。僕も受託開発のチームに居た頃がありますが、開発チームとクライアントが描いている絵が異なったまま、開発が進んでいくということは、実によく有りました。企画書やポンチ絵段階では、なんとなく同意で来てる風でも、いざゲームや映像というカタチで見せた時に、「いや、こんなんじゃないんですけど」というちゃぶ台返しは、珍しいことではありません。まぁ、プロジェクトマネージャが優秀だと、あまりこういうことないんですけどね。彼らはきっと、クライアントと密にコミュニケーションを取って、一個一個、確認作業をしてたのだろうなと。ちゃぶ台を返されないためには、面倒くさくても、ちゃんとコミュニケーションを取ることが必要なのであります。

でもって、今僕が居るゲーム業界では、サービスはリリースされるまで、顧客やユーザの元には届きません。せいぜいがネットや雑誌による情報提供くらいで、リリース前にゲームを遊んでもらうことは、基本的には無い。ということは、「リリースしてみるまで、それがウケるかどうかわからない」わけで、ここに、ゲーム開発の難しさがあります。ベータ版とかをうまく使うという手もあるけど、ベータ版の評価が悪かったら、正式版リリースされてもネガティブなイメージに引きずられて、結局流行らないからねぇ。難しいものです。ベンダーとか使って、ユーザテストしてみるのが現実的なところでしょうか。ベンダーなら、情報漏えいとかネガティブな意見をネットに流すことは無いだろうし。

以下メモ

・顧客とユーザをはあっくするとともに、そのニーズを満たすための解決策に影響する主要な概念が３つある。具体的には、チームワーク、』コミュニケーション、継続的関与である。これらの３つの要素のどれが欠けても、正しいシステムが開発されたことを確認するための作業に、顧客及びエンドユーザーは効果的に関与できなく成田王

・一般に、合意できない時に、人はコミュニケーションを避ける傾向がある。不一致に対処することは難しい時もあるが、だからといってコミュニケーションを絶つべきではない

・何を言うかだけでなく、どのように言うかも、コミュニケーションの一つである

・ユーザーによる受け入れテストの問題の一つは、システう開発段階の一番最後に行われることが多い点である

・自分たちが行うべきテストのすべてを他者に依存すべきではない

・敵対的な態度は通常は組織の体質に根ざしたものであり、短期的に容易に変えることはできない

・起点とは、敵を作らずに、言いたいことを伝える才覚である

・成功の鍵は分からないが、失敗の鍵は誰をも満足させようとすることである

高校の科目で一番クリエイティブな科目は数学だと思う、の件

QAやってると、自分の担当領域からバグが流出してしまうという経験、避けて通ることはできません。どんだけテストしても出るときは出る。

流出したときの感情は2つあって、ひとつは「やっちまった！」で、もう一つは「なるほど！」です。

イチ組織人としては「やっちまった」なんですが、イチテスト技術者としては「なるほど、そういう観点があったか！」という、どちらかといえば嬉しい気づきの感情があります。そして、それが溜まっていくことで、良いテスト技術者になっていくのだと思います。

とはいえ、組織人としては、「なんで、お前らこのバグ流出させとんねん」と偉い人たちから詰められることが良く有ります。まぁ、理由は複合的で、企画がミスった、開発がしょぼい、テスターが素人、そもそも時間がない、とか、そんな感じなんですけど、ことテストフェーズにフォーカスして、なぜそのバグを事前に見つけることが出来なかったのかの理由説明で、僕がよく持ち出す喩え話に、将棋の話があります。

将棋をやってると(まぁ、麻雀でもいいけど)、後で、「なんでこの手に気が付かなかったんだ！」ということが良く有ります。これには2つの要因があって、ひとつは能力不足、もう一つが時間不足です。
将棋が、なぜ競技として成立してるかというと、それは制限時間があるからだと思うのです。どれだけ、すごい棋士でも、1時間考えた結果に打つ手と、10秒しか考えられない状況で打つ手が、同じとは限らない。だからこそ、毎回微妙なブレが出て、それが、勝敗に繋がっていくのだと思います。どんだけ強い棋士でも、勝率は7割くらいという話を聞いたことがありますが、それは、この時間によるブレがあるからなのではないかなー、と。

テストも同じで、どれだけ能力がある人でも、テストの時間が足りなかったら、目の前のテスト項目を消化することに追われてしまって、大事なテスト観点が抜け落ちてしまうことがありえます。これは、能力の問題ではなく、そういう性質の仕事なのです。ただ、時間が充分にあったからといって、必ずしも漏れなくテスト出来るわけではないというが、これまたやっかいなんですけどね。

テスト観点というのは、まぁ、機械的に網羅できる部分もあるけど、「そうでない部分」もたくさんあって、「そうでない部分」というのは、その人の「発想」が頼りだったりします。この条件で、この機能使ってみたらヤバいんじゃね？的な。そして、この発想が産まれるには、その人の能力と、そして時間が必要になります。

で、発想ってのは、数学の問題を解いたり、難易度の高いプログラムを組んでる時に、経験することが多いので、理系の人は意外とわかってくれるのですが、文系の人はイマイチピンと来てくれない傾向にあります。なんか、文系の人ほど、ロジカルシンキングかぶれが多くて、「発想」というものに理解を示してくれない気がする。ロジカルに考えれば、すべて解決できると、どこかで思ってるよね。一部の人は。

なんか、微妙に愚痴っぽくなってきたので、まとまりないけどこの辺で。
テストって、ロジカルな部分とクリエイティブな部分があるんだけど、クリエイティブなところって、まわりから全然理解されてないよなと思うことが、最近多かったので、書いてみました。

『テスト担当者を悩ませる、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つの属性がある。機能と構造と品質である。

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

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

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