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

年度末でございます。仕事は、半年前に立てた目標が、まぁまぁ達成され始めてて、細やかな充実感が得られたりしてます。

一方、私生活では、2017年は早寝早起きと目標を立てたのですが、一向に目標達成できる気配がありません。眠い。

ということで、この本のメモの続き

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

 

11章 難題第2位 どちらに転んでも損をする状況と戦うこと

品質悪くてテストが炎上して、とてもじゃないけどリリースできないが、経営層はさっさとリリースしたがっている。リリースを止めても経営層には睨まれるし、けどリリースしても品質悪くて経営層に詰められる。
という、前門の虎・後門の狼という状況のことです。

この状況はQAにとっては、非常に辛い状況で、モチベーションが上がりません。忙しくテストをし、QAとしての責任を果たそうとしても無視され、にもかかわらず、リリース後のサービスの評判が悪ければ、あらぬ罪を着せられるわけだし。

これも結局は、関連部署のQAに対する無理解から来ています。一言でいえば、コミュニケーション不足が引き起こす災害です。

この「どっちに転んでも損をする」状況に陥っている現場をたまに見かけますが、問題が起きてる現場の共通点は、QAから他部署へのコミュニケーションが控えめであること、ステークホルダが複数いること、開発現場に未熟な人が多いこと、開発のプロセスや雰囲気が固まってからQAがジョインしていること(つまりジョインが遅い)、が挙げられると思います。

解決策、というか、こういう現場に陥らないコツは、「QAの役割を正しく認識してもらうこと」、「プロダクトにとって都合の悪いことも、はっきり伝えること」に尽きるかなと思います。このとき、数値や本やネット記事なんかで、根拠も伝えられると良いかもしれません。

プロダクト側が聞く耳もたないなら、そうですね、転職の準備をしましょうw
そんな現場にいても、得るものは無いです。

以下メモ

・テスト担当者が直面した、どちらに転んでも損する状況には、下記のような影響がある
　・組織のプロセスの成熟度を低く抑える
　・テストプロセスをないがしろにし、其の基盤をそこなう
　・テスト担当者のモラルを低下させる
　・テストに関する誤った見方を助長する

・(テストは開発を遅らせる要因と認識されがちだが)実際には、テストが有効なプロセスとして機能していれば、最終的に開発プロセスの効率が上がり、リリースまでの時間が短縮される

・テスト担当者が欠陥の修正フローの制御ができなければ、テスト担当者はチェックして欠陥を見つけることに責任を負うだけで、ソフトウェアの品質の責任は負えない

・どちらに転んでも損をする状況では、テスト担当者は全ての欠陥を発見することを期待される

・実際には、プロジェクトに関与している誰もが、テストに責任がある。

・組織内の誰もがテストが演ずる役割を知っていることが、極めて重要である。そうでないと、テストについて、間違った安心感や責任感が持たれてしまう。

・テストチームの中には、苞の役割を宣伝するのに効果がある1ページのニュースレターを、四半期ごとに発行しているところがある。（他部署のテストに対する理解を深めるため）

・他部署の人間をテストチームで短期間仕事させることは、大きな効果がある。予め適切にテストサれていなかったソフトウェアをテストすると、どういうことになるのかについて、よく理解するようになる。

・品質は偶然に達成されるものではない。品質は、強い意図と、真剣な努力と、知的な方向付けと、巧みな実行の結果である。品質は多くの選択肢を賢く選択したことを表す。

・ソフトウェア開発の各ステップごとに、品質管理点をプロセスとして組み込むべきである。プロダクト開発の責任者が、品質管理にも責任を負うべきである。

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

いつかゲームQAの本を出したいなぁとか思う今日このごろ。

ゲームテスト&QA

CHAPTER 3 テストの様々な性質：ゲームのライフサイクル

ゲームテストというと、世間的には、ひたすらプレイしてバグを出す、の一言で片付けられがちだけど、ゲーム開発の様々なフェーズに応じた色んなテストがあるんだよ、ということが述べられています。

そう、良いゲームQAというのは、「いま、どんなテストをするべきか」をちゃんと判断出来る人のことだと思います。

安定性とかパフォーマンスとか面白さとか(アプリQAだと)端末カバー率だとか、色んなテーマのテストがあって、それらをどのタイミングでやるべきかというのを、ちゃんとコントロールする必要があります。

プロダクト側は、その辺、意外と無頓着で、ビルドがまったく安定してないのに、「そろそろAndroidで他機種＆複数OSバージョンのテストやってくれる？」とか言ってくることも、珍しくありません(そういうときは、ちゃんと、理由を述べて断りましょうね)。

バグの優先度の話とか、任天堂やSCE,マイクロソフトのプラットフォームのコンプライアンステストの話や(これは、最近だとアップルのガイドラインを守ってるかどうかとかとも関わりますね)、バランス調整の話や、ローカライズの話や、ユーザビリティの話など、テストの種類とその目的が網羅されてるチャプターで、新規タイトルのゲームQAを任された人には、とても参考になる内容だなと思いました。

