【CEDEC 2019】グリーが目指したブラックボックステストの自動化による、高品質なテストの実現と自動化部隊の育成

9月4日～6日にかけて、パシフィコ横浜で行われたCEDEC 2019。その初日のセッションの中から、「ブラックボックステストの自動化による、高品質なテストの実現と自動化部隊の育成」の模様をお届けする。

登壇したのは、グリー<3632> Customer & Product Satisfaction部の赤﨑光氏、奥泉卓也氏の両名。

ゲームアプリ市場の成熟に伴いゲームで求められる品質レベルが年々高まり、ソフトウェアは複雑化する一方で、十分なテスト期間を確保できないケースも見受けられる。

ブラックボックステストを人力のみで実施していくことに限界を感じることも少なくない状況の中で、今話題の自動化は、効率的にテスト領域を拡張し、品質を高めることができる可能性のある手法の1つであると考えられている。

本セッションでは、ブラックボックステストの品質向上への自動化活用事例と属人化排除のためのテスターへの技術教育の取り組みについて紹介された。


▲グリーの赤﨑光氏（左）と奥泉卓也氏（右）。

まず登壇した赤﨑氏は、ブラックボックステストの自動化を導入の背景と方針について話を始めた。

元々グリーのQAチームでは、障害や費用削減の取り組みを行ってきた。ここで言う障害とは、実際に市場にアプリが出回った後の、本番環境でリリースした後に検知された不具合のことだ。

具体的に取り組んできた事としては、プロダクトの成熟度に合わせたテストケースの精査や、実際にテストを行うテスターがテストケースを使いやすくする利便性の向上、テストケースの改善、後は実際に市場で発生した障害を分析し、責任箇所の発見や発生原因、なぜQAで見過ごしてしまったのか分析。

そこから障害防止策を考案したり、開発プロダクトにセミナー形式で公表するなどの取り組みが功を奏し、年々障害数やQA費用はかなり良化している傾向にあるとした。

次に、赤﨑氏が所属しているチームの、主にWebゲームのタイトルの障害数の推移を紹介。青いグラフは2015年、緑のグラフが2019年で、1タイトルあたりの障害が減っているのがわかる。



ただ、直近の2018年の黄色いグラフと2019年の緑のグラフを見ると、特に12月以降、障害数の削減の減少率が低下してきているのがわかる。加えて「QA費用もかなり最適化されてきていて、次の対策を打たなければ」（赤﨑）というところが課題感としてあったそうだ。

そんな折、他業界や社内のエンジニアでも自動化の取り組みをしているケースを耳にしたという。そしてエンジニアによる自動化事例に着目し、QAでも何かできることはないか、という所でQA主導でゲームのテスト自動化を検討した。

その取り組みの中で2つのアプローチを準備した。1つはキャプチャリプレイツール「Selenium」。もう1つは検証用ロボット「Finger1」。この2つを使いテスト自動化にチャレンジしたという。

SeleniumはWebページの構成要素を読み取って、ブラウザの操作を自動的に行いWebサイト等の自動検証を行うツール。

「Webページの検証でよく使われているイメージですが、WebゲームもWebページを介したゲームなので、そちらでも使えるはず」と考えた赤﨑氏。端末無しでPCが動けば手軽に試せるというところで、Seleniumを手掛かりに自動化にトライした。



今回の要件は、回帰的でメンテナンス工数が安く済む施策に導入すること。これは一度コードを書いたら都度修正するのではなく、何度も使いまわしてコストを削減できるというもの。また、エンジニアが作ってエンジニアが動かすというところは簡単にできるが、実際にテストを行うテスターも簡単に使える所も目指そうと要件に加えた。

今回の導入箇所は、ガチャ施策を対象にSeleniumを実装を行っている。グリータイトルのガチャは、「ステップアップガチャが多く、ガチャを利用した回数に応じて何が出るかという補償内容だったり、ガチャのオマケで何がもらえるかという内容が変わるものが多い」と赤﨑氏。

その内容を、今まではテスターが手動で何回も回して都度内容が合っているか確認していた。しかし目視での確認のため見落とし等も出てしまう。

基本的にガチャページに遷移してガチャを実行する所がメインなので実装も簡単であることと、ガチャは基本的に種類は色々あるものの基本的に大きくは変わらないので一度作ってしまえば別のガチャでも同じようなコードを使い回せるという事で、今回はガチャをターゲットにした。



「今回、『海賊王国コロンブス』を対象にSeleniumで自動テストを実装しましたが、本タイトルではテスターがExcelのテストケースを使り、そこにテスト結果を書いて実施していたので、ExcelからSeleniumを呼び出せたら便利というところで、ExcelでVBAで実装している」と赤﨑氏。

ガチャにはIDが振られているので、そのIDを入れて何回回すか数字を入力。そしてVBAでボタンを叩いて実行すると、実際にSeleniumが起動し自動テストが始まる、という段取りになっているそうだ。



▲実際にテストを行っているデモ動画も公開。

そしてSeleniumの導入によって得られた効果について。

赤﨑氏は、「Selenium導入余地の実証を行い、どういった施策に導入したら効率的か検討できた」という。今回はガチャに実装したが、「その他、チュートリアル等は何度も通る道なので、そこが自動的に回帰テストで使えると便利だとわかり、他の自動検証ツールにもその思想が引き継がれた」と語った。

