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

ゆっくりですが、完走はする

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

8章 難題第5位 テストの時間を確保すること

ソフトウェアテスト7原則というものがあります。(参考リンク)

そのうちの2つに、「テストは欠陥があることしか示せない」、「全数テストは不可能」というものがあり、これらの原則は、すなわち「有限の時間で完璧にテストするのは不可能」という結論を示しています。

にもかかわらず、実際の現場では、短い時間で完璧なテストを求められることが珍しくありません。テストというのはソフトウェア開発プロセスの最下流に位置するところであるから、締め切りの帳尻合わせとして、短納期での作業を余儀なくされることがままあり、それでいて、完璧なテストを求められたりします。

これらの矛盾は、一言でいえば、関係者のテストに対する無理解から来ていることが多いです。まず、完璧な品質を得られるテストなど、存在しません。そして、テストによって得られる品質というのは、時間を引数とした関数です。短い時間しかテストさせてもらえないならば、その分、不具合が流出するリスクは増加するものなのです。

品質を重視するならば、テストの時間を確保しなければならないですが、そのためには、プロジェクトのステークホルダに、テスト業務の本質を理解させる必要があります。

テスト担当者がやるべきことは、求められる品質を把握したうえで、それを達成するために必要な時間を獲得するための交渉と、獲得した時間を、少しも無駄にしないように、正確にテストスコープを定めることだと思います。

以下メモ

・欠陥があると疑われる部分だけをテストすることができたならば、テストにかかる時間を大幅に削減することができるだろう。しかし、まったく疑わしくないところから、欠陥が見つかることがよくある。

・優れたテスト担当者は、一方通行の道路を横断するときでも、必ず右と左の両方を見る。

・時間の観点から、何がどう進んでいるのかを把握することは、何を実施することが可能か現実性の高い期待を設定するのに役立つ。

・合理的なのは、要求ベースのテストのようなアプローチを用いて、実行するテストケースを絞りこむことである。そうすれば、状況によっては、テストケースの数を何十万から100未満に減らすことが出来る

・テストの品質は、実行したテストの量や速さで決まるのではなく、何をテストしたかによって決まる。

・テストケースに優先度を付ける基準としては、リスクが最適である。

・テストのもっと多くの重要な部分は、ビジネスに関することなのである。テストは、顧客やエンドユーザに提供される、プロダクトの品質を管理することなのである。

・テスト担当者は、テスト対象のソフトウェアの量を制御出来ないことが多い。しかし、ソフトウェアにタイシて実行する、テストの量を制御することは出来る。

・僅かな共通プロセスを用いた小規模なチームのほうが、大規模なチームよりも、効率が良いことが証明されている。

・プロジェクトの末期(更に悪いことには、ソフトウェアのリリース後）に発見された欠陥を修正するには、非常に高いコストがかかる。

『ゲームテスト＆QA』 その1

市販されてるテスト関連の技術書で、今のところ唯一ゲームにフォーカスした本(多分)。5000円という強気のお値段でも有名。

ゲームテスト&QA

ゲームテスターという仕事を始めたばかりの人、あるいは、ゲーム業界での就職を志望する人向けの本で、どちらかといえば初級者向け。専門的な記述少なめ、業界談義多めなので肩肘張らずに読めます。ただ、翻訳本なので海外の話がほとんどですが。

内容は確かにライトなのですが、ゲームテスターという仕事が如何に不安定なのかということをぶっちゃけて書いているので、ゲームQA業界の特に若い人には是非読んで欲しい一冊です。僕は自分のチームの若者には、特にチャプター2とチャプター8は読んでもらって、危機感を煽ってます。

CHAPTER 1 QAとテストの歴史

ゲームの黎明期は、開発者がテストすることが多かったが、ゲームが高度化・複雑化していくにしたがって、テストという仕事が独立するようになった。また、任天堂を初めとしたプラットフォーマがデベロッパに一定以上の品質を要求したことも、テストという仕事が生まれた一つの要因。
テスターに求められる素養も時代によって変化するもので、ファミコン時代とPS4時代では、テストの質もボリュームも全く異なっている。

以下メモ

・QAとテストプレイで可能になること
テストプレイを通じて、ゲーム業界に入る
テスターとして生活する
自分が希望する開発会社や販売会社の正社員になるための近道としてテストプレイを利用する

・任天堂には、彼らが独力で北米に再び喜びをもたらしたこと(※ファミコンが世にでる前に、アタリショックでゲーム業界がめちゃめちゃになった時代があった)、そしてゲームテスターという職業を生み出したことに感謝するべきでしょう

・1985年に人展動画ビデオゲーム市場を復活させた時の主要戦略の一つとして、厳格な品質基準の施行があった

・ゲームのメディアがCD-ROMになったことは、ゲームの表現とボリュームに変化を与えただけでなく、プロジェクトに必要なテスターの人数にも変化を与えた。

・容量が増大すれば、テストプレイの複雑さも増す

・テストプレイの見地からすると、「オープンワールド」のゲームの登場によって、テストがかなり複雑になった。

・ゲームが複雑化することによって、テストプレイは重要な産業になった。

・PCゲームのテストプレイは、コンシューマとは別物である。

・PC用ゲームには多くの問題が起こる可能性があるので、優秀なテスターだけがPC用ゲームのテストプレイを担当することが出来る。

・テスターはプレイするゲームを選ぶ事はできませんし、プレイする仲間も選べない。

・ゲームテストの業界に入る動機のきっかけとして、「ゲームを制作したいから」というのは良い答えです。テストプレイは開発会社の正規雇用に繋がる場合があります。

・一番重要なことは、テスターとして仕事を始めた際に、自分が何をしているのか、自分がどこへ向かおうとしているのかを把握しておくことです。

今週気づいたこと

知ってる範囲のテスト業界の人もそうだし、採用面接に来る人もそうだけど、テスト業界って、理系の人が少ないです。肌感としては、1～2割くらいなんじゃないかな、理系の人(ここでいう理系とは、高校時代に数学物理化学が得意だったという人たちを指す。大学でコンピュータサイエンスとかまで広げるともっと少なくなる)。これ業界の課題なんじゃないかなと思う次第でございました。テストしてる対象のものは、理系の人が作ってるわけですしね。

あ、文系をディスってるわけではなくて、割合が少なすぎやしませんかねぇ、ってことでございます。テストの仕事はロジカルな仕事と、ドキュメント作成と、人付き合いでできてるので、一人で全部出来るスーパーマンを集めるのは難しいとしても、チームとしてはそれらを備えていたいなと。

プログラマをスカウトしてくるのが一番の近道なのかなとは思いつつ、やりがいとかお金の面で、なかなか難しいのが現状ですね。というか、お金の面やね。テストで年収1000万とか、まずお目にかからないし、500万ですら、そうそうない。

お金とやりがいを用意するのが、今後のテスト業界で生きる人の課題なのかもしれません。

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

続き！ようやく折り返し

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

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

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

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

以下メモ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以下メモ

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

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

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

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

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

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

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

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

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

第一印象いいもの同士

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

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

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

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

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

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