ゲームテストへの新しいアプローチ

ゲームテストへの 新しいアプローチ A New Approach to Games Testing Michael Hart 翻訳：今給黎 隆

• https://www.linkedin.com/in/wh1tepointer?trk=pulse-det-athr_prof-art_hdr

• Video games is a billion dollar industry and video games themselves are complex pieces of software that comprise of many parts. I'm always disappointed however to hear about how many video game studios treat their QA department. This doesn't apply to all studios of course, there are plenty out there that do it well, but there are also many out there that don't. Typically, minimal testing by qualified testers is done during the bulk of the game's development, then once the game hits a certain milestone late in the process, a large amount of temporary staff are brought in to test the game that's usually under a very strict deadline. Many overtime hours are spent by programmers, content producers and testers alike, as all of a sudden the floodgates have opened and they are copping a barrage of bugs that need to be fixed before going gold. Once the game has shipped, the majority of those temps have their contracts ended. • This is obviously really inefficient and it surprises me that video games still use this waterfall type of model when the majority of other software has moved to other methodologies. What I want to do with this post is encourage a different approach to video games QA.

• ビデオゲーム産業は、十億ドル規模であり、ビデオゲーム自体は多 くの部品で構成する複雑なソフトウェアである。私は、「ビデオ ゲームスタジオが彼らのQA部門をどのように扱うか」を聞いて、い つも失望している。もちろん、すべてのスタジオがそうと言うこと ではない。うまくやれる多くのスタジオもあるが、同じようにそう ではないスタジオが多くある。一般に、ゲームの開発のほとんどの 期間には、内部のテスターによる最小限のテストが行われ、開発の 後半の特定のマイルストーンにきたら、大量の臨時社員が非常に厳 しい締め切りの条件でゲームをテストするために連れてこられます。 全ての水門が突然開いたかのように、プログラマ、コンテンツ制作 やテスターは大量の残業をし、彼らのゲームが金塊になる前に修正 されるべきバグのつるべ打ちを落としていきます。ゲームが出荷さ れると、一時雇用者の大半は、契約が終了します。 • これは明らかに、本当に非効率的であり、ビデオゲーム開発が、ま だウォーターフォールモデルを使用していることにも驚きました （他のソフトウェアの大部分が他の方法に移行しているにも関わら ず）。私がこの記事でやりたいことは、ビデオゲームのQAの異なる アプローチを奨励することです。

QA is a discipline • Firstly, the QA department should be treated just like any other. QA, especially in video games, is often seen as a less skilled, entry level position. I want to put a stop to that right now. QA is not an easy job that just anyone can do. QA is a discipline just like programming, or art, or animation, or design, or sound, and requires its own specific set of skills (not the least of which is often needing to have a certain level of understanding of all of the above listed disciplines). Your internal testers should be permanent full time employees, and be on the development floor(s) with easy access to speak to anyone they need to, not locked away in a basement where the only interaction they have with developers is when they respond to a bug report. They should be trained, qualified and experienced Test Analysts, with degrees or diplomas, and/or software testing qualifications (there are several software testing specific qualifications out there), and their salaries should reflect that. It's just as hard to find talented experienced test analysts as it is to find talented experienced programmers and artists. Don't treat QA as a default stepping stone into other disciplines.

QAは分野である • まず、QA部門は、他と同じように扱われるべきです。特にビデオゲーム 業界では、QAは、しばしば「スキルが要らない」、「エントリーレベル の位置」と、見なされます。私は今この瞬間から、それに待ったをかけた い。 QAは、誰もが行うことができる簡単な仕事ではありません。QAは、 プログラミング、アート、アニメーション、デザインや音楽のような「分 野」であり、固有のスキルセット（上記の全ての分野において、一定の理 解レベルを持っている必要がほとんどない）が必要です。あなたの会社の 内部テスターは、正規雇用の従業員であり、必要があれば誰とでも簡単に 話せるように開発フロアにいるべきで、バグレポートに応答するときだけ しか開発者と交流しないような地下室に閉じ込められてはいけません。彼 らは、学位を持ったりソフトウェアテストの資格（世の中には、幾つかの ソフトウェアテストに関する資格がある）を有したり、訓練され、能力が あり経験があるテストアナリストであるべきです。彼らの給料にはそれら が反映されるべきです。才能・経験豊富なテスト・アナリストを見つける ことは、才能・経験豊富なプログラマーやアーティストを見つけることと 同じように難しいことです。QAを、他の分野に移るための定番の飛び石 として扱わないでください。

