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

EVO2017の最終日を家で見てました。スト5が劇的やった。

自分が携わったゲームがユーザ参加型のイベントに使われたことがあるのですが、ユーザが夢中で楽しんでる姿を見るのは、やはり良いものでした。一生懸命不具合取り除いて、ユーザがバグに気を取られることなく楽しんでる姿をみると、ゲームQA冥利に尽きます。

ゲームテスト&QA

CHAPTER 5 エンジン始動！バグ探しの要点

この章では、シューティング、2Dアクション、格闘ゲーム、RPG、FPSなどなど、さまざまなジャンルのゲームQAの勘所を、ジャンルごとに説明しています(第二版があるなら、VRゲームも書いてほしいですなぁ)。不具合だけでなく、ユーザエクスペリエンス部分でもどのような指摘をすべきかも説明してあって、ゲームQAのお仕事は単なるバグだしだけじゃないということが伝わってきます。

テスターやテストリーダの立場でも有益だし、それよりも上流で、テスト計画や見積もりの参考にもなりそうな内容でした。

MMORPGのテストが一番難しい、というのは、覚えておきたいところです(僕はMMOもRPGもテストしたこと無いので、いつかしてみたい)。

また、不具合報告書の書き方も記してあって、テスト初心者におすすめしたい内容でした。

以下メモ

・ゲームをテストすることは、プレイすることとは大きく異なります

・2Dゲームをテストする際は、重点をゲームプレイに起きます

・3Dゲームをテストする際は、カメラについてレポートすることは、テスターの使命である

・FPSでは、レベルデザインが理解しにくかったり、迷宮のようになっていてはいけません。プレイヤーを迷子にすることなど、あってはならないのです。

・マルチプレイヤーのFPSをテストするときは、ネットワーク接続に関連するバグに注意しなければなりません

・RPGゲームのテストを始める際には、仕事量が実に多くなることを前提に準備をしてください。テストの難易度は「ハードコア」だと思って良いでしょう。

・ストラテジーゲーム(シヴィライゼーションみたいな)をテストするときは、ゲームバランスに注意すべき

・パズルゲームで注意すべき点は、すべてプログアムに関する部分です。

・MMOはゲームテスト界の頂点です。

・MMOでは、βテストでユーザに不具合を上手く見つけさせる仕組みを用意すると、うまくいく。例えば報酬を上げるとか

・ゲームのテストには大量の書類が伴うということを想像している人はあまり居ませんが、筆記力がなければ優れたゲームテスターになることはできません。

・不具合報告書のタイトルは、ジャーナリズムの基本である５W（誰が、何を、いつ、どこで、なぜ)を抑えればOK

・テスターは会話と筆記の両方で、明確かつ有効なコミュニケーションを取れなければいけません

・バグレポートには、常に正しいバージョンを記入していくことが重要です。

・私が求めるテスターは、プレイ中にバグを発見してレポートを提出したことがあり、「バグレポートの記入時に最も重要な項目は何か？」という質問に答えられるテスターです。この質問に対する答えから、回答者がどのようなテスターになるかわかります(一番の解答は「再現手順」です)

・ゲームをテストしているときは、自分が今何をしているのかを正確に把握していなければならないのです。ただプレイするのではなく、機能していない何かを見つけるのが仕事です。

仕組みでどうこうじゃなくて、マインドの問題かもしれない

実際に目にしたインシデントを振り返ってみるコーナー。

事例：一部のリソースが、実は最新じゃない状態でリリースしてしまった

凡ミスの類。
確かに不具合だけど、大した事ないんじゃない？と思うなかれ、ゲームだとコラボイベントなどで版元が絡んでると、かなり大問題になるのです。

リソースにも色々あります。ゲームだと、画像、音声、データ、ソースコードなど。
最近は、バージョン管理ツールを全ての部署で利用することもあるので、この手の不具合は、起こりにくくなってはいます。特にコードは。

しかし、画像や音声に関しては、外注してたり、こだわり派のデザイナが締め切り過ぎても(こっそり)手を加えたりで、管理が行き届かない現場も、よく見かけます。

スケジュール守りましょうね～、最新のものをこっそりコミットしたりはしないようにしましょうね～、と伝えても、こだわることが正義だと思いこんでたりもするので、あまり響かず同じ失敗を繰り返しがち。

「今、俺が見ているデータは最新なのか？」という保証は、結構難しい。