コラム欄も充実してて、トリプルAタイトルを生み出し続ける海外パブリッシャの品質へのこだわりも伝わってきます。

以下メモ

・バグとはわざと作られるものではありません

・バグとは、何かが誤っている状態のことです。これによって、ゲームの質が低下したり、見苦しくなったり、プレイできなくなったりします。

・ゲームにおいて、ゲームをより良いものにすること無く質を落とすような要素は、全てバグです

・テスターの目的は以下の通り
　・バグを見つける、バグを再現する、バグを報告する
　・副次的な目的は以下の通り
　　・バグが修正されたことを検証する
　　・ゲームが楽しいことを確認する

・テストは、開発のあらゆる段階において行われるべき

・ゲームは、生きて呼吸をするソフトウェアです

・アルファのフェーズでは、バグがないゲームを作ることよりも機能を確定することに重点が置かれます

・QAが開発プロセスの最後にあって、スケジュールを調整しやすいものであると誤解されないようにする必要がある。

・いくら機能が優れていても、実装が不完全であれば何の意味も無い

・テスターはローテーションするべき。慣れてしまうとバグに無感覚になってしまうので。

・ビルドが壊れていると、お金は無駄になり、テスターたちは時間を潰すことになる

・QA部門は有益なフィードバックを提供するという点で非常に重要

・QAチームは協力者であって、敵ではないということを開発者が忘れずにいることも、とても重要

・協力は必ずより良い製品につながる

・バランステストのやり方は、ざっくりいうと、テスターを同じくらいのスキルレベルになるようにチーム分けして、スコアを測り、結果に極端な偏りが無いかどうかをチェックする

・互換性テストは、バランステストよりも遥かに技術的要件が厳しいテストである。

・ゲームを数日間動かしっぱなしにするテストのことを「ソーキング」(浸す、の意)と呼ぶ。これによりメモリリークや丸め誤差といった、通常のテストでは検出できないバグを検出することができる。

・楽しさには決まったルールはなく、その要因を確認する方法はテストプレイしかない

・任天堂のゲームにはちょうどよいゲームプレイバランス、つまり「楽しさの要因」が常に備わっている

・ユーザビリティとは、「簡単さ」ではなく「使いやすさ」

・プレイヤーの関心は、コントロールの仕組みではなくゲームをクリアすることにあります。それ以外にエネルギーを使うことになれば、本来得られるはずの面白さが損なわれてしまいます。

・ゲームのテストは簡単に学べるスキルですが、ゲーム業界や、業界と様々なテストとの関係を理解することは、かなり困難です。

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

完走まであと少し！

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

10章 難題第3位 動いている的を射ること

僕が日々携わっているゲームのQAは、まさに、動いている的を射る仕事である。

テスト期間に入っても仕様が固まらないなど、日常茶飯事だ。外部要因だと、プラットフォームのOSのバージョンが変わったり、新しいハードが出たり、ガイドラインの変更があったり、ミドルウェアのアップデートがあったりと、変化の要素には事欠かない。

まずゲームなので、仕様変更はしょうがない。「最初の案より、こっちのほうが面白い」と判断したなら、そうした方がきっと良いゲームになる。そして、仕様を変更が入った場合は、ちゃんとそのリスクを伝えるのがQAの仕事である。ここで何も発言せずにいると、無茶なスケジュール組まれて残業地獄となるか、不十分なテストでリリースせざるを得ない状況となり、障害のリスク(と責任)を負わされるかもしれない。

外部要因への対処は、回帰テストが中心となる。ただ、回帰テストはテスターにとっては退屈な仕事の一つなので、ただ、テストケースを消化するだけではなく、なにかしらのゲーム要素を取り入れたほうが、テストの質は上がる気がしてます(消化速度だとテストがおざなりになるので、見つけた不具合数とかの方が効果的)。

あとは、なるべく無駄な項目を削るために(ボリュームの多い回帰テストほど、テスターのやる気を削ぐものはない…)、回帰テストのテスト項目には優先度をつけたり、影響範囲を把握するためにコンポーネントの関連図を用意しておくのも効果的。

ゲームのQAをやるならば、変化に文句を言ってはいけません。変化を許容し、変化によるリスクを正確に伝えるように心がけたいものです。

以下メモ

・過去においては、「要求の変化をいかにして抑えるか」が問題であったが、今となっては、「変化する要求に如何に対処するか」が問題である。

・変更には、回避不可避なものと回避可能なものが混在している

・変化は避けられないのであるから、変化に驚くよりも、むしろ変化を計算に入れるべきである

・テストの目的は一連の固定的な基準に基づいて、何かを評価することである。

・変更を許容するのでも記録するのでもなく、管理すべし

・回帰テストを実行するには、正確性が求められる(なので、自動化が望ましい)

今週気づいたこと

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

以下メモ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ゲームテスト&QA

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

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

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

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

以下メモ

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

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

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

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

テストチームと軍隊

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

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

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

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

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

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

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

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

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

■特殊部隊

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

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

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

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

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

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

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

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