NativeGameの障害削減に向けた取り組み

by gree_tech

Slide 1

Slide 1 text

グリー株式会社　WFQAチーム　マネージャー　野本雅俊  NativeGameの障害削減に  向けた取り組み  グリー株式会社　WFQAチーム　　　　　　　　奥泉卓也 

Slide 2

Slide 2 text

Copyright © GREE, Inc. All Rights Reserved. 自己紹介氏名と所属  野本　雅俊  (のもと　まさとし)  Customer & Product Satisfaction部   WFQAチーム　マネージャー   主な業務内容  NativeゲームのQAマネージャー   WFSタイトル全般のQA統括   各メンバーのマネジメント   略歴  SIerでエンジニアを経験後、NTTひかり電話関連システムのQA担当を経て、2012年グリーに入社   GREE PFのQA担当後、NativeゲームのQAへ異動。複数タイトルの国内外リリースを成功させ、2018年からマネージャーとなる。   氏名と所属  奥泉　卓也  (おくいずみ　たくや)   Customer & Product Satisfaction部   WFQAチーム  主な業務内容  Nativeゲーム（WFSタイトル）のQA担当   横断的な障害削減  略歴  SIerでインフラエンジニアとしての業務を経て、2018 年グリーに入社。  当初は移管タイトルのQA立ち上げを担当し、2019年から自社開発Nativeゲーム   （WFSタイトル）のQAを担当。  

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Copyright © GREE, Inc. All Rights Reserved. a.集計方法の統一    ● 全タイトル共通の基準として「重大度」を設定    ● S：返金のリスクがある不具合、大規模な進行不能/データロスト  ● A：広範囲/イベント報酬関連の不具合、IPを傷つける恐れがある不具合  ● B：条件や範囲が限定的な不具合  ● C：回避手段がある/軽微な不具合  ● D：プレイに影響のない不備・改善余地    ※Cランク以上を削減対象として設定  今までの記載基準  改善後の障害集計基準 

Slide 8

Slide 8 text

Copyright © GREE, Inc. All Rights Reserved. a.集計方法の統一    記載する情報をルール化  ● 見逃し原因  ● 概要  ● 重大度  ● 補填  ● 対策  タイトルA  問い合わせ内容  影響度  タイトルB  概要  対応  補填有無  タイトルC  概要  詳細  今後の対策  タイトルD  概要  対策  補填有無  過去の情報記載粒度  改善後の情報記載粒度 

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Copyright © GREE, Inc. All Rights Reserved. c.再発防止の実施  QA責障害  QA起因の障害    テスト実施漏れ  テスト設計漏れ  開発責障害  開発起因の障害  QA未依頼  QA後修正  テスト範囲外  グレー障害  開発、QA双方で考慮が難しい不具合  テスト  範囲外  （暗黙的）  外部要因障害  テストでの検知が難しい障害  端末依存  環境依存  原因別に効果的なアプローチを検討する  各障害見逃し原因の概要 

Slide 11

Slide 11 text

Copyright © GREE, Inc. All Rights Reserved. ヒューマンエラーであるという点に着目  …システム的に再発を防ぐ方法を検討    ● 特に効果的なのが「データ上の不具合」  ○ 開発への事前の入力値チェックの提案  ○ マスタデータの可読化  ○ マスタと仕様の自動比較(データ検証)    c.再発防止の実施  目視チェック  テスターの技量やコンディションによって見落としの可能性が生じる  データ検証  テスターの技量やコンディションに左右されづらく、見落としリスクが低い  テスト実施漏れ 

Slide 12

Slide 12 text

Copyright © GREE, Inc. All Rights Reserved. c.再発防止の実施  ナレッジの蓄積で再発防止を図る    タイトル内で  振り返り  他タイトルで  ナレッジ活用  設計観点の追加  横断レビュー  横断的な  設計観点の追加  例：  ● ランイベ用キャラ  ○ 実戦に近い状態での実機テストを実施  ● 特殊スキル  ○ 比例・反比例による性能変化等の境界値分析テストを実施  ● 既存の取り組み  テスト設計漏れ 

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Copyright © GREE, Inc. All Rights Reserved. ● BTS化や指標の共通化を行うことは工数面でもメリットがあった  ● 共通指標を使うことでタイトルごと横並びで分析できるようになった  ● QA責障害の可視化によりナレッジ蓄積が行え、再発防止を強化できた  ● 結果としてQA責の障害数を35%削減することに成功      ４．まとめ  導入は面倒だし効果に疑問もあるかと思いますが、  障害が減らないことに悩んでいるチームはぜひやってみてください！     

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyright © GREE, Inc. All Rights Reserved. b.分析軸の策定  タイトル名  S  A  B  C  Aプロジェクト  1  2  8  11  Bプロジェクト  0  2  4  6  ・・・          タイトル名  テスト実施漏れ  テスト設計漏れ  テスト範囲外  ・・・  Aプロジェクト  0  1  6    Bプロジェクト  1  0  8    ・・・          集計した情報をもとに現状把握  ● 週次で状況共有を実施  ● 発生状況や見逃し原因、作りこみ原因、重大度を確認    分析を効率化できる軸を検討  現状の把握…タイトル横並びで情報を集計     

Slide 17

Slide 17 text

Copyright © GREE, Inc. All Rights Reserved. c.再発防止の実施  テスト範囲外  （暗黙的）  ピンポイントでの対策にしない  …単体の事象をもとに、アプリの構造を深堀していく  例：武器に新レアリティ追加の結果、特定クエストが進行不能  ● 特定クエストでキャラが装備している武器のレアリティを参照するロジック   ● 該当クエスト側に新レアリティに対応する実装がないのが原因   ● 武器追加時に今回障害が発生したクエストを進行して問題がないことを見る   ピンポイントの対策  ● 他に関連付けが難しいテーブルを参照しているクエストがないか精査し、観点追加   望ましい対策  見逃し原因ごとの傾向を探る：グレー 