テストする段階で、諸々の素材はfixしてることが好ましいが、スケジュールがタイトな現場だと、仮素材でとりあえずテストを走らせつつ、fix次第、組み込むということも珍しくない。そして、fix素材アップしました、からの、やっぱ微調整しました、が繰り返されると、プログラマが更新し忘れたり、仕様となるドキュメントを更新し忘れたりで、ミスが入る余地が増えてしまう。

また、デザイナとプログラマは、別の管理方法を取ってる現場もあって、

①デザイナが最新データを共有サーバに上げる
②プログラマそこからデータをとる
③ゲーム内フォーマットに加工して組み込む
④プログラマ用のリポジトリにアップする

みたいな感じだと、最新の生素材から組み込みまでに複数のプロセス(しかも手作業の)が入るので、ここをミス無く運用するのは、難易度が高い。

これを防ぐにはどうしたらいいのか。
まぁ、余裕を持ったスケジュールを引いて、特定の日以降は素材の更新を認めない、というのが正攻法ではある。けど、そうも言ってられない場面もあるわけで、なので、大事なのは、「この画像・音素材が最新です」と記したドキュメントを作成し、それの更新を徹底することかなと思う。そのドキュメントがあれば、最新のビルドと素材の突き合わせを関係者全員が行うことができ、仮に素材の更新漏れがあったとしても、誰かが気づく可能性が高くなる。

しかし、ドキュメントの更新というのは、大抵が手作業で、忘れがちだしミスも起こりがち。つまり、「今、俺が見ているドキュメントは最新なのか？」という保証も難しいわけで、堂々巡りの様相を呈してくる。

解決策としては、ドキュメントの自動化とかかな？
それか、絵や音声に関しては、QA時に制作者に最終チェックしてもらうとか。作った人が、一番、細かいところまで知ってるからね。

ただ、後者の場合は、素材制作者がQAプロセスのボトルネックになりがちなので、そこがデメリット。「最終チェックしてください」と依頼をしても、全然見てくれなかったりね。

そこを解決するには、関係者が定期的に集まる場を強制的に設けて、そこで滞留してるタスクを動かすとかかなぁ。朝会とか夕会とか。この手の、ミーティング嫌う人多いけどね。

素材の更新ミス、みたいな単純な問題でも、それを徹底して防ぐのは難しいのです。

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

GW最終日。しくじり先生のアンミカが面白い。

GWは遊んでばかりいたので、罪悪感を少し紛らわすために、勉強用のこのブログを更新してみる

ゲームテスト&QA

 

CHAPTER 4 計画の立案：バグのカテゴリ、ツール、ドキュメント

QAにまつわる職種の紹介から始まり、バグのカテゴリの説明、バグトラッキングツールの説明、テストに関連するドキュメントの解説など、実践的な話が多い章でした。

特にバグのカテゴリの説明のところは、新人に読ませるのにちょうど良さそうだし、QAリーダとしてBTSのバグの分類を設計するときにも参考になりそうでした。

以下メモ

・QAマネージャは、QAにおける縁の下の力持ち、スポットライトが当たることのない魔法使いのようなもの

・QAマネージャの責務は、スタッフが素晴らしい仕事が出来るような環境作りをするということ

・ゴシップや士気の低迷は驚くべき速さでその部署をだめにしてしまう

・リードテスターは、歩兵の集まりをチームとしてまとめる手助けをします

・フロアリーダは「非公式」なリードテスター。フロアリーダにあるのは、経験と開発プロセスに関する深い知識です。有能なフロアリーダーになるためには、技術的なスキルだけではなく、ソーシャルスキルも高めなければいけません。

・オーディオ系のバグは、ビジュアル系のバグと比べると見つけにくい。

・近い将来、物理演算のバグがテストプレイにおいて占める割合は、更に大きくなるでしょう。

・パフォーマンスに関する深刻なバグは、開発プロセスの最後の2ヶ月で修正しようとしても複雑すぎる可能性がある。

・ロード時間のバグテストは、非常に退屈。ゲームの全てのレベルを何度もロードして、其の所要時間をノートに書き留める必要がある。

・テストをする際には、常にパフォーマンスを意識することが重要です。「完璧」なゲームであっても、パフォーマンスの低さによって、其の名を汚すことがある。

・安定性に優れた製品は、バグを上手く隠して見つけにくくしているだけである。

・テスターと開発者の間でやり取りが行われることがありますが、これは業界ではあまり良いことだとは思われていません。優れたテスターは自動追尾機能付きミサイルの打ち上げのように、目前の仕事をこなして次へ次へと切り替えていきます。

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

年度末評価の時期です。

仕事は概ね想定通りの進捗だったんですが、一点、この半年で新しい人が一人も入らなかったのが、残念でした。

