スピード感とクオリティを両立するQAプロセスを求めDeNAへ

私は「グローバル展開のためにQA基盤を構築する」というミッションを持ってDeNAにジョインしました。ちょうど入社した2011年頃が北米や中国にMobageを展開し始めた時期で、グローバルに事業を展開していく中でMobageプラットフォームの品質を高めていきたいという話を頂いたことがキッカケです。これまでは日本というマーケットだけで、スピード感を重視して縦に積み上げてきたものを今度はいかに安全に横展開していくかということが課題でした

それ以前はハードウェアを作っている会社のソフトウェアエンジニアとして働いていたのですが、ハードウェアってQAに求められる基準が非常に高いんです。機器が発火したりすると人命にも関わるので。ただ、ハードウェアのプロセスが全ての基準になっていてソフトウェアのプロセスにマッチしていないことも多かったです。もっとスピード感とクオリティをバランスよく両立させることができるはずだと感じていました。その理想の形の追求がDeNAであれば出来るのではないか、ということで入社を決めました。

手動テストの神「ゴッドハンドさん」のテストプロセスを自動化

グローバル展開を行っていく前のDeNAではスピード感を重視していたため、QAの体制やプラットフォームのテスト基盤は整っていない状態にありました。ごく一般的なQAテストは行われていましたが、そのほとんどが手動で、「テスターさん」と言われるメンバーが携帯でサービスにアクセスし、実際に操作を行って確認をしていました。

テスターさんの中にゴッドハンドと呼ばれている人がいまして（笑）。不具合を見つけ出すのがとにかく上手いんです。端末毎のクセも把握しているし、システムも理解しているので「ここは裏側でつなぎ込みをしているから怪しい」といったポイントも抑えた上でテストをしてくれていました。とても信頼していましたが、そういった達人を育てることは非常に難しいですよね。「その人がいないとテストが進まない」という状態では危険なので、ゴッドハンドさんがテストで繰り返し通る道をできるだけ技術で自動化していくことが必要だと考えていました。

また、Mobageのような共通プラットフォームの場合はユーザーさんの目に見えないバックエンドの役割も大きく、マニュアルテストだけでは足りない部分も多いんです。そして、第三者検証があるからと言って開発側で何もしないのはダメで、開発している中でも品質を上げていくという意識を高めていきたいとも感じていました。

Seleniumの導入で、手動だったユーザーシナリオテストを自動化

最初は3名で今のSWETグループの母体となるQAチームを立ち上げ、サーバーサイドAPIのテストを自動化するところから始めていきました。私が主導してリファレンスになるようなテストを書いていき、他の2人にはブラウザテストの技術調査や簡単なテストを書いてもらうという分担で進めていきました。

APIのテストがある程度片付いた後は、Seleniumというブラウザテスト自動化ツールを導入して、ユーザーの目に見える部分のテストを書いていきました。Seleniumを導入すると、プログラムを書くことで、ブラウザのボタンクリックやフォームへの入力などのユーザー操作が自動で実行されるようになります。例えばパスワードが7文字以下だったらきちんとエラーになるのか、ということを毎回手動で打ち込んで確認しなくてもいいようになります。

Seleniumを選択した理由としては、この分野ではSeleniumがデファクトになっていて他に選択肢が無かったからです。Selenium自体はツールなので、それだけではテストは書けません。実際のテスティングフレームワークとしてはRSpecを使って、つなぎにCapybaraを使っています。

実はAPIのテストの方はPerlで書いているのでブラウザテストの方もPerlで書きたかったのですが、Seleniumが公式でPerlをサポートしていなくて。非公式で使う方法もあるにはあるのですが、公式でないものは持続性が保証されていないので、テストを書くには向いていないと判断し今回はRubyを採用しました。

スマホ領域へとテストを拡大。選択した自動化ツールはAppium

APIとブラウザのテストが動くようになったので、次はスマートフォンのネイティブアプリへと拡大していきました。Seleniumを選択した時とは違い、スマートフォンの分野では自動テストツールのデファクトは今も当時も決まってはいないんですね。そこで弊社として判断の軸になったのはAndroid/iOSの両方に対応しているかという点でした。

ツールを分けてしまうと、Android用とiOS用で全く別のテストを書かねばならず、メンテナンスコストも2倍になってしまうので。今後も弊社の様々な事業分野に展開していく上でAndroid/iOSのどちらかしか作らないということはありえないので、その観点で見ると、一番有力なのがAppiumでした。

▼ネイティブアプリのテストを自動化するAppium

また、AppiumはSeleniumと同じ開発者が作成していて、基本的にプロトコルが同じ仕様になっています。極端な話をすると同じコードでSeleniumもAppiumも動かす事ができるので、既存の資産を生かすことができるというのも大きかったです。

テスト工数を大幅削減、「開発者が品質を担保する文化」も根付く

テストの数って無限大に増えていくものなんですよね。例えば1つのAPIにテストケースが40〜50個あるようなケースもあって、それをAndroid、iOS、PC、フィーチャーフォンなど各種デバイスのブラウザやアプリ上で実行した場合をそれぞれ確かめる必要があります。

ひとつの端末でしか使えない機能があったらそれもテストしなければいけませんし、これを1回1回ぽちぽち手動で実行していくのは本当に大変です。

SeleniumやAppiumのといった自動テストツールの導入により、この部分に係る工数は劇的に改善しました。工数の削減以外にも効果はあって、Seleniumを開発者自身が使えるようになったことでデバッグが簡単になったり、簡単なテストを開発者自身が書くようになったりとメリットは多かったです。

本来品質というものは開発者自身がまず担保するものだという考えが私のベースにあるので、開発の段階で品質向上を目指す文化が根づいたのは大きいですね。

テストと開発は切り離さない！テスト文化を作る2つのポイント

テスト文化を根付かせるために意識した事が2つあります。1つめはノウハウを共有して蓄積していくことです。テスト範囲が広がるにつれて必然的にチームも大きくなっていくんですよ。最初は3人で始めたチームも、自動テストの導入が進むとカバー範囲が広がってデベロッパー用サイトやMobageのSDKもテストするようになり、最終的には10人ほどのSWETグループになりました。

そこで単純にクライアントチーム、サーバーチームのように分けてしまうと情報が断絶してしまうので、お互いが何をやっているかを意識できるように常に気をつけていました。

もう1つはテストチームと開発チームを近い場所に置いて、綿密に打ち合わせをして進めていくことです。テストチームもサービスのキックオフの時から参加し、仕様から設計のレビューまで深く関わっていきました。

早い段階で問題のある仕様を取り除き、テストしやすい設計にしていくことで最終的な品質向上を目指していきました。ここが中途半端になってしまうと品質は向上していかないので、「絶対に情報はシェアしてくれ」ということを徹底していました。

テストの自動化だけに留まらず、開発に専念できる環境を作る

テストの自動化というのは、それ自体が大きな効果を上げることが多いのですが、それ自体は1つの技術でしか無いんですよね。SWETチームではテストやQAはひとつの手段と捉えていて、その上には「DeNAサービスの品質向上」と「DeNAエンジニアの開発生産性向上」という2つのミッションを掲げています。常にそのミッションを意識しながら、開発者が開発そのものに専念できるような環境を作っていきたいですね。