QA from the beginning • Your testers should be involved in the development process from almost the beginning, not just brought in only when there is something "physical" to test. It all starts with the game design document. Your QA staff should be looking over this document even before development proper begins in order to find potential defects. Don't consider it some kind of criticism of your design, moreover embrace it. Qualified and experienced testers will find potential problem areas in the design just like they will find bugs in the code and art, which is the kind of thing you can easily fix before anything is implemented. It's a lot harder, not to mention a lot more expensive, to discover there were issues with the design after the code has been done and you realise you need to rewrite the code, change the design or ditch the feature entirely. After all, this design document is supposed to be the source of truth for your staff. They are going to need something to refer back to so they know exactly how something is supposed to work or look like. If this is inaccurate, these inaccuracies multiply down the line. Allowing your testers this early access to the design document also allows them to start designing their test cases from an early stage. • Note that the testers are not there to suggest design changes or critique the design document, they are there to spot defects. It would be totally up to the senior designers exactly how they would go about fixing those defects. • While it's true that many games tend to deviate from what was originally in the design document, this is another process that needs to change. If the design is modified, then the design document must be modified with it to reflect the new functionality. Your design document is your source of truth and your staff, especially your testers, should be relying on it as a reference point so they can easily know if what they are noticing is actually a bug or not. Don't neglect your design document! Keep it up to date!

最初からQAを • テスターたちは開発プロセスのほぼ最初から絡んでいるべきです。「物理的」なテストがある場合 にのみになってはいけません。全てはゲームデザインドキュメントから始まります。QAスタッフ は、開発が正式に始まる前であっても、潜在的な欠陥を発見するために、このドキュメントに目を 通すべきです。QAからのフィードバックを、あなたの設計への批判のたぐいと考えず、積極的に 受け入れてください。正規で経験豊富なテスト担当者は、何が実装される前に、コードやアートの バグを見つけるのと同じように、設計の中に潜在的な問題領域を見つけるでしょう。それらは、簡 単に修正できるたぐいのものです。コードができた時になれば、コードを書き直し、デザインを変 更したり、完全に機能を捨てなくてはならないと悟る、発見するのが困難だったり、触れなければ より高くつく、設計上の問題となります。結局のところ、この設計ドキュメントは、あなたのス タッフにとっての「真理の源」になることを目的としてます。彼らは差し戻すための材料を必要と しているので、物事が本来ならばこのように働いたり見えるはずだということを正確に把握します。 これが不正確である場合、将来、これらの誤りは増していきます。テスターに設計ドキュメントへ の初期のアクセスを許可すると、彼らは早い段階からテストケースの設計を開始できます。 • テスターは設計変更を提案したり、設計ドキュメントを批判するために存在するわけではないこと に注意してください、彼らは「欠陥を発見」するためにいます。それらの欠陥をどのように修正す るかは、完全にシニアデザイナーの責任です。 • 多くのゲームは、もともとの設計ドキュメントに書かれたものから逸脱する傾向があることは事実 ですが、変更する必要が生じるのは別のプロセスにおいてです。設計が変更された際は、設計ド キュメントは、新しい機能を反映するように修正されなければなりません。あなたの設計ドキュメ ントは、あなたの真実の源です。あなたのスタッフ、特にテスターは、実際にバグであるかどうか 簡単に知れるような基準として、その文章を頼ります。設計ドキュメントを無視しないでくださ い！更新し続けてください！