まぁ、人手は足りてるんですが、それはそれとして、人の流動が無いと、チームはいつか停滞しちゃいます。変化を嫌うチームができてしまう。

この業界、変化を拒んでたら、あっというまにワープアです。来年度は、人を入れつつ、異動を推奨しつつ、変化を楽しむチーム作りを進めていきたいなぁと思ってます。

ということで、メモの続き(ついに1位まできた)

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

12章 難題第1位 「NO」と言うこと

つまり、「この品質では、市場に出せませんよ」とステークホルダに言うことです。これが上手くできないと、テストチームも、そして会社も窮地に陥ることになります。

つい最近、同僚がまさしくこの状況に陥っておりました。納品日が近づいても収束しない不具合。テストチームは毎日レポートを出しているが、誰もそれに目を通さず、ただただ、目の前のバグ修正に追われる開発者。レポートを見れば、リリースに値しない品質だということは、明らかなのですが、納品日はずらすことが難しいため、とりあえず、インパクトの大きな不具合だけを修正し、残りはリリース後のアップデートで対応しようという方針になりました。

しかし、リリース後、ユーザから寄せられるのは、その細かな不具合へのクレームであり、開発チームはそれらの対応に追われることになります。そして、そのストレスは、テストチームへの批判というカタチで向けられるのでありました。

どうすれば、「今は、出すべきではない」という事実を、ステークホルダが納得してくれるのでしょうか。この本が出している結論は、「客観的なデータを集めること」と「誠実に伝えること」の2点です。

データは重要です。テストチームが主観で意見を伝えてしまうと、それは単なるプロダクトへの悪口に聞こえてしまいます。なので、不具合の数、クローズ数、インパクトの大きな不具合の割合といったことを、データとして出す必要があります。

そして、それを伝えるときは、誠実さが大事です。これは、医者が患者に症状を伝えるときのことをイメージしたら良いかもしれません。ふざけてもいけないし、過剰に不安を煽ってもいけません。

プロダクトにNoを言うためには、テストチームの役割とはなんなのかを、時間をかけて理解して貰う必要があります。そのためには、開発チームとしっかりコミュニケーションを取る必要があるのです。

あ、テストチームがリリース権限を持ってる組織もありますが、それでも結局やることは同じで、客観的なデータと、誠実なコミュニケーションが大事でしょう。合格・不合格、それぞれで、ちゃんと納得感があることが重要です。

以下メモ

・テスト担当者が直面する人間関係絡みの最大の難題は、ソフトウェアに問題があることを関係者に伝えることである。一般的な法則として、人は悪いニュースを聞きたがらない。

・テストレポートは、開発プロセスに組み込んでしまうのが、効果的である(定期的に報告をする)

・テスト結果を正確かつ客観的に報告することは、後で自分を守る最善の方法である。システムをリリースした後で、ソフトウェアに問題があるということで、テスト担当者が非難されることがある。そのような状況において、テスト報告は自分を守る優れた方法である。

・テストの評価と報告もテストプロセスの中に定義すべきである

・欠陥を見つけて報告することがテスト担当者の仕事であることを、関係者は理解する必要がある。実際、テスト担当者が事実上失敗する可能性があるのは、検出した欠陥を報告することに失敗した時だけである。

・四六時中ギシギシ行ってる車輪を人は無視するようになる(テストチームが常に否定的なニュースを伝えるようになると、開発チームはそれを無視するようになる)

・テスト報告書には、客観的な情報を記載すること

・悪いニュースだけではなく、肯定的に、正常に機能しているソフトウェアの部分を指摘することは、大いに結構である。

・裸の王様の新しい服の話は、ソフトウェアに問題があることを経営管理者に告げる勇気を誰も持っていない場合に、何が起こるのかの良い例えである。

・システム導入後のレビューは、非常に役に立つものである。鋭い目で過去を振り返って、プロジェクトの良かった点と悪かった点をドキュメントに記載しましょう

・組織が成熟する速さや深さは、上級経営管理者が成熟する速さや深さによって決まる

・改善の焦点を(プロダクトではなく)プロセスに合わせるだけで、殆どの組織において劇的な変化が見られる。

・コミュニケーションとは、自分が行っていることを聞き手に理解出来るように、他の人と情報を共有するプロセスの一部である。「話す」ことと「聞く」ことと「理解する」ことが全て、コミュニケーションのプロセスに関わる

『テスト担当者を悩ませる、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をやるならば、変化に文句を言ってはいけません。変化を許容し、変化によるリスクを正確に伝えるように心がけたいものです。

以下メモ

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

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

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

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

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

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