また、周辺箇所の効率化の検討や一部検証作業（テスター工数微減、目視による検証漏れのリスク削減）の自動化も実現できたという効果もあったことも加えた。

続いて、奥泉氏が登壇。検証用ロボット「Finger1」について説明していった。



Finger1とは、テクノプロ社のタッチパネル機器を検証するロボット。タッチペンによるタッチ、スワイプを行いテンプレートマッチングで画像を検出するロボットとなっている。

このFinger1を使った自動化テストに取り組んだわけだが、なぜFinger1を選んだのか？　その理由について奥泉氏は、「1つはテンプレートマッチングでキャプチャーを事前に取得して、実際にUIからその画像を探すことで整合性を判定できる点が、自動化経験が少なくても仕組みをイメージしやすかった」と説明。

また「PC等の仮想環境上での操作ではなく、実際の検証端末をFinger1上に置いて操作する形なので、ユーザーのプレイ環境に近い状況で検証を行えること」をもう1つの理由として挙げた。

今回自動化の対象としたのは、有料ガチャから新規キャラが排出されることを検証する部分で、目標の対象が排出されるまで繰り返しテストを行うというもの。


▲自動検知までの流れは、大きく実装フェーズと実行フェーズに分けられる。

実装フェーズでは、最初にベースとなる画像の取得を行う。今回は新規キャラの排出検証なので、新規キャラの画像を取得。新規キャラの排出結果画面までにはいくつかページの遷移が必要になるので、その遷移に必要なボタンなどもキャプチャーを取得する。

一通りのキャプチャー取得ができたら、処理の流れ、遷移や目標検知、検知が完了したら終了するといった処理の流れをスクリプトで実装する。

実装が完了したら、実際にFinger1での操作で目標のページまで遷移して排出結果画面へ。そこで目標とする新規キャラの画像の有無を判定するという流れになっている。


▲Finger1でのテストの様子をデモ動画で公開。

その結果として、「実際に特定の新キャラを自動検知できました。加えて、スクリプトをほぼ触らずにFinger1を動かせるシステムを実装できた」と奥泉氏。

そのシステムについて奥泉氏は「まずテストエンジニアのほうで頻出する処理をライブラリに書き、その呼び出し方をスプレッドシートに記述する形式をとっている」と説明。そうすることで処理の組み換えなどはスクリプトを編集することなく行えるため、「プログラミング経験者でなくても一部実装が可能になった」（奥泉）とのこと。


▲スプレッドシートの仕組み。処理を縦軸に並べ、横軸に処理の結果に応じた条件分岐を並べている。

ここまでの説明で、「シンプルに処理の組み換えに関してはスクリプトに手を加えず行えるので、その部分はテスターでも実装可能になり、属人化は排除できた」と奥泉氏は語った。



さて、グリーが1年間QA主導で自動化を進めてきた結果は、良かったのか？　それとも悪かったのか？

まずFinger1に関しては、端末ごとに設定変更が必要で多端末検証に向かないことを課題に挙げた。端末が変わると各種UIや画像の大きさが変わりキャプチャの使い回しがまわしができないので、それに合わせた設定変更、キャプチャの撮り直しが必要になる。グリーでは複数端末での検証を行っているため、そういうシチュエーションで工数がかかるという。

また、アームの稼働時間がかかるため、その部分でテスターと比較すると検証スピードが遅くなるという課題も。ただ、テクノプロ社でも改善が進められ、新しいマシンでは稼働スピードも倍以上になっており、今後の改善に期待できるとのこと。

続いてSeleniumについて。残る課題としては、システムの性質上Webゲームでしか使えないところが挙げられた。また、綺麗に実装されたWebページでなければ実装工数がかかり効果を発揮しづらい。

総じて、成果の部分では自動化を導入したことで人力以上の効果は出ず、QA費用の削減には至らなかったそうだ。そして若干の品質向上効果はあったものの、局所的なものに留まり、目に見えて大きな成果は出せていないという。



一方で、良かった点として、スクリプトシートの連携のようにプログラムの実装を一部テスターでも行える形式を採用する事で、エンジニアを介さない属人化排除を挙げた。これは他の自動化の部分でも有効活用できそうと感じているようだ。

もう一つは、正直当初想定していなかった部分だが、QAが自動化に取り組んだことで自動化に対する周囲のモチベーションが上がった点。今回、Finger1、Seleniumといったツールを用いた自動化にトライしたが、QA内外問わず関係するメンバーにも、他の部分で繰り返しテストを自動化できないか、という観点が生まれ、自動化が加速という。

まとめると、今回の取り組みで自動化以外の効果が出たという所は大きな成果だと感じられたそうだ。こうした自動化は、初心者でも実装できるような環境を作ったり、教育を行うことで「実はテスターにスクリプトを組んでもらうこともできるようになった」と明かす。

1年を通して自動化を取り組んだことで、「良い部分からも悪い部分からも多くの学びがありました。その学びをもとにブラッシュアップしつつ、今期はまた引き続き、様々な部分で自動化にトライしようと思っています」とまとめた。