QA as part of development • Once the full development actually starts, your QA staff are right there working side by side with everyone else on whatever the feature happens to be. They are designing the test cases they will need to execute on the feature while it is still in development, working in conjunction with the programmers and content producers (who are providing their input along the way) to make sure everything is adequately covered. There should be QA sub-tasks created under the main User Story/Task/Feature Request/whatever you want to call them, the testing is carried out and tracked, and that ticket can not be closed off until QA has been carried out and given it their wax seal of approval. Once it's complete, QA will then need to determine whether they should add regression tests on the feature to regular manual test runs, or whethe r the feature may be a candidate for automation. Regular manual test runs and automated tests are performed to spot regressions as soon as possible. • This should be happening with every feature that is developed, not just in the game itself but any internal tools that may be required, whether those are simple Maya plugins or a complex suite of internally developed content tools. It's especially important for QA to cast their eyes over these because t hey are being rolled out to the rest of the development team, and if there is a critical bug that wasn't spotted that prevents them from working you are losing a lot of productivity while your tools team are frantically trying to track the issue down and fix it. QA in this case should be the gatekeeper, who are not only responsible for the testing but also the ro ll out. • Especially when developing content tools, please don't fall into the trap of judging a bug based on when it may have been int roduced. It's all too easy to pass a bug off if it's already in the current build of the tools, and perhaps has been for some time, and the content producers either haven't compl ained too loudly about it or have been working around it. Judge the bug on its own merit, based on its severity and impact to the development staff. It doesn't matter if th e bug has been in there since version 0.01 and it's only just been bugged up now, it should still be fixed if it's causing your content producers headaches. Remember, QA are speaking to and working closely with everyone under this model, and they know what is and isn't causing issues. If they don't believe the next version of the animation visualiser should be rolled out without a fix for a bug, that's been around for a few versions and causes animators to lose 10 minutes each day due to needing to work around it, pay attention to them. Content producers tend to not want to stir the pot too much unless it's an obvious critical blocker (ie, the tool doesn't work), so you need to rely on your QA staff to tell you exactly how severely the bug is affecting them. If the bug is having a negative impact on someone else's work, it should be fixed; if the bug isn't causing any real loss of time, put it into the backlog. But please don't automatically shove a bug into the "maybe in a future version" pile based on how long it's been occurring. • With every feature that is developed, QA is there every step of the way. Some teams may decide to adopt a more "Agile" approach and actually embed the testers into their respective development squads. There's nothing wrong with doing that, especially if your studio is a heavily Agile environment, but I don't believe it's entirely necessary. Either way however, having the QA there working beside everyone else ensures quality on the features as they are being done, and regular test runs and automation spot any regressions that may occur. Ultimately it means far less bugs, overtime and hair pulling towards the end of the project. Your test analysts still report to your test leads and managers, who are still their direct line managers and task coordinators, but also work on supporting their test analysts, re moving QA blockers, staying on top of the overall testing goals and objectives, liaising with the development and content leads regularly, prioritising testing tasks, keeping their teams motivated and focused and even assisting in the testing effort if need be.

開発の一部としてのQA • フルの開発が始まると、あなたのQAスタッフは、実装する機能について何でも他の皆と一緒に取り組みます。彼らは、すべてが適切に網羅されていることを確 実にするために、プログラマーや（途中で入力を提供してくれる）コンテンツ制作者と一緒に働き、機能がまだ開発中である間に、機能が実行する必要があるテ ストケースを設計します。テストが実施・追跡される、主たるユーザーストーリー/タスク/機能の要求/あなたが呼び出したいものすべてに関するQAサブタスク があるはずです。QAが実行して、彼らの承認の封ろうをするまでは、それらのチケットは閉じることはできません。ひとたび完成したら、QAは、新たな機能が 彼らの定期的な手動テストの回帰テストに追加する必要があるか、または自動化の候補にできるかどうか判断する必要があります。定期的な手動テストの実行と 自動化されたテストは、できるだけ早く回帰を発見するために行われます。 • これは、ゲーム自体だけではなく、簡単なMayaプラグインや社内で開発した複雑なコンテンツツールのスイートなどのどんな内製ツールでも、すべての機能で 要求される必要があります。開発チームの他の人にツールは展開されるので、QAにとって、これらに目を配ることは特に重要です。もし着目されずに防がれな かったクリティカルなバグがあれば、ツールチームが必死に追いかけ・修正する間に、たくさんの生産性を失うことになります。この場合、QAは、テストだけ でなく、展開のための責任を負うゲートキーパーでなければなりません。 • コンテンツツールを開発する場合は、特に、バグが導入されている可能性がある状況に基づいてバグを判断する罠に陥らないようにしてください。もし、ツール の現在のビルドにすでにバスがあるのであれば、バグを見ないふりして通過させるのは非常にたやすいし、おそらくたびたびおこなわれています。そして、コン テンツ制作者は、それについてあまりにも大声で不満を言わないか、周囲で作業を行っています。開発スタッフへの重症度と影響に基づいて、独自の評価でバグ を判断しなさい。バグがバージョン0.01以降に存在していたかどうかは関係ないし、今、不満に思うかどうかだけです。コンテンツ制作が頭痛で悩んでいる限り、 それはまだ修正されるべきです。覚えておいてください。このモデルの下では、QAは、みんなと話し・緊密に協力し、問題が何かを知っており、問題を引き起 こしていません。もし、次のバージョンのアニメーションビジュアライザがバグを直して展開されると信じていなかったら、幾つのバージョンが出回り、アニ メーターはバグを回避するために必要なことを探るのに注意を払う為に毎日10分を失うことになります。コンテンツ制作者は、明らかに重大なブロッカー（すな わち、ツールが動作しない）でない限り、論議を巻き起こそうとはしません。そのため、バグの影響がどのくらい深刻なのか、あなたに正確に伝えるためにQA スタッフに頼る必要があります。バグが誰か他の人の仕事にマイナスの影響を与えている場合、それは修正される必要があります；バグが実際的な損失を生んで いなければバックログに積みます。しかし「多分将来のバージョン」のグループにどのくらいの時間がたったかに基づいて自動的に突っ込むのはやめてください。 • 開発されたすべての機能を使用することは、あらゆる面において、QAが行うことです。いくつかのチームは、より「アジャイル」なアプローチを採用し、実際 にそれぞれの開発部隊にテスターを配置しています。もしあなたのスタジオが重いアジャイル環境であれば特に、それを行うには何の問題もないですが、私はそ れが絶対に必要だとは思いません。どちらの方法でも、そばで取り組むQAを持つことは、彼らが行っているような、定期的なテストを実行し、自動化によって 発生する可能性がある任意の回帰に目印をつけるという機能上の品質を保証します。最終的に、プロジェクトの終わりに向かって、バグや残業や頭をかきむしる ことがはるかに少なくなっていきます。あなたのテストアナリストは依然として、彼らの直接のラインマネージャーとタスクのコーディネーターであるあなたの テスト・リードとマネージャーに報告するだけでなく、彼らのテストアナリストをサポートし、QAブロッカーを排除し、全体的なテストの目標と目的の上に鎮 座し、通常は開発とコンテンツリードと連携して、テスト作業の優先順位を付け、チームのモチベーションを保ち、テストを頑張る必要があれば補助することさ えします。

The end of the tunnel
•

So your project has reached the point where you need more eyes looking at it, whether you consider this phase alpha, beta, pu blic/private test or the
name you decide to call it. Note that I did not say that if you adopt the above approach that you won't need this period, you absolutely still do. Your
internal QA team can only be so large and could not possibly spot everything a larger team of testers or players could uncover. However, the role of
your internal team doesn't stop here.

•

This is the phase where they will be keeping on top of the bugs as they are coming in from the larger (often external) team, and effectively triaging
them before they ever reach development leads. They are the ones most familiar with the bugs that have previously been entered into the database
and if they spot duplicates or reports that are not bugs, they can close them off on the spot. When reports do come in that a re genuine, your internal
team then works prudently to reproduce the problem within your environment, so your programmers or content producers can fix them more
efficiently. These kinds of bugs are often difficult to reproduce so you need your internal QA team jumping onto these to try to track them down as
fast as possible.

•

Under a traditional development methodology, because minimal testing has been done, this is often the point where the proverb ial excrement hits
the fan. Suddenly there is an avalanche of hundreds or thousands of bugs and you are buried so deep in the reports that you a nd the rest of your
team can only start digging and hope the direction you are digging in is up. This in reality shouldn't be a surprise; if you' re leaving all of your testing
until the end, that's when you should expect all of the bugs to come in. But it seems this is a mistake that's repeated over and over because there's
never enough time allocated at the end of the project to test properly, to fix all of the bugs that do get raised, and to pro perly verify those fixes. More
and more games are either being delayed (sometimes multiple times) because the amount of time needed during this period was m isjudged, or are
shipping with major bugs - some of them are known but the scarier part is that a lot of them are unknown until the paying custom er gets their hands
on them. Testing is treated as an afterthought: "Oh yeah we should probably test this now", rather than treating it as a key part of the development
process every step of the way. The result is a poor quality product.

•

However, since your QA team has been testing from the very beginning and working alongside the rest of the development team a s features were
implemented, the overall volume of bugs coming in during this phase is a lot lower and a lot more manageable. This ultimately means less overtime
spent during the typical crunch period at the end of the project, less stressed and happier staff, and the project has a much higher chance of actually
shipping on time. There are also less bugs thrown into the "won't fix" pile, or the dreaded "day 1 patch" pile at the end of the project simply because
you ran out of time to fix them. This is because many of these bugs would have already been raised and fixed during the project's development, when
it was far easier, faster and less costly to fix them.

トンネルの最後 • あなたのプロジェクトは、より多くの目が必要な域に達しました。このフェーズは、アルファ、ベータ、パブリック・プ ライベートテストやそのほかにつけた名前のポイントです。私はあなたがこの期間を必要としない上記のアプローチを採 用した場合、あなたがどうしてもやらなければならないことは言っていないことに注意してください。あなたの内部の QAチームは大きくはなれるけれども、大きいテスターやプレイヤーのチームが発見できたすべてを見ることができるわ けではなかった。しかし、社内のチームの役割はこれで終わりません。 • これらは、より大きい(しばしば外部の)チームが入り、バグを最上位に据えて、バグが開発リードに到着する前に、それ らを効率的に優先順位づけするフェーズです。彼らは、最もバグに精通した者たちです。そのバグは、以前にデータベー スに入力されており、重複やバグではないレポートを見つけたなら、彼らはその場でそれらを閉じることができます。報 告が本物であったら、あなたの内部チームは、使っている環境において問題を再現するために慎重に働くので、あなたの プログラマーやコンテンツ制作者は、それらをより効率的に修正することができます。この種のバグは、多くの場合、再 現することが困難なので、できるだけ速くそれらを追跡するために、この問題に飛び込む内部のQAチームを必要としま す。 • 従来の開発方法論では、最小限のテストしか行われていないため、よく大変な事態（排せつ物を扇風機になげる）になる ポイントです。突然、数百から数千のバグの雪崩がおこり、あなたは埋められます。そこで、レポートに深く飛び込んで、 あなたとチームのメンバーは堀りはじめ、あなたが掘っている方向が上昇に転じることを期待します。これは実際には驚 くべきことではありません；もし、最後までテストのすべてを残しているなら、すべてのバグが入っていることを期待し なければならなりません。しかし、これは何度も繰り返されてきた失敗で、プロジェクトの最後に、すべてのバグを修正 し、適切に検証するような、テストを十分に行う時間が確保されていることはありません。より多くのゲームでは、この 期間中に必要な時間の量が誤判定されて遅延（時には複数回）されたり、主要なバグを抱えたまま出荷しています。この うちのいくつかは知られているが、恐ろしい部分は、購入した顧客が手にするまで知られない多くのバグが存在すること です。テストは付け足しとして扱われます：あらゆるステップを開発プロセスの重要な一部として扱うよりも、「ああ、 うん、我々は、おそらく今、これをテストする必要があります」。その結果は、低品質の製品です。 • しかし、あなたのQAチームは非常に初期からテストが行われ、機能を実装する開発チームと一緒に仕事をしているので、 この段階のバグの全体的はより少なく、より扱いやすくなっています。これは、究極的には、プロジェクトの最後に、典 型的なクランチ期間で費やされる残業が減り、ストレスが減り、スタッフが幸せになり、プロジェクトが期日通りに実際 に出荷される可能性がはるかに高くなります。プロジェクトの終了時に、あなたがそれらを修正する時間を使い果たした というだけの理由で、「解決されません」や「1日目のパッチ」に回すバグもほとんどありません。これらのバグの多く は、より速く、より安価に、はるかに簡単だった、プロジェクトの開発中の期間に発生して修正されていました。

Metrics • I know some studios put KPIs on their testers that generally tell them to raise x amount of bugs per day. With all due respect, I find that a nonsensical metric as this ultimately leads to inaccuracies. If you impose this kind of thing on them, testers will de liberately hold onto bugs once they have reached their daily quota so they can log them the next day, or deliberately raise duplicates a t the end of the day if they don't have enough, or focus on raising frivolous minor bugs in low priority areas when they should be concentrating on the more critical ones that may be more difficult to reproduce first. You don't ask your programmers to writ e x amount of lines of code per day, or your artists to create x amount of triangles per day, after all. The number of bugs a tes ter finds is in no way an indication of the amount or quality of work they do. • Using the model I propose above, your tester's time is actually tracked in a similar way to your other developer's time, thro ugh the tickets that are used to create features. The testers will be logging their time (including time spent designing and writing test cases) against these tickets just like everyone else. For any time the testers are spending not actually working on those tickets which will likely mostly be when they are carrying out test runs or exploratory (ad-hoc) testing, this time can be tracked in almost all modern test case management tools. • A metric I prefer to use is the "customer satisfaction" metric. If the customer (which can be anyone from the content produce rs using the tools to senior management or the publisher reviewing the game, or even the end users) is happy with the quality we have delivered, then we have done our job. If they spot zero or very few bugs, we have also done our job. I don't like saying "how many bugs did you find today?"; I prefer to say "Are our customers pleased with what we gave them?". This is a more positive approach that puts responsibility on your testers. They aren't under pressure or wasting time trying to raise an arbitrary am ount of bugs, but they do know they are responsible for any major bugs that might slip through the cracks, so they take extra care to make sure all of their bases are covered. They know that if a major bug pops up on a system or feature that they were responsible for testing, there will be some explaining to do. • The "quality" part of Quality Assurance does not mean "quantity" of bugs.Quality is not measured by the number of bugs found and fixed, it is measured by the number of bugs not present when the customer uses the product. It is measured by how satisfi ed the customer is when they use the product. They don't care if there were 50,000 bugs fixed during the development of the game , they only care about whether the game works the way they expect it to when they play it. That is what quality is.

メトリクス • 私はいくつかのスタジオで、KPIとしてテスターに「一日にx個のバグを上げるように」と言っていることを知っています。はばかりながら、私 はこのよう無意味なメトリックは、最終的に誤りにつながることを知っています。もしこの種のものを課すと、テスターは、日々のノルマに達 した後はバグを抱え込んで次の日に記録したり、ノルマに達していない日は意図的に同じバグを上げたり、よりクリティカルなバグを探すべき 時に優先度が低くて取るに足らないマイナーなバグを上げることに重点を置いたりします。あなたは、プログラマーに毎日x行のコードを書いた か尋ねたり、アーティストに毎日生み出した三角形の数を訪ねないでしょう？それと同じことです。テスターが見つけたバグの数は、決して彼 らの仕事の量や質の指標ではありません。 • 前記の提案モデルを用いれば、機能を作成するために使用されるチケットを介して、他の開発者の時間と同様にテスターの時間は追跡されます。 テスターはちょうどみんなと同じように、これらのチケットに対して（設計に過ごした時間とテストケースの作成を含む）活動時間をログに記 録します。（テストの実行または探索（アドホック）テストを行っているときのような）テスターが実際にそれらのチケットに取り組んでいな い時間については ほぼすべての今どきのテストケース管理ツールで追跡できます。 • 私が好んで使うメトリックは、「顧客満足度」です。顧客（ツールを使っているコンテンツ制作者から上級管理職、ゲームをレビューしている 出版社もしくはエンドユーザーなどだれでも）が成果物の品質に対して幸せなら、我々は自分の仕事を遂行しています。ゼロまたは非常に少な いバグしか見つけられなかった場合も、我々は、自分の仕事をしています。私は “どのくらいの数のバグを、あなたは今日見つけましたか？”と いうのは好きではありません。私は、「当社の顧客は、彼らに与えたもので満足していますか？」と言うことを好みます。これはテスターに責 任を置く、よりポジティブなアプローチです。彼らは報告するバグの量を増すために、プレッシャーを受けたり、時間を浪費したりしませんが、 隙間をすり抜ける可能性のある主要なバグに関して責任を持つことを知っているので、必ずそれらのベースのすべてがカバーされていることを 確認するために追加的なサポートをします。彼らは、テストする責任があったシステムや機能の主要なバグが現れた場合、説明する責任がある ことを知っています。 • 品質保証の「品質」はバグの「量」を意味しません。品質は、見つけて修正されたバグの数で測定されません。顧客が製品を使うときに存在し ないバグの数で測られます。それは、彼らが製品を使用する際、どのくらい満足したかで測定されます。ゲームの開発中に修正された50,000個 のバグがあったといてもユーザーはそれを気にしません。彼らが唯一気にすることは、ゲームをプレイするときに、期待した通りに動作するか どうかだけです。これこそが品質なのです。

Acceptance Criteria • Your QA leads and managers should be required to give sign off on the delivery of any major milestone. They base their sign off on the acceptance criteria - a previously agreed on list of quality requirements a delivery must meet. They will compose a test summary report, or TSR, that details the results of the most recent test runs - making specific note of the tests that failed and any bugs that are still unresolved. They then use this as the basis for whether the acceptance criteria have been met. The acceptance criteria can change from milestone to milestone so it's important that the expected quality standard is agreed on with all of the development and QA leads well in advance. • Senior designers/producers/tech leads/management ultimately would have the final say in whether a milestone ships out or not with known issues. However it is understood that they are the ones that are going to be held responsible if there are any ramifications due to that decision, not QA. Using this model of testing however, the number and severity of these kinds of known issues are drastically reduced.

受け入れ基準 • QAリードとマネージャーは、すべての主要なマイルストーンのデリバ リーを締結させために必要とされるべきです。彼らは、彼らが締結した受 け入れ基準（成果物が満たさなければならない品質要件のリストに載った 事前の合意）を基準として用います。彼らは、最新のテスト実行の結果を 詳述するテストサマリーレポートを構築します（失敗したテストと、まだ 解決されていないバグの詳細な記録を作ります）。そして、受け入れ基準 が満たされているかどうかの基準としてこれらを使用します。受け入れ基 準は、マイルストーン毎に変えることができます。期待される品質基準は、 すべての開発とQAのリードに事前に合意されていることが重要です。 • シニアデザイナー/プロデューサー/テクニカルリーダー/マネージャーは、 結局のところは、既知の問題に応じてマイルストーンを出すかどうかの最 終決定権を持っているでしょう。しかしながら、彼らは、QAではなく、 決定によるいかなる影響の責任も負うことになる人々であると理解されて きました。しかし、テストのこのモデルを使用することで、既知の問題の 数と重要度は大幅に減少しています。

Your QA team are professionals • Conclusively, you should not try to cut corners with QA on your game project. You might consider it a bit of a waste of time and money to be working like my above proposal, but I will say that this extra time and money is well spent. If you run into these issues late in the project instead of early, which is so very often the case, it will cost you a lot more time and money. Your internal QA team is an important resource, just as important as any of your other teams, and should not be treated as some kind of unskilled or entry level purgatory where hopeful programmers or content producers go when they can't land a job in their preferred discipline. Your QA team is not a group of hopefuls you can hire for minimum wage for a few months and then let go. Your QA team are full-time trained professionals that should be treated and paid as such. • Your QA team is there to help you. However you must restructure your development methodology, rethink your strategies and possibly change your mindset for them to do their job properly. I want to encourage studios that it's time for video games to drop the methods they have traditionally used, and widely adopt a new approach to QA. It will ultimately mean a better quality product at the end of the day. Are you willing to take the plunge?

あなたのQAチームはプロなのです • 詰まるところ、あなたのゲームプロジェクトでQAを手抜きしないでください。 あなたは、上記の私の提案のように作業することを時間とお金のちょっとした浪 費と考えるでしょう。ここで、私は、追加の時間とお金が有意義に使われること を話しましょう。もしあなたが、プロジェクトの初期ではなく、後からこれらの 問題に遭遇した場合（非常によくあることですが）、あなたはより多くの時間と お金を使うでしょう。あなたの内部QAチームは、他のどのチームとも同じくら い重要な資源であり、希望にあふれたプログラマーやコンテンツ製作者が、彼ら がより適した分野での仕事につけないときにスキルがなかったりエントリレベル の者が行く苦行の場として扱うべきではありません。あなたのQAチームは、 数ヶ月のために最低賃金で雇って、その後首にできる有望な人のグループではあ りません。あなたのQAチームは、フルタイムとして扱われ、給料が支払われる べき、訓練を受けた専門家なのです。 • あなたのQAチームはあなたを助けるためにいます。しかし、あなたは、彼らに 適切に働いてもらうために、自分の開発方法論を再構築し、戦略を再考し、おそ らく考え方を変更する必要があります。私は、QAに関して、ビデオゲーム業界 で伝統的に使われてきた技法を止め、新しいアプローチを広く採用する時が来た と、各スタジオに奨励したいと思います。それは究極的には、日々の終わりがよ り良い品質の製品を意味します。自分から進んで思い切ってますか？

おしまい