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

この記事読んで、ああ俺はテスト技術者の道を選んでよかったなと、しみじみ思いました。テクノロジは移り変わってもテスト手法って、そんなに変わらないからね。フロント開発の人は、ほんとがんばってください

【翻訳】 2016年にJavaScriptを学んでどう感じたか - Endo Tech Blog

さて、ゲームテスト＆QAのメモをば。

ゲームテスト&QA

CHAPTER 2 謎めいたテストプレイの世界

この業界に数年居た人なら「あるある」と膝を打つようなことが書かれています。標準的なゲームテスターの仕事内容や、オフィス環境、テスターの年齢層、テスターによくみられる性格などが解説されています。

また、ゲーマーとゲームテスターは別モノであり、それを隔てるものは「規律」の有無だと説いており、僕もこれには大いに共感します。

テストは、プログラマやアートと比べると、チームプレイの要素が大きい仕事です。もちろん、生産性の個人差はありますが、「その人にしかできない。その人が居ないと、仕事が進まない」というようなことはあまりありません。そのため、僕は採用や配置の際は、チームプレイができるかどうか？がゲームが上手いかどうかとか、テストの専門的な知識の有無よりも重要視するようにしています。

以下メモ

・テストには技術的な側面がある

・良い人材はPCゲームのテストに、そうでない人材はニンテンドーDSやPSPといったポータブル機のテストに割り当てるべき

・強いものだけが生き残る。この恐ろしい運命から救ってくれるのは知性と技能だけです。目立つだけでは足りません。差を付けなくてはなりません。

・ゲームのテストには規律が必要です。

テストチームと軍隊

先日、日経ビジネスオンラインで紹介されてたこんな本を読んでみました

国のために死ねるか 自衛隊「特殊部隊」創設者の思想と行動 (文春新書)

すわ右翼の過激思想本か！と、なんとも目を引くタイトルです。

そして、実際に、多少偏ってるというか極端な記述もあるのですが、組織論、リーダシップ論の面で、考えさせられる内容が沢山ありました。全体を通して良書でした。

作者は海上自衛隊の特殊部隊創設に関わった人なのですが、特殊部隊と通常の軍隊は以下のように仕組みからして大きく違うそうです。

■軍隊(いわゆる、陸軍とか海軍とか)
・上意下達であり、厳格にヒエラルキーがある。また、部隊ごとに役割が分かれている。攻撃班、物資輸送班、医療班、といった具合に

・兵士は「如何に上官の命令を素早く正確に実行できるか」が重要視される。判断をしてはならず、状況を上官に報告し、都度、命令をもらう必要がある。

・身体面、学力面で一般的な人よりも劣っている人が集まりやすい(特に海外はその傾向が強いそうです)

・組織の小回りが効かないが、規模の大きな作戦は比較的やりやすい。

■特殊部隊

・一人でなんでも出来なければならない。

・「どうすれば目的を達成できるか」を一人ひとりが考え行動する。チームプレイも当然あるが、「命令と実行」ではなく、自分と相手の状況を把握して最善の行動を各自が選択する。

・選抜された人の集まりなので、優秀な人が多い。

・スピード感を求められる作戦には向いているが、大規模な作戦には向かない。

でもって、テスト組織って軍隊型と類似してる点が多いなぁと思った次第です。作業の細分化・フロー化が進んでることとか、あまり優秀な人が集まらないこととか(残念ながら)。

まぁテストリーダとテスターで構成される伝統的テストフローは、確かに管理しやすいし、テストするサービスの規模が大きいと、そうせざるを得ないところもあるので、必ずしも劣ってるわけではないですけどね。。

ただ、テストチームを運営する身としては、いつか特殊部隊化したテスト組織を作ってみたいなと思ったのでした。仕事(つまり目的)を与えたら、あとは勝手に動き出してくれるチーム。「君はテストケース作ってね、君は項目の何番～何番を消化してね」ではなく、お互いがお互いの得意不得意と現在のタスク状況を把握した上で、「僕はここやります、私はここをやります」と走りだし、走りだした後も適切なコミュニケーションで、都度軌道修正し、正確に仕事をやりとげるような…。

どうしたらいいんですかね、テスト技術者虎の穴でも作って、そこから生きて出られた者のみを対象にチームつくるとかかな。

『テスト担当者を悩ませる、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割くらいという話を聞いたことがありますが、それは、この時間によるブレがあるからなのではないかなー、と。

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

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

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

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