今週気づいたこと

ソフトウェア開発会社の専門職には、出世コースに、マネジメントコースとプロフェッショナルコースの2つ用意されていることが珍しくない。

最近、思ったんだけど、QAでずっとメシを食っていこうと思ったら、プロフェッショナルコースを意識した方が良いような気がした。まぁ、マネージャ目指してもいいけどマネジメントコースは、大抵の場合、有限な椅子の椅子取りゲームなので、自分だけではどうにもならんことがある。

一方、プロフェッショナルコースは、椅子は自分で作ればいい。実力を見せつけて、会社に認めさせればいいのだ(ただ、その道はマネージャルートよりもよっぽど過酷だと思う)。

マネジメントコースとプロフェッショナルコースの大きな違いは、社内価値を意識するのか、市場価値を意識するのかの差だと思う。重なってる部分ももちろん多いけど、マネジメントは市場価値が考慮されない場合がある。例えば、長く会社に在籍してるだけでもなれる場合があるし、逆のパターンだと、実力があっても一部の人に嫌われてたらなれないことだってある。なので、「頑張るのが馬鹿らしい」という瞬間が来ないとも限らない。社内価値を意識することは、このリスクがある。

他の職種と比較すると、残念ながら、QAを専門職と認識している会社は、それほど多くない。だからこそ、それを証明し、プロフェッショナルとして会社に認めさせていくプロセスは、出世を目指すのとは異なるベクトルの、持続可能なモチベーションが得られそうだなと思った次第なのでした。

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

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

9章 難題第4位 投げ渡されたソフトウェアをテストすること

テスターからの不満第一位だと思う。

テストチームにとって、テスト対象のソフトウェアの質が悪く、仕様も固まっていない状態でテストすることほど、ストレスの貯まることはありません。しょうもないバグの報告書作成や、しょうもない仕様質問にひたすら時間が消費されていき、大事なところのテストができない。

にも関わらず、スケジュールが遅れたり、リリース後にインシデントが発生すると、まずテストチームに責任の矢が向けられることは珍しくありません。

したがって、この問題は、テストチームの生産性を高め、かつ社内的な立場を守るために、速やかに解決しなくてはならない問題の一つだと思います。

この章でも明記されていますが、必要なことは、関係各所とのコミュニケーションです。ソフトウェアテストというものの性質を良く知ってもらわなくてはならない。まずはそこからです。

僕の知り合いのテスト技術者は、プロダクト側に最低限クリアしなくてはならないチェックリストを渡し、それをすべてクリアしないとテストはしないようにしてるそうです。チェックリストの中身は「起動すること」とか「今回追加した機能が正常に利用できること」とかそれくらいレベルの低い内容だったそうですが、効果はかなりあったそうで、「しょうもないバグ」の数が劇的に減り、複雑な条件のテストに費やす時間が確保できるようになったそうです。

まぁ、上記のことをやるためにも必要なことは正確なコミュニケーションということになるのでしょうけど。「しょうもないバグや俺らのミスを見つけるのがテストチームの仕事だろ？」と思ってる開発者は、残念ながら居ますから。

 

以下メモ

・開発者はプロダクトを突然にテスト担当者に送りつけることがある。そのような振る舞いを「投げ渡す」ということがある。

・開発者側では、最終的にテスト担当者が全ての欠陥を見つけてくれるだろう、と想定している。そのため開発者は、たとえ(自身で)テストを行ったとしても、不十分になりがちである。その結果、単体テストの段階で開発者に酔って検出されるべきであったシステム中の欠陥が、テスト担当者によって数多く発見される傾向が強くなる。

・「ソフトウェアを投げ渡す」ような行動の根本原因の主たるものは、コミュニケーションの欠如である。

・(投げ渡されたソフトウェアのテストは)多くは表面的になり、その結果として、重大性の高い欠陥を発見する有効性が下がっていった。

・(投げ渡されたテストで思い通りの結果が出ないのは)人数ではなくプロセスの問題である。

・ソフトウェアがテスト担当者に投げ渡される場合、開発者側には、「自分はテストしている時間が無いから、テストを本業にする人たちに任せておけば良い」、という態度が産まれる。

・テストのコストを論点にしてみると、コミュニケーションがうまくいくかもしれない。開発者がソフトウェアをテスト担当者に投げ渡すようなやり方だと、テストや再作業の回数が増えるため、コストが高くなることを示してみる。

・開発者が実施すべきテストと、テスト担当者が実施すべきテストとを指定した、プロセスを定めることである。

・欠陥除去有効性=テスト中に発見された欠陥の数 / プロダクトの寿命期間中に発見された欠陥の合計数

・品質の高いソフトウェアはひとりでにできるものではない

・仕事に幸福感を感じるためには、3つの事柄が必要である。具体的には、該当の仕事に向いていること、仕事をしすぎないこと、仕事に成功感を感じることである(ジョン・ラスキン -イギリスの作家-)

『ゲームテスト＆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万ですら、そうそうない。

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