みなさん、こんにちは。Cygamesエンジニアの折田です。

いきなりで恐縮ですが・・・みなさんは、テストの自動化にどのように取り組んでいらっしゃいますか？

テストの自動化

所属するプロジェクトによって、テストの自動化に対する運用方針も様々だと思います。
テストファーストで積極的に取り組んでいる方もいるでしょうし、開発ワークフローに組み込まれていて、仕方なく取り組んでいる方もいるでしょう。ちゃんとしたいのはやまやまだけど、そこまで手が回らないという方がほとんどかも知れません。「単体テスト」や「結合テスト」が自動化されているプロジェクトであっても、テストの最終工程にあたる「受け入れテスト」だけは自動化の対象から外されているケースは意外と多いのではないでしょうか？

膨大なコストを払ってまで「継続的インテーグレーション」や「継続的デリバリー」を実践しているのに、その最終工程の自動化は叶わず、人間のチカラに依存せざるを得ないもどかしさ。ゲーム開発の場合、画面に表示されるオブジェクトは一つ所に留まってはくれないので、それを自動プレイするだけでも大変なことです。技術的に解決すべき課題も多く、「受け入れテスト」の自動化に目処が立たないというのが本音ではないでしょうか？

厄介な「受け入れテスト」だけど、その一部だけでも自動化できたら・・・そう考えたことはありませんか？

CEDEC 2016での講演内容

私の所属する部署では、以前から「受け入れテスト」を自動化するシステムの開発に取り組んでいます。CEDEC 2016では「ゲーム開発におけるデバッグ作業の自動化」というタイトルで、その成果を発表しました。

CEDEC 2016来場者からの質問

アルバイト学生の技術指導を兼ねて作ったシステムですが、思いのほか大きな反響ありました。
CEDEC 2016の来場者の方からも多くの質問をいただきました。 この場を借りて、そのいくつかに回答したいと思います。

• 【質問】システムの開発には、どのくらいの工数が必要ですか？
• 【回答】デモで披露したカードパックの実装は1日で完了しました。その実行基盤となるシステムの構築には、それなりに時間がかかると思いますが、（多くの方が考えるよりは）ずっと簡単に実現できるはずです。スクラッチの状態から必要最低限のサブシステムを整備するのに、1ヶ月程度もあれば十分だと思います。
• 【質問】このシステムを使えば、「受け入れテスト」を完全に自動化できますか？
• 【回答】不可能ではないと思いますが、それが現実的であるとは思えません。実装仕様が二転三転する開発フェーズでは、（手戻りの幅が大きすぎて）自動化する手間が増大します。完全自動化にこだわるより、従来型のアプローチとの折衷案が現実的だと思います。定型的で実行頻度の高い検証シナリオのみを自動化し、より柔軟な対応が求められたり、実行頻度の低い検証シナリオについては、これまで通り人間のチカラを借りる方が合理的です。
• 【質問】なぜ、プログラミング言語にPythonを選んだのですか？
• 【回答】OpenCVとの親和性と生産性の高さ、Numpyをはじめとする幾何計算ライブラリの充実度が一番の決め手になりました。また、シミュレータやビデオキャプチャーデバイスを制御するために、OS固有のAPIを呼び出す必要があります。C++で開発されたモジュールとシームレスに連携できる点も重要な選定ポイントでした。

さらなるカイゼン

さらなる利便性の向上を狙って、「受け入れテスト」を自動化するシステムの大規模改修に取り組んでいる最中です。機会があれば、パワーアップしたシステムの概要をお届けしたいと思います。

もし、Cygamesに興味を持っていただけた方は、こちらの採用ページをご確認ください。