全開発者におくるデバッグ入門! 個人開発でも使えるQA Tipsや基礎的な考え方をご紹介

47.7K Views

June 13, 24

スライド概要

本スライドは2024年5月25日(土)に開催したゲーム開発者向けのリアルイベント『ゲームメーカーズ スクランブル2024』で行われた講演のスライドとなります。

タイトル:
全開発者におくるデバッグ入門! 個人開発でも使えるQA Tipsや基礎的な考え方をご紹介

内容:
どういうテストをすればいいの?テストのタイミングって?工数感はどんな感じ?といった基礎情報から、「Quality(品質)」に関する考え方、テストに求められる要件についてお話しします。

登壇者:
株式会社デジタルハーツ
QA事業本部 MS事業部 部長
渡辺 栄宏 氏

【アーカイブ記事】https://gamemakers.jp/article/2024_06_13_69326/
【イベントページ】https://gamemakers.jp/scramble2024/
【イベントレポート記事】https://gamemakers.jp/article/2024_06_04_69158/

profile-image

ゲームづくりに役立つ情報をお届けする「ゲームメーカーズ」の資料公開用アカウント。 WEBメディア「ゲームメーカーズ」では、ゲーム開発TIPSや”作り手目線”のインタビュー、お得なセール情報などを毎日更新! http://gamemakers.jp

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

(ダウンロード不可)

関連スライド

各ページのテキスト
1.

全開発者におくるデバッグ入門! 個人開発でも使えるQA Tipsや 基礎的な考え方をご紹介 © 2001-2024 DIGITAL HEARTS Co., Ltd.

2.

デジタルハーツについて Services Results for 2023 リリース前、リリース後の総合的な不具合検出 • 企画書、仕様書からテスト要件の整理 • 開発チームへのテストリーダー派遣による進行サポート • 必要なデバッグ機能のご提案 • テスト項目書の作成 • テスト実施 □ 機能チェック 実装された各機能が正常に動作しているか、特殊な状況で不具合を引き起こさないか 日本国内ゲームデバッグにおいて 10年連続シェアNo1達成 ・24年3月期予想売上高:400億円(エンタメ領域では196.5億円) ・年間合計担当プロジェクト数:1600以上 ・海外事業が急成長中。年間翻訳実績7,600万文字以上 □ データチェック 実装されたデータが仕様と異なる部分がないか □ 多端末チェック 多様なメーカー・スペック・OSによるコンパチビリティ・パフォーマンスチェック □ ネットワークチェック / 負荷チェック 想定される人数パターンで正常にプレイできるか、 同時に多人数がログインするなどの負荷がかかった状態でも問題なくプレイできるか 弊社サービスのタイトル関与率 家庭用ゲーム売上ランキング TOP100における関与率 スマホゲーム売上ランキング TOP100における関与率 □ バランスチェック ゲームの難易度に関わる要素が、意図された通りの設計になっているか □ 作成基準チェック PSにおけるTRC、任天堂のガイドラインチェック、 XboxのXRに反する内容が含まれていないか □ FPA(光過敏チェック) 光過敏性発作発症の可能性が無いか(Flash & Pattern Analyzer) 67% □ 倫理チェック 政治、人種、犯罪教唆、差別表現、青少年への悪影響などを含む 様々な倫理的な観点から懸念される表現があるか ※いずれも日本国内で開発されたゲームに限る © 2001-2024 DIGITAL HEARTS Co., Ltd. 71%

3.

デジタルハーツについて エンタメ領域グループ会社のみで日本国内16拠点、海外6拠点 TOKYO JAPAN ASIA / GLOBAL GAME TESTING LAB. SAPPORO×2 合計8000人以上の テスターが在籍 *TOKYO Lab. SENDAI Other Region KYOTO FUKUOKA×2 NAGOYA *HEAD OFFICE Group Companies In Tokyo TOKYO ×2 JetSynthesys Digital Services OSAKA MATSUYAMA KUMAMOTO © 2001-2024 DIGITAL HEARTS Co., Ltd.

4.

不具合を見つけるには? © 2001-2024 DIGITAL HEARTS Co., Ltd.

5.

