Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ヘブンバーンズレッドのアドベンチャーパートに対するテスト手法

 ヘブンバーンズレッドのアドベンチャーパートに対するテスト手法

GREE Tech Conference 2022で発表された資料です。
https://techcon.gree.jp/2022/session/TrackB-8

gree_tech
PRO

October 25, 2022
Tweet

More Decks by gree_tech

Other Decks in Technology

Transcript

  1. グリー株式会社 QAエンジニア 勅使川原 大輔
    ヘブンバーンズレッドの
    アドベンチャーパートに対するテス
    ト手法
    グリー株式会社 QAマネージャー 野本 雅俊

    View Slide

  2. 登壇者紹介
    2

    氏名と所属

    野本 雅俊 (のもと まさとし)

    Customer & Product Satisfaction部

    WFQAチーム マネージャー

    略歴

    2012年グリーに入社。GREE PFのQA担当後、
    NativeゲームのQAへ異動。2018年からマネー
    ジャーとなる。

    主な業務内容

    WFSタイトル全般のQA統括

    各メンバーのマネジメント

    氏名と所属

    勅使川原 大輔 (てしがわら だいすけ)

    Customer & Product Satisfaction部

    WFQAチーム 

    略歴

    2016年グリーに入社。移管タイトルのQAやリ
    スク対応推進担当などを経て、ヘブンバーン
    ズレッドのβ開発からQAを担当。

    主な業務内容

    ヘブンバーンズレッドのQAチームリーダー


    View Slide

  3. 3

    1. 本タイトルにおける品質状況

    a. ヘブンバーンズレッドとは

    2. アドベンチャーパートのテスト

    a. 探索的テスト

    b. フラグ分岐の網羅

    3. まとめ


    View Slide

  4. ・新規リリースから1ヶ月程度は障害数が多くなりがち
    ・だが、本タイトルでは障害数が抑制できていた
    4

    タイトルA タイトルB 本タイトル
    90件 99件 25件
    本タイトルにおける品質状況
    リリース直後の障害数について
    リリース後1ヶ月障害数比較(大小含めた件数)
    本タイトルのQAにおける独自の取り組みが障害抑制の一因となった

    View Slide

  5. ヘブンバーンズレッドとは
    5

    フィールド バトル
    アドベンチャー

    View Slide

  6. ヘブンバーンズレッドとは
    6

    フィールド バトル
    アドベンチャー

    View Slide

  7. QAの取り組み例
    アドベンチャーパートのテスト
    • 全テストケースのレビューとフロー構築
    • スキルの組み合わせ網羅とテストデータ作成
    • アドベンチャーパートのテスト
    • 探索的テスト
    • フラグ分岐の網羅
    • ※VISUAL ARTS/Keyによる全分岐の網羅的な監修
    7


    View Slide

  8. 8

    前提課題
    アドベンチャーパートのテスト
    ゲームのメイン部分を占めボリュームが大きく
    品質を担保すべき優先度も高い
    なんかADVのスクショ

    View Slide

  9. 9

    前提課題
    アドベンチャーパートのテスト
    選択肢による分岐

    View Slide

  10. 10

    前提課題
    アドベンチャーパートのテスト
    複雑なフラグ管理
    過去の選択肢が影響して分岐する

    View Slide

  11. 11

    前提課題
    アドベンチャーパートのテスト
    それらを網羅した様な仕様書は無かった
    絶望的なイラスト

    View Slide

  12. 12

    前提課題
    アドベンチャーパートのテスト
    テキスト量が膨大
    フラグ管理が複雑
    網羅した仕様書が無い
    膨大な工数がかかる
    カバレッジを担保することが難しい
    テストケース作成が困難

    View Slide

  13. 13

    アドベンチャーパートのテスト
    テスト目的などを含むテストチャータを使用する
    詳細な手順や確認項目を記載せずテスト実行時に
    手順や新たな観点を発見していく
    探索的テスト
    "探索的テストは、仕様がほとんどなかったり、不十分であったり、テストのスケジュールに余
    裕がなかったりする場合に最も効果が大きい。他の形式的なテスト技法を補完する場合にも
    効果が大きい。"
    JSTQB Foundation Level シラバス より

    View Slide

  14. 14

    アドベンチャーパートのテスト
    各シーンで確認すべきテスト目的の粒度で記載
    探索的テスト
    シーン 対象 目的
    ADV テキスト 誤字脱字、話者名の相違などがないか
    ADV 演出 表示崩れやNG演出がないか
    ADV ボイス テキストとの相違や音量の不備がないか
    ADV 背景 状況に合った背景か
    テストチャータの例

    View Slide

  15. 15

    探索的テスト
    アドベンチャーパートのテスト
    メインストーリーは
    ゲーム内の時間単位で
    区切ってテストを行った

    View Slide

  16. 16

    アドベンチャーパートのテスト
    テンプレートを作成し
    全ての章、Day、時間帯に分割してテストする
    探索的テスト

    View Slide

  17. 17

    アドベンチャーパートのテスト
    テスト設計にかかる工数を削減し
    全てのストーリーをテストしたことが担保できた
    探索的テスト
    だがフラグ分岐の網羅はできていない

    View Slide

  18. 18

    フラグ分岐の網羅
    アドベンチャーパートのテスト
    Luaスクリプトの例
    見せる用のLua
    ※実際のスクリプトとは異なります

    View Slide

  19. 19

    フラグ分岐の網羅
    アドベンチャーパートのテスト
    Luaスクリプトの例
    見せる用のLua
    ※実際のスクリプトとは異なります

    View Slide

  20. 20

    フラグ分岐の網羅
    アドベンチャーパートのテスト
    Luaスクリプトの例
    見せる用のLua
    ※実際のスクリプトとは異なります

    View Slide

  21. 21

    フラグ分岐の網羅
    アドベンチャーパートのテスト
    全Luaからフラグをセット/参照している場所を抜き出して網羅
    Luaファイル フラグのセット/参照
    一章/Day01/午前01 SetFlag(“1章Day1でてへぺりんこした”)
    一章/Day10/夕方 GetFlag(“1章Day1でてへぺりんこした”)
    一章/Day03/昼 GetFlag(“ハンバーグカレー食べた ”)
    一章/Day03/昼 GetFlag(“カルボナーラ食べた ”)
    フラグの例

    View Slide

  22. Luaから分岐のある箇所を
    確認し全ての分岐に対して
    フラグを立てられること
    回収できることを確認
    22

    フラグ分岐の網羅
    アドベンチャーパートのテスト
    フラグ分岐のテストケース

    View Slide

  23. フラグ分岐を網羅した上で
    各分岐を探索的テストできる
    ようにしたテンプレート
    23

    フラグ分岐の網羅
    アドベンチャーパートのテスト

    View Slide

  24. 24

    結果
    アドベンチャーパートのテスト
    品質
    工数 テスト作成工数削減
    リリース1ヶ月の障害数25件
    アドベンチャーの進行不能なし
    工数と品質に大きな効果が出せた

    View Slide

  25. 25

    結果
    アドベンチャーパートのテスト
    一定の結果は出せているがまだ障害は減らせるはず
    品質を高めるため、さらなる改善に取り組んでいく

    View Slide

  26. 26

    まとめ
    ・仕様書が不足している場合は実装を基にしたテストを検討する
    ・実装を読み取りプランナーやエンジニアと対等に話せる技術知見が必要
    ・QA技術を用いて必要なテストを導くことで品質を高めることができる
    ・品質を高めるためには積極的な『攻めのQA』を意識する
    今後、これらの取り組みをQA全体で共有し
    より技術力を高めてグリーグループ全体の品質向上に繋げていく

    View Slide

  27. 27

    ご清聴ありがとうございました

    View Slide

  28. 28


    View Slide