グリーのテストエンジニアとテスト戦略
galtonkatsuはじめに
こんにちは、やまもと@テスト番長です。
このエントリーは「GREE Advent Calendar 2015」7日目の記事です。
年の瀬が近づき、東京も朝晩はだいぶ寒くなってきました。
このところすっかり出不精になって、家に籠って愛犬とChromebookに癒される日々を送っております。
さて、昨年はグリーのQA体制とテストエンジニアリングへの取り組みについてお話させていただきましたが、今回は2015年のアップデートと、チームがフォーカスしているトピックなどについて書かせていただこうと思います。よろしくお付き合いください。
現在の体制
現在Quality Assurance部には社員30名・アルバイトと協力会社の方々も加えると80名ほどのメンバーがいます。
2015年後半に体制変更を行い、既存のWEBゲームなどの対応を行う「Product Operationグループ」と、主にスマートフォン向けネイティブアプリへの対応を行う「New Productグループ」という二つのグループ構成になっています。
Product Operationグループでは安定期に入ったプロダクトの運用のブラッシュアップ担い、New Productグループは開発中のプロダクトに寄り添って品質の向上を目指して頑張っています。
向き合いのプロダクトの運用フェーズや性質によって求められる対応に差があるため、このようなグループ編成となりました。
各グループ内には機能検証を受け持つスタッフのほか、審査やユーザーテストのスタッフなどもおり、総合的に品質問題に向き合える体制となっています。
開発スキルを持つテストエンジニアは両グループに在籍していて、それぞれエンジニア視点から品質向上のスイートスポットを探して日々精進しております。
地道な取り組み
Quality Assurance部では、ナレッジの蓄積やオンサイトでのデバッグ効率向上を狙って、昨年度よりアルバイトテスターさんを導入しています。ほぼ一年が経過して、彼らは次第に大きな役割を果たすように成長しつつあります。
新人からベテランまで幅広く在籍しているので、メンバーのスキルアップにも力を入れており、日々慌ただしく大きなプロダクトに関わりつつも、隔週で社内勉強会を開くなどしています。
また、社内のサイネージに障害件数の情報を発信するなど、品質意識向上のための啓発活動も行っています。
目に付きやすいところに障害情報を乗せることにためらいもありましたが、概ね好意的に捉えていただいているようです。
テストエンジニアのお仕事
さて、僕の担当しているテストエンジニアリングチームはProduct Operationチームに所属しています。
New Productグループの話は、ma3tkさんや西脇さんがこの後Advent Calendarで紹介してくれると思いますので、ここでは主にProduct Operationチームでの事例について書かせていただきたいと思います。
このところ関わらせていただいているのは、釣り☆スタや聖戦ケルベロスなどのWEBゲーム領域と、ヘルスケア事業のLespas、ライフメディア事業のLIMIAなど 新規事業系統です。
WEBゲーム領域
テストエンジニアリングというとテストフレームワークの導入やCI環境の構築、単体・自動テストの実装といった派手なイメージがまず頭に浮かびますが、
何年もサービスを続けている既存ゲームの場合、大きく根本的な変更を行うのは工数や手間の問題があり得策ではないため、障害のデータから費用対効果の大きい改善点を選び出し、運用ツールなどを強化する形で品質向上を狙っています。
ゲームにおける障害事案の中で少なからず出るのがデータの入稿ミスです。
チームでは2014年からデータの整合性確認ツールを手掛けており、他のゲームでも有効なのではということで、聖戦ケルベロスにおいて横展開を実施し、障害の削減を実現しております。
釣り☆スタでは各種イベントのCMS化を行って入稿ミスを防いでいます。
こちらはディレクターの手間の削減にもなっているそうで、運用が続くほど効果の見込める施策となっています。
また、マニュアルテスターの育成を目的とし、任意のバグを発生させられるように仕込んだダミーゲームの開発なども行いました。
新規事業領域
グリーではゲームのみならず、ヘルスケアやライフイノベーションなどの新規事業を手掛けています。
9月にサイトリニューアルを行った定額フィットネスサービスの「Lespas(レスパス)」、10月にリリースとなった住まいメディア「LIMIA(リミア)」などがあり、
リリース前検証のお手伝いをしています。
特にLIMIAでは、リリース前リグレッションの自動化を行っており、Selenium Webdriver + Node.js & Mochaでウォークスルーの検証スクリプトを動かしています。
サービス立ち上げ期は要件の変化が多いため、E2Eのテストは書きにくい面もありますが、エンバグが発生しやすい時期でもあり、荒いリグレッションでも良いのでささっと用意しておくと有効であるのを再認識できました。
今後もサービスの成長に合わせて、キャプチャの保存なども進めていければと考えています。
サービスの立ち上げ期にどの程度テストにコストを掛けるかは、色々な議論のあるところかもしれませんが、不安がつきまとうのであれば解消していくのが良いと思います。
この先の方向性について
WEB開発はどんどん高速化しており、Amazon.comが1時間当たり最大1000回に及ぶデプロイをしているという話は有名です。
高速化はテストの手段や目的、意義にも変化をもたらし、テストチームが担う役割も変化してきています。
開発〜テスト行程を高速化・省力化して発生した余剰はイノベーションに注ぎ込むことができ、サービス運営側の思いとクリエイティビティを加速していく基礎となります。そこを意識出来るかどうかで今後大きく差が出てきそうです。
グリーのQAチームでも手探りながら、この領域でのトライを続けていくことでしょう。
最後に
重要度が増すばかりのテストエンジニアですが、ソフトウェアテストへのスキル・情熱と、開発スキルの両方を兼ね備えた人材は少なく、当面その人材価値は上がっていくと思います。
更なるミッションを遂行するため、テストエンジニアリングチームでは優秀なテストエンジニアを大募集しております。我こそはという方がいらっしゃいましたら、ぜひお知らせください。
明日はma3tkさんによる記事です。乞うご期待！