不具合を見つけるには? 不具合が見えるようになる、ということが大事 では、見えるようになるとはどういうことか? © 2001-2024 DIGITAL HEARTS Co., Ltd.

6.

不具合を見つけるには? 例えば、雪の種類は何種類ある? という質問に対して © 2001-2024 DIGITAL HEARTS Co., Ltd.

7.

不具合を見つけるには? 日本人は、大体2、3種類にという答えになる ところが、海外のある国では、 雪を20種類くらいに分類している つまり、日本人は2、3種類にしか見えていないが、 その国の人は、雪を20種類に分類して見ることができる © 2001-2024 DIGITAL HEARTS Co., Ltd.

8.

不具合を見つけるには? 見えるということは、目に入った情報に対して 脳がこれを不具合だと認識をすること つまり、不具合を見つけられるようになるには、 不具合だと認識できる言葉を持つという事 目に入った情報の中で、 「これは不具合である」という認識を持てるようになれば、 不具合を見つけることが可能 © 2001-2024 DIGITAL HEARTS Co., Ltd.

9.

不具合を見つけるには? 不具合が見れるようになる=目に入った情報を脳が不具合だと認識できるようになる これはつまり、どうなっていれば正しいということが「定義」されていればよい > ~~画面のテキストは中央寄せで表示される > ◯ボタンを押すとパンチが出る > ボタンを押すとキャンセルできる これらは、「仕様」として「定義」された動作 このような情報を持っていれば、 「テキストが左寄せになっていることは不具合」 「〇ボタンを押すとキックがでることは不具合」 「×ボタンを押すと決定になることは不具合」 という認識が持てるようになる © 2001-2024 DIGITAL HEARTS Co., Ltd.

10.

不具合を見つけるには? その認識を誰でも持てる・見えるようにしたものが項目書 場所 確認項目 手順 OP 表示確認 アプリを起動 結果 日付 OK 2017/7/1 OK 2017/7/1 OK 2017/7/2 画面遷移 「ミッション」を選択 ミッション画面へ遷移できること OK 2017/7/2 画面遷移 「クエスト」を選択 NG 2017/7/3 ボタン押下しても反応せず 表示確認 自デッキを確認 表示確認 スタミナを確認 表示確認 所持金を確認 ホーム画面 表示確認 オーブを確認 表示確認 ランクを確認 期待値 備考 起動時にOPムービーが開始される こと 自デッキが正しく表示されること 画面上部左にスタミナが正しく表示 されること 画面上部中央に所持金が正しく表示 されること 画面上部右に所持オーブが正しく表 示されること 画面上部下にランクが正しく表示さ れること クエスト画面へ遷移できること 画面遷移 「マルチ参加」を選択 マルチ参加画面へ遷移できること © 2001-2024 DIGITAL HEARTS Co., Ltd.

11.

参考:項目書に書くべき内容 前ページの項目書は、実はあまり項目書としては適切な内容ではない > ~~が「正しく」表示されていること とか > ~~に「違和感がないこと」 とか 何が「正しい」のか、「違和感がない」の定義は何? そこには人によるブレが発生してしまう 項目書に書くべき内容は、確認したい期待する事項について、 正確にその内容を書く必要がある 例えば【テキストが中央で表示される】といった表示確認について、、、 テキストが正しく表示されること 〇 テキストが中央に表示されること © 2001-2024 DIGITAL HEARTS Co., Ltd.

12.

テスト・デバッグ今昔 時代と共に変化する「テスト」方法 © 2001-2024 DIGITAL HEARTS Co., Ltd.

13.

時代と共に変化する「テスト」方法 昔は… ひたすらに テスト・デバッグ 実行! バグレポートは、 紙で書いていた時代 デバッグ中はビデオに録画 出来上がったゲームを とにかく触ってみる! でも・・・ 内容が作業者任せだと 再現性がない 管理も確認も大変、、、 © 2001-2024 DIGITAL HEARTS Co., Ltd.

14.

時代と共に変化する「テスト」方法 テスト 実装 テスト 実行 内容を具体化して項目書にしよう さすがに紙レポートでは 管理しきれない、、、 項目書を消化するのに どれくらいかかる? PCを使って Excelで管理していこう! © 2001-2024 DIGITAL HEARTS Co., Ltd.

