Unity を検索

1 週間で Unity をテストする方法

2018年8月20日 カテゴリ: テクノロジー | 7 分 で読めます
取り上げているトピック
シェア

Is this article helpful for you?

Thank you for your feedback!

これは、Sustained Engineering 部門の品質エキスパートとして、私たちが常に直面している問題です。毎週、修正や改善を施した Unity の新しいマイナーバージョンを 2 つリリースしています。私たちの重要な仕事の 1 つに、これらのビルドの品質を評価し、考えられる問題を特定し、開発チームにフィードバックを提供し、アップデートのリリースにゴーサインを出すことです。この問題は、長期サポート版である LTS の登場により、さらに顕著になりました。Unity のような複雑なものを 1 週間でテストしつつ、何十万人ものユーザーの手にわたった後で、画面内のすべてのものをマゼンタピンクで表示してしまう問題が起こらないようにするにはどうすればいいのでしょうか。

ロボットに任せる

この質問に対する答えの最初の部分は、ある意味で自明とも言えるものです。自動化です。たくさんの自動化が行われています。私たちのビルドは、ユニークなものだけで約 58000 のテストをパスする必要があります。実際に実行されるテストの数はもっと多いので、「ユニークな」という言葉に注意してください。これらのテストの多くは、複数の構成や複数のプラットフォーム上で実行されます。そのため、LTS のアップデートリリースは人の手に渡る前に、期待通りの動作をするかどうかのテストが行われています。これらのテストにはさまざまな種類があります。自動化されたテストの大半は、エディターとネイティブのテストです。エディターテストは、エディターの機能を網羅するテストです。ネイティブテストは、Unity のコードの C++ 側を対象としています。それに加えて、再生モードのテスト、グラフィックステスト、パフォーマンステストなども行っています。その中の 1 つでも失敗すればビルドは作り直しとなり、失敗したテストの原因を突き止め、修正を加えて新しいビルドを作成することになります。すべてのテストに合格したビルドは、私たちの手に渡り、手動の品質保証プロセスが始まります。このプロセスには大きく分けて 2 つのフェーズがあり、修正されたと思われるすべてのバグが確かに修正されているかどうかを確認するためのケース検証フェーズと、修正によって新たなバグが発生していない、つまりレグレッションが発生していないかを確認するフェーズがあります。なお、LTS リリースと TECH ストリームリリースは同じプロセスで開発されており、同じ品質基準で開発されていますので、ご安心ください。

ケース検証

アップデートに含まれるすべての修正プログラムは、関連するバグの責任者によって検証されています。Unity の組織内にいるなら、誰でもがこの責任者となることがあります。たとえば、グラフィックスや 2D など特定の分野を専門とする組み込み品質エンジニア、クライアントからのフィードバックを受けているときにバグを提出したフィールドエンジニア、あるいは、Unity のユーザーから寄せられる何百ものレポートをバグレポートに変換する役割を担い、Unity の QA の最前線に立つ QA Student Worker チームなど、さまざまな部門の人材が責任者となります。上に挙げた人材はそれぞれ、バグが修正されたかどうかを確認する責任を負います。あるバグ修正の検証が 2 回か 3 回行われることも普通にあります。特定のリリースバージョンに修正が反映される前に、開発ブランチでも誰かが検証するからです。以上のプロセスにより、「直った」と言ったものが本当に「直った」となるように努力しています。修正がうまくいかなかった場合、バグは最初に修正を加えた開発者に差し戻されます。上記のプロセスには、ビルドが多くの人の目に触れるという良い副作用があります。さまざまな地域のさまざまな人がビルドに触れ、その品質を評価するのです。

リリース受け入れテスト

これがベースラインのテストフェーズです。これは、Unity のさまざまな領域の機能を動かしてみて、すべての基本的な部分が想定通りに動作しているかどうかを確認する、総合的な手動テストのフェーズです。3D、2D、アニメーション、XR などの主な分野をカバーしています。また、利用者の多いプラットフォームのすべてについて、すべてが正しくビルドされ動作しているかどうかをテストします。私たちは、Windows、MacOS、Android、iOS、そしてサポートしているコンソール機向けのテストを行っています。私たちのリリース受け入れテストのスイートは常に進化しており、変化を続ける機能セットに応じて内容も変えていきます。さらに、あるケースがどれだけ効果的に問題を捕捉できるかという観点で、随時、大規模なオーバーホールを行います。

ターゲットを絞った探索的テスト

前述のリリース受け入れテストは、「重要な部分がどこも壊れていない」ことを確認するフェーズです。これは通常、複数のビルド間で同じであり、リリースに含まれる修正の種類にはそれほど影響されません。修正プログラムを含むビルドで発生する可能性のあるレグレッションを特定するために、ターゲットを絞った探索的テストのフェーズを設けています。毎週、アップデートに含まれるさまざまな種類の修正を確認し、評価するミーティングを行っています。その評価に応じて、もう少し詳しく調べるべき部分を決めます。あるビルドに、多くの領域に影響を与える 2D の大規模な修正が含まれていることがわかった場合、2D 機能を中心とした探索的なテストを実施することになります。さらに具体的にするために、特定の領域のテストを担当する人は、修正箇所や追加されたコードも見て、テストの狙いをより精密なものにします。

プロジェクトテスト

ゲームスタジオが提供してくれた人気ゲームやアプリケーションの Unity プロジェクトがあります。あるバージョンから別のバージョンにアップグレードする際に、何も壊れていないかどうかをテストするために使用します。これらのプロジェクトを新しいビルドにインポートし、エディターで実行してエラーが出ないことを確認します。ほとんどの場合、ビルドを作成して、Unity のパイプラインに何も問題がないことを確認します。さらに、アセットストアのさまざまな人気パッケージ、「3D ゲームキット」や「タワーディフェンステンプレート」のようなコンテンツチームが作成したコンテンツ、そしてパーティクルや 2D 物理のような特定の分野をテストするために社内で開発されたパッケージでもテストを行います。

今後の展望

上記はすべて、LTS が可能な限り安定しており、LTS に移行してもユーザーに問題が生じないようにするために、現時点で行っていることです。私たちの取り組みはかなりうまくいっていますが、さらに良くするための努力を重ねています。そのため、皆さんが読んだ文章は、3 か月後でも完全には正確ではないかもしれません。順調に進んでいるかどうかを確認し、それに応じてプロセスを調整しています。私たちの哲学は、問題をできるだけ早期に発見し、可能であれば問題の原因となる要因を排除することにあります。私たちの最終的な目標は、LTS リリースにどれだけ多くの修正が施されても、リグレッションを「ほぼゼロ」にすることです。そのために行っていることの一例として、「根本原因分析」があります。見逃した重大な問題を特定し、なぜ見逃したのか、さらに言えば、そもそもなぜその問題が生まれたのかを考えてみます。そして、その結果に基づいて、今後同様の問題に対処するためにプロセスを最適化します。また、リリースされる Unity の全体的な品質を向上させるためのツールを探すことにも相当の時間を費やしています。開発者がコードをコミットする際に貴重なフィードバックを提供するツールから、コードのリスクの高い部分を特定してテストを最適化することを容易にするデータ分析ツールまで、さまざまなものが考えられます。これらのツールの中には、すでに役に立っているものもあれば、試作品のようなものもあり、まだ頭の中にあるものもあります。Unity は、何百万人ものユーザーに利用されている複雑なソフトウェアで、あらゆる種類のエキサイティングでクリエイティブな方法で使用されています。あのようなソフトウェアを 1 週間でテストして、入れた修正がまったくリグレッションを発生させないようにすることは可能なのでしょうか。難しい問題ですが、ぜひとも解決したいと思っています。

2018年8月20日 カテゴリ: テクノロジー | 7 分 で読めます

Is this article helpful for you?

Thank you for your feedback!

取り上げているトピック