最終更新日: 2022年2月22日
ボルテージのQA（品質強化）についての取り組み
第一部として、『ボルテージのQA（品質強化）についての取り組み』についてお話しさせていただきます。これはQAグループだけでというよりは、ボルテージ全体で品質強化についてどういう取り組みをしてきたのか、どういう課題があってどのように解決してきたのかということをご共有できればと思います。
開発・QA体制
前段として、開発運用体制と、その中でQAがどう関わっているかを解説いたします。
基本的には、ゲームの事業部があり、それとは別で開発共通部署としてQAグループが存在しています。事業部に関しては、ゲームタイトルごとの事業部制になっています。売上や営利はゲームタイトルごとに出していくので、責任は各々もっていくということになり、基本的には最低限の人数で運営していくという思考が働いています。そのためQAなどの共通部署へのコストに関する目は厳しくなりがちという状況です。
こちらは開発の共通部署です。QA業務、インフラ、データ分析基盤構築など、直接ゲーム売上に関わらないものに関しては、ゲームタイトル所属ではなく、共通部署として組織しています。常にテストがあるわけではないですし、サーバー構築もそれほど頻繁にあるものではないので、人数を計算しづらいという点、また、各タイトルに一人だけQAがいてもなかなかノウハウがたまりませんし、テストがなかったときのリソースコントロールにも問題が生じるため、集めたほうが都合がよいという点から、開発共通本部として編成しております。ですので、基本的に共通部署に各ゲームタイトルから都度依頼するという流れになっています。もちろん共通部署のほうも人材をそれほど潤沢に抱えているわけではありませんので、依頼が来たときにテストリソースのコントロールが課題となっていました。
こちらはQAテスト体制です。現場は２名体制になっていまして、チームリーダーとテスターの２名が常駐しています。そしてAIQVE ONEさんから２名のテストリーダーとテスターの方に業務委託として常駐していただいていまして、合計4名体制です。点線のオフサイトとなっているところはまた後ほど説明いたします。
QAグループで担っているテスト業務
次に、テスト業務のご紹介です。
定常施策とありますのは、主にソーシャルゲームにおいて、月に何回か、大イベント、ミニイベントというのを繰り返して、中のストーリーの読み物や、新しい素材、特典やアバターを出して楽しんでもらうということをやっているのですが、そこに関しては機能改修が入ってこないので、基本的にストーリー通読、基本的な動作のテスト、一部仕様書に基づいたデータのテストを行っております。画像にあるのがテストの指示書になりますが、管理画面上で、ある程度こういうパラメータになっていればとりあえずOK、というテスト効率化も一部行われています。
次に、普通に新規機能追加・改修テストです。こちらに関してはデータテストはプラスですが、機能的なところを重視したテストを行っています。
そして、新規ローンチ前のテストで、ストレステストですね。連打やアプリ起動中に着信などの異常ケースをやってみたり、全体のテストケース作成を行ったりしています。結合テストが主なところかなと思います。
他端末のテストもやっていまして、今はAIQVE ONEさんに依頼して必要なものは全網羅していただいています。そして新OSバージョン、新ブラウザバージョンテストですね。iOS、アンドロイドは大きく変わることがあるので都度行っています。また弊社はガワネイティブというWebビュー中心のアプリが多く、Chromeによって動かないということがあるので、Chromeのバージョンテストも行っています。また、問い合わせや障害調査の検証のために古いバージョンの確認、文字間違いの確認、テスト項目書レビューも行っています。
品質を良くするための取り組み
品質を良くするためには、極端なことを言った場合、完全網羅したテストケースを作成して、全部しっかり時間をかけて正しくテストする―これができればOKだとは思います。
ですが、実際には、そこまでしっかりテスト項目書を作るスキルがない、時間が足りない、突発的にテストがあったときにリソースが足りないなどの理由で、様々な問題や障害が起きてしまいます。
時間がいくらでもあるわけではありませんし、経費もいくらでもかけてもいいというわけでもありませんので、最小の力で最大の力を発揮するために、QA業務を効率化し、経費コントロールもしつつ、しっかり品質担保していきたい、ということを課題としてきました。
品質を良くするためには
ビジネスの三大要素といわれる、ヒト・モノ・カネという観点で考えたときに、スキル面、システム面がモノだとすると、きちんとしたテストケースを作成する、テストした機能が正しくデプロイされるという課題がありました。
次に人・体制面です。
人はやはり一人だと観点漏れを起こしてしまうので、それをいかに埋めるかが課題でした。また、開発者以外がテストを実施し、結果をしっかりフィードバックすることが必要です。以前は、開発者自身がテストして、しっかりレビューされないまま、サービスインしたらエラーということもよく起きていました。
そしてお金の面です。
テスト工数の見積をしっかり実施して経費コントロールしていくこと、そして、緊急時でもテスト実施できる体制をいかに作っていくかが課題だと感じていました。
ここからそれぞれどのように解決していったかという話をしていきたいと思います。
スキル面・システム面
スキル面に関しては、きちんとしたテストケースを作成する知識がなく観点漏れを起こすということがよくあったので、開発者のテスト設計スキルを高める必要性を感じ、ここ数年、QAを中心にテスト項目書作成の勉強会を頻繁に実施しています。境界値分析、同値分割、ホワイトボックステスト、ブラックボックステストなどのテクニカルなことに関しては、開発者のリーダー、QAのほうも実施している実績があります。もう一つの観点として、誰が見ても間違えないテスト項目書を作るとか、いろいろなテストが一つの項目書の中に点在していたときにまとめていくということが必要になりますので、これは第三者のQA側が主に実施しました。
テスト設計にフォーカスした勉強会はやはり優先度は低くなりがちです。弊社でも、開発はモノづくりということで、まずは開発力がメインで、そこから開発のチームワークやいろいろなツールを勉強していき、どうしてもテストが最後にきてしまうということがあるので、一度体系的に知識を入れることが大事だと思っています。新卒研修でも軽く実施はしていたのですが、実践に入ってから再度体系的にスキルを入れることで実感できることもあるので、都度勉強会を開催していくことがとても大事だと感じています。ただ、テスト設計のスキルを身に着けても、それを限られた時間の中でどう使えるかというのは、開発フェーズにおいての課題かなと思っています。
次にシステム面になります。
以前までは、ステージング環境でしっかりテストをしたものの、本番でサービスインしたら、データやプログラムのデプロイミスで障害発生ということが結構ありました。以前は、デプロイサーバーから手動でアップして、本番サーバーが複数台ありますので、そこ自体はrsyncを叩くような、同期スクリプトを叩いてデプロイをしていたのですが、どうしても何か抜けてしまうとか、順番を間違えてしまうことが原因で結構障害が発生していました。これは他の会社さんでもあるのではないかと思います。
そこを解決するために、今は管理画面にデータの同期機能を入れ、ボタン押下するとある程度のデータのかたまりが自動的にいってくれるというシステム化を行い、そのあたりは自動化しています。もちろんそこには勝手に入れないような申請とか承認の仕組みは必要かなと思っています。プログラムも同じような形でやっていたので、Jenkinsを導入し、ある程度FGitのバージョンを指定したらそれがいっぺんに上がってくれるというところで自動化をはかっています。ここはいろいろな方法があり、完全なCIが理想かなと思ってはいるのですが、些細なデプロイのミスを軽減することはこれでほぼ成功できていると思います。テストというところからは少し外れますが、システム化でカバーできる部分は、自動化を行うことがとても大切だと思っています。
人・体制面
続きまして、人・体制面です。改修したい機能に関してエラーケースを想定してテスト項目を作成し、テストも完了したあと、既存機能に想定外の影響があって障害発生、ということもよくあることだと思います。特にスマホゲームは短いサイクルでどんどん機能改修をしていくので、開発者が開発に追われているケースが今でもやはり多いということがあります。テストに関して、テスト設計にじっくり時間をとれないということもあると思います。
そこを解決するために、テスト項目書の第三者レビューをなるべく入れていくということを行っています。100%はなかなか難しいのですが、エンジニアリングマネージャー中心に働きかけをして、流れはできてきているかなと思います。QAグループがしっかり業務として取り組むと宣言し、エンジニアリングマネージャーと協力してテスト項目書レビューを入れるフローの導入に成功しているというところです。
この効果としては、やはり第三者の目を入れることがとても大事だなと思っています。お互いの監視の目を入れることによって、ピア・プレッシャー効果でちゃんとしたものを出そうという意識が働くのかなと思います。
似たようなケースでもあるのですが、アーキテクトが刷新して大きな改修を入れてサービスインしたところ、大規模な障害が頻発したことがありました。数ヶ月にわたってお客さんからの問い合わせも来ましたし、開発自体もお知らせをどんどん出してもエラーが起き、またお知らせを出してという状況で開発もお問合せ部隊もQAも大変でした。
原因としては開発自体がとてもひっ迫していたというのがあります。テスト設計もテスト実施も十分ではなかったというところです。 ここに関しては、QAにも業務依頼、テスト依頼、テスト項目書のレビューも来なかったですし、全体刷新になってしまったため、テスト自体もしっかり項目書を作るというよりは、モンキーテストのように全体をテストしていくという形になってしまったことも原因かと思います。
このようなことを経まして、弊社では中規模以上のテストに関しては、QAグループでしっかりテスト実施することを推奨しております。先ほどの項目書のレビューもそうですが、テスト設計をしっかり考えるということに加え、そこに対してしっかりスケジュールを確保するという意識が働くため、品質アップにつながるのではないかと思います。実際QAグループが担っているテスト業務に関しては、大きな障害というのはほとんど起きていないかと思います。ということで、第三者の目を入れるというのがとても大事なポイントだと思っています。
第三者のレビューを入れることの施策として、これはまだ実験段階ではあるのですが、チーム以外の開発のスペシャリストへレビュー依頼できる制度に現在取り組んでいます。開発チームに関しては、基本的にそのチームリーダーとメンバーという編成なのですが、まだチームリーダーレベルですと、どうしても知見や障害に対しての経験が足りない場合があります。弊社のスペシャリストは、エンジニアの職階上位のリーダー職、30代半ばから40代くらいにかけてのベテラン揃いとなっているので、テスト観点のアドバイスや、影響範囲の指摘、障害発生後の対策レビューを一緒に考えるというフローを明示的に導入しています。スペシャリストとしても、自分と違うコンテンツを見ることで新たな知見が得られるというメリットもありますし、特にテレワークの中、自チーム以外のメンバーと触れ合うという効果があると感じています。また、弊社のコンテンツはタイトルごとに動いているため、スペシャリスト同士が横のつながりを強化できるという側面もあるので、これからの効果に期待したいと思っています。
テストリソース・経費のコントロール
続きましてテストリソースと経費コントロールの話です。
以前は、開発からQAのテスト依頼が来る期日が決まっておらず、リソースコントロールがなかなか難しい状況でした。特にルールも決めておらず、ある程度確定しないとテスト依頼が来なかったため、コントロールが難しく、どうしても余裕のあるテスター人員を確保する傾向にありました。先ほどのテスト体制で、４名体制とありましたが、以前はその2倍3倍ぐらい抱えていた状況で、ある程度一つのラインに何人かテスターのラインがあるというような形でした。
現在では、 Googleカレンダーを共有し、テスト未確定でも予約できるような柔軟な予約制度を取り入れています。この制度を取り入れたことによって、前月末までには当月のテスト工数と日時、いつ来るのかとのはほとんど把握できるような形になりました。後述しますオフサイトテストと組み合わせて常駐テスターは最低限でコントロール可能になっています。
また、今度は年単位の話になります。ゴールデンウィークや年末などの商戦期にはテスト依頼が1.5倍くらいに多くなるのですが、以前はどうしてもここに合わせてテストを確保するという状況でした。そこでオフサイトテストを導入し、突発的にテストを依頼できるような形、制度を整えています。事前に、先ほどのも含めてテスト工数を予測し、適切なコストコントロールをするということが可能になっております。基本的にはテストスケジュールが決まっているのですが、突発的なテストを入れたいという場合は、前日14時まで発注可能という形でAIQVEさんにOKをもらっていますので、今はしっかりテストコントロールができているという状況になっています。
オフサイトテストの課題と解決
ただ、やはり社外でのテスト実施ではとても非効率な部分が存在していました。セキュリティ上、管理画面は社内のネットワークからでしか操作ができず、日時やレベルなどのパラメータを設定して準備してからテストする必要性があったのです。そのため社内にいるメンバーが操作してテストをお願いし、終わったらまたパラメータ設定する必要があったので、非効率で、オフサイトには実質出せないという状況でした。
その解決としては、開発と協力し、テストアプリにデバッグ機能（パラメータを設定できるような機能）を実装し、端末のみで操作可能にして効率化をしております。ここがあとで出てくるテスト自動化にも有利になってくる場所になっています。
もう一つの課題としては、どうしても起きてしまうことですが、仕様の不慣れによる勘違いでのバグ発生ということがありました。ここに関しては、地道にテストマニュアルを作成し、何か間違いが起きたら都度アップデートしていくということをやるしかないということと、あとは定常的なテスト(仕様書がしっかりあるもの)を中心に依頼していくことですね。新規機能追加などマニュアルが存在しないものに関しては社内のテスターが実施することで、今ではQAによく依頼があるほとんどのゲームタイトルに関しては全部出せるような状態になっています。
品質について課題と解決まとめ
というところで第一部のまとめとなります。
スキル・システム面では、テスト設計の知識を取得するために勉強会を実施しています。デプロイは手作業を排除しシステム化、自動化しています
人・体制面は、テスト設計の第三者レビューを明示的に推奨、導入をしております。中規模以上の案件は開発者以外がしっかりテストを実施するというフローを取り入れ、他人の目を入れてしっかり確認しています。開発者が必ずしもテストが得意というわけではないので、テストの得意なQAグループにお願いしていくというのがとても大事だなと感じています。
リソース・経費コントロールに関しては、テスト案件をしっかり把握できるテスト依頼の仕組みを導入し、リソースを最低限にするためにオフサイトテストを導入するという方法をとっています。
このように、ヒト・モノ・カネの面において様々な課題が解決できているのではないかと思います。
品質面での課題
いろいろ解決してきたとはいえ、まだ品質面での課題は残っています。
第三者レビュー・テスト実施の浸透
先ほど言いました第三者レビュー、テスト実施の浸透というところでは、忙しいと来ないケースもまだあるので、ここはいかに啓蒙していくかが大事だと思っています。テストがこないケースで、ちょっとした開発でエラーが出ることは本当に多いので、ここをいかに無くしていくかということも課題だと感じております。
同じような事象の障害の防止
そして、同じような事象の障害の防止ですね。先ほどの大イベントやミニイベントに関しては、繰り返し同じ仕様のイベントが発生するのですが、そこをテストすると毎回同じところでエラーになってしまうということもやはりありますので、このあたりはQAからしっかりフィードバックできるような仕組みを作っていきたいと思っています。
適切な工数スケジュールでのテスト実施
最後に、適切な工数スケジュールでのテスト実施です。項目書のレビューやテスト実施をし、バグを見つけたとしても、時間がないために優先度が低く、直さずにサービスインしてみたらユーザーに影響が出たということも結構起こります。よくあるテストのシフトレフトという考え方がありますが、QAがいかに最初から案件に入ってテスト項目書を作るとか、テストスケジュールをQAの目を持ってしっかり一緒に考えるとか、そういうことをしていくのが課題かと思います。
というところで一旦第一部としては以上となります。
続きはこちらの記事をご覧ください。
【QA Tech Nightレポート】ボル恋を支えるQAとテスト自動化への挑戦【後編】（株式会社ボルテージ 高橋様）