15.

時代と共に変化する「テスト」方法 テスト 計画 テスト 実装 書き込む情報が多い、、、 書ききれない、、、 Excelが重くなる、、、 Web上で管理しよう! ※チケット、タスクツールの利用 テスト 実行 見積もりや計画、 報告・情報の整理 次の開発へのFBが必要 テスト 完了 見積もりや計画を立てたけど、 状況が変化すると計画が無駄 になってしまう © 2001-2024 DIGITAL HEARTS Co., Ltd.

16.

時代と共に変化する「テスト」方法 テスト 計画 テスト 実装 テスト 実行 テスト 完了 モニタリングとコントロール © 2001-2024 DIGITAL HEARTS Co., Ltd. 状況を定量的に把握して、 臨機応変に 対応できるようにしよう!

17.

時代と共に変化する「テスト」方法 テスト 計画 テスト 分析 テスト 実装 テスト 実行 テスト 完了 テスト 実行 テスト 完了 モニタリングとコントロール テスト 計画 テスト 分析 テスト 設計 テスト 実装 モニタリングとコントロール © 2001-2024 DIGITAL HEARTS Co., Ltd. チェックの抜け漏れ がある。項目書を いきなり作り始める のではなく、まず観 点を整理しよう 項目が膨大になり がち、実施する優 先度をロジカルに 導出できない?

18.

参考:テストの規模感 現存のアプリゲームであれば 計画、分析、設計、テスト実装までで、1ヵ月~1ヵ月半 30人日程度 ※1日8h稼働として、1人日 項目書の項目数としては、30万項目~50万項目程度 © 2001-2024 DIGITAL HEARTS Co., Ltd.

19.

参考:テストの規模感 テスト実行=400~800人日 期間としては、2ヵ月~3ヵ月程度 ちなみにアプリゲームに関する話、 コンシューマーゲームに関しては、これに限ったことではなく 場合によっては、1つのゲームに対して1万人日、期間として も1年~2年、もしくはそれ以上かけてテストを行っているこ ともある © 2001-2024 DIGITAL HEARTS Co., Ltd.

20.

参考:プラットフォームについて知っておこう 個人開発で不具合知識とともに、必要になってくるものとして リリースする「プラットフォーム」に関する知識は、勉強しておくと吉 たとえば… ■PC=Steamであれば、以下の部分は気にしておく必要あり ・Achievement(いわゆる実績/トロフィーです) ・Steam Cloud(オンラインにセーブデータを保持する機能です) ・Steam Deck互換性(携帯機であるSteam Deck、ガイドライン的なものがあります) ■スマホ=iOS、Android ・AppStoreへのリリースは、「Apple審査」がある ・Google Playも「審査」アリ 各プラットフォームで、ガイドラインは必ずあるので、 「審査」に必要な情報は開発段階でも把握しておくと良し © 2001-2024 DIGITAL HEARTS Co., Ltd.

21.

参考:バグレポートに記載する情報について 仮のゲーム、特定の条件下だけでフリーズしてしまう、みたいな不具合の場合 【タイトル】デジハクエスト 【記入日】2024/5/25 【確認ROMバージョン】Ver 0.525 【概要】 エネミー①との戦闘中に、キャラ①がスキル①を使用する際に同時にキャラ②がスキル②を使用すると、画面が停まり一切の操作を 受け付けなくなることがある。 【手順】 1. エネミー①との戦闘を開始する。 2. キャラ①がスキル①を使用する。 3. 同時にキャラ②がスキル②を使用する。 【詳細】 エネミー①との戦闘中に、キャラ①とキャラ②が同時にスキルを使用した際に画面が停まる不具合が発生しています。 停止後、一切の操作が受け付けられなくなり、ゲームの進行が不可になります。 【再現度】7/10 文字だけの説明で伝えづらい場合は、更にスクリーンショットや、再現動画 等も情報として追加 © 2001-2024 DIGITAL HEARTS Co., Ltd.

22.

ユーザーエクスペリエンス(UX) 向上を目的としたQA © 2001-2024 DIGITAL HEARTS Co., Ltd.

23.

ユーザーエクスペリエンス(UX)向上を目的としたQA 服を買うとして、持ってる予算、値段以外で 気にすることは何? © 2001-2024 DIGITAL HEARTS Co., Ltd.

24.

ユーザーエクスペリエンス(UX)向上を目的としたQA 多くの人は、デザインを気にするはず =機能要件が満たされていることは当たりまえ 袖に手を通せるか、首が通せるか 穴が開いていないか? それは品質なのか? © 2001-2024 DIGITAL HEARTS Co., Ltd.

25.

ユーザーエクスペリエンス(UX)向上を目的としたQA デザインを気にするユーザーが、 そうなってて当たりまえ、という部分を重視しますか? それはゲームがおもしろい、ということに繋がっていますか? © 2001-2024 DIGITAL HEARTS Co., Ltd.

26.

ユーザーエクスペリエンス(UX)向上を目的としたQA 一般的に優先度高く対応する不具合とは、 > クラッシュ > 進行不能 > 強制終了 など、深刻度が高いものが上がってくる ユーザーが遊べなくなるのは問題 それはそれで正しいが、仮にそれが発生する条件が非常に稀であり、 ほとんどのユーザーが遭遇しえない場合 それを修正することは、ゲームのおもしろさに繋がるのか? 「品質向上」になる? © 2001-2024 DIGITAL HEARTS Co., Ltd.

27.

ユーザーエクスペリエンス(UX)向上を目的としたQA 「品質」を考える場合、障害深刻度に対する優先度だけではなく、 「ユーザー影響度」としての優先度を設け、マトリクスで判断し、 ユーザーのUX(体験)を阻害する不具合を優先で対応する 不具合ランクの 考え方マトリクス 障害深刻度 S A B C ユーザ影響度 A 高 高 中 低 B 高 中 低 低 C 中 低 低 低 © 2001-2024 DIGITAL HEARTS Co., Ltd.

28.

ユーザーエクスペリエンス(UX)向上を目的としたQA ゲームが売り切りだった時代は、発売前に不具合を取り切ることが当たり前だった これについては、近年のネットワーク環境の発展から、 いつでもアップデート可能な時代になったことで変わった 昔と違い、出したものを修正することが出来ない時代ではないので、 こういう機能を入れるとおもしろいよね、 というように、後から調整をかけるということが出来るようになった なので、ユーザーから届く意見も定量的に観測して、それをゲーム内に取り組んでいった 方がよいね、という考え方 © 2001-2024 DIGITAL HEARTS Co., Ltd.

29.

過去レポートから見た よくある不具合の要因 © 2001-2024 DIGITAL HEARTS Co., Ltd.

30.

よくある不具合の要因 第一位 96% 仕様書で定義されているとおりに動かない 原因1=仕様書通りに作れていない 原因2=仕様書の記載が足りていない(定義しきれていない) © 2001-2024 DIGITAL HEARTS Co., Ltd.

31.

よくある不具合の要因 第二位 2.5% 閾値(境界値)の不具合 特定の値から、挙動が変わる時 上限値、下限値の確認 © 2001-2024 DIGITAL HEARTS Co., Ltd.

32.

よくある不具合の要因 第三位 1% 逆観点での確認 仕様通りの定義でなければ、そうはならない、という確認 例えば、ポップアップが で消えることの確認はするが、それ以外を タップした場合でも消えてしまうということの確認 © 2001-2024 DIGITAL HEARTS Co., Ltd.

33.

よくある不具合の要因 第四位以下 ほぼ1%未満 特定の環境でしか発生しないもの 複雑な操作を必要とするもので、レアな事象なもの © 2001-2024 DIGITAL HEARTS Co., Ltd.

34.

よくある不具合の要因 まとめると 仕様書通り作成すること 閾値(境界値)の部分 そうではない場合の確認 これが出来ていれば、不具合はほぼ撲滅できる © 2001-2024 DIGITAL HEARTS Co., Ltd.

35.

最後に テストを実施する上で、大切なのは 不具合が見えるようにしておくこと ≒ 仕様書をちゃんと定義することが大事 © 2001-2024 DIGITAL HEARTS Co., Ltd.