バグレポート作成のコツ

管理人の独自解釈(ここ大事)によるバグレポート作成のコツを書いてみます。偉そうに書いていますが、管理人が全てのバグレポートでこれらを完璧にできているかと言えばそうではありません(ドヤ)。だいたいは検証を終えてログアウトする頃には眠気がピークなので、支離滅裂なレポートを送りつけていることもあります(赤面)。

誤解のないよう先に書きますが、バグレポートは「何をしたらどんな事象が発生した」という「報告」です。バグを再現することや検証を要求されてはいません。そもそもユーザーにできるのはトリガーの特定までであって、原因の特定は内部のデバッグツールにアクセスできる開発者にしかできません。それを手助けするための情報を提供するのがバグレポートです。

もちろん確実に再現できる手順を報告すれば原因究明の大きな手助けになることは間違いありませんので、検証好きな方はぜひ検証して報告されてください!(バグ検証は楽しいです、とても楽しいです…。でもβの場合はそこがメインではないので…はい。)

また、複数の方からの報告があることでデバイスや環境に依存するバグなのかどうかの振り分けもできます。いろんな視点からの報告が原因特定の手掛かりになる場合も少なくないでしょう。他の方が報告しているかどうかなどは気にせず、ぜひチャレンジしてみてくださいね。

Device Info

デバイスのモデル名

iOSの場合:
設定 > 一般 > 情報 で分かります。

例)iPhone 12 Pro Max MGD23J/A
例)iPad (8th generation) MYLA2J/A

モデル番号は要求されていませんが、各種デバイス情報(容量など)が判るので記入するほうが望ましいだろうと考え、記載するようにしています。

Androidの場合:
Android 端末にはさまざまな組み合わせがあります。特にグラフィック関連の問題やクラッシュの場合は、ぜひ SoC(または CPU や GPU)を調べて追記するととてもとても役立ちます!

例)Samsung Galaxy A53 5G SC-53C (DoCoMo JP); SoC Exynos 1280 (5 nm); GPU Mali-G68

遊馬さん ありがとうございます!

キャリア(DoCoMo・AUなど)によっては プリインストールされているアプリが原因で不具合が起きるケースもあるようです。(他のキャリアの端末では起きていないなど)事象によってはキャリア名も追記すると役立つでしょう。タムさん ありがとうございます!

Title/Topic

タイトル

英語で300文字まで。

検索・参照しやすくなるよう、それが何についてのバグなのかを必ず含めます。また、特定の場所で起こるなら場所名、特定の条件下で起きるなら最重要トリガーなども含めたいところです。

例)
  • 楽園の島々では光のかけらが見えなくなることがある
  • [精霊名]の記憶の解放では、記憶の断片に精霊が欠けている
  • インスタンスにプレイヤーの出入りがある時、椅子から落ちる
  • カチカチ蟹穴でスクリーンショットを取る度に異なる異常なテクスチャ

「チャットテーブルバグ」などの漠然としたタイトルは、後で見返したり検索する場合にも見つけにくいと言えます。また、似たような事象が多く寄せられているタイミングでは見落とされやすくなるかもしれません。例えば 椅子から落ちる事象 が沢山寄せられている時に チャットテーブルが増殖する バグをレポートするようなケースです。

QA チームはきちんとデータベース化しているだろうとは思いますが、ユーザーに分かりやすいことも大事ですね。

Describe the bug

事象の概要

英語で800文字まで。

事象の簡単な説明をまとめます。何をしたらそれが起きたかというような細かい再現手順は次の項に書くので、分かりやすくまとめられれば大丈夫です。タイトルをもう少し詳しく説明する欄だと考えれば書きやすいかもしれません。

追加しておきたいのが頻度や範囲。おおよその記憶でもいいので書くと役立つものになるでしょう。

  • その事象は頻発するのか滅多に起きないのか
  • 特定の条件下で必ず起きる(起きやすい)のか・初めてなのか
  • 特定の機種のみで起こるのか・その場の全員に起こるのか
  • 一時期起きなくなっていたのに再発したものならその旨

再現を試みても分からなかった場合でもガッカリせず「再現できませんでした」と記載することが役に立ちます。おんぶロケットなど他のプレイヤーの行動によるものの場合は判断がつかないことも多いですし、そういった類の事象だとの推測がしやすくなります。

原罪での事象などはそう簡単に再試行できないので「再現できるかどうかは分かりません」でもいいですね。同じバージョンでだいぶ前に行ってみたが今回だけ起きたのであれば「前回は起きなかった(起きた)」などでも役立ちます。

もう一つ書いておくと役立つのが環境。特に設定やコントローラーなどを変更して起こる場合は、その旨を必ず記載しましょう。

  • 画質モード
  • 操作設定(コントローラー・タッチスクリーン)
  • 楽器の設定
  • など

How to Reproduce the Bug

事象が起きる前後のステップ(再現する手順)

英語で800文字まで。

いつ、どこで、何をしたらそれが起きたのかを淡々と書きます。事象に至る過程も重要な鍵になるので、起こる前からのステップを書きましょう。扉バグのように、起きるずっと前にどの地方へ行って何をしたかによって起きるものもあります。

その前後に周りで何が起きていたのか どんな操作をしたのかをよく思い出しながら、できるだけ詳細に 800文字埋めるつもりで書くといいかもしれません。バグレポートに不要な情報はありません

キャンドルを灯した、闇花を焼いた、ジャンプボタンを押した、方向パッドを操作した、画面を動かした、感情表現メニューを開いた、チャットの吹き出しをタップした、飛行モードを切り替えた、ゲーム内録画を止めた、野良さんをタップしてしまった(現れた・見えた・消えたなど)、フレンドがワープしてきた、などなど。

これは管理人あるあるなのですが(こういう手順で起こった!)と思っていても、動画を見返してみると順番が違ったりすることがとても良くあります。もし動画を撮影していた場合は、見直しながら動画に含まれない情報などを思い出して追加して書き出すのがいいですね。

サーバー統合やインスタンスに出入りがあった際に起きる事象の場合、その兆候を含めると分かりやすくなります。例えばキャンドル自動点火や闇花爆発、遠くにプレイヤーのビーコンが見える、野良さんの降臨(消滅)、カニちゃんがひっくり返る(音)、装置の自動起動(の音)などです。

特にβでは、クラッシュ等の大きなバグの際にはログイン・ログアウト(クラッシュ)の時刻も記載したいところです(膨大なサーバーログから探し出して調査することを手助けします)。

とはいえ、事象のスクリーンショットや動画があり、かつ、いつ誰が見ても同じ状態 で手順も へったくれも 何もない、だだそこにあるような事象の場合は「ビデオ(スクリーンショット)を見てください」だけでも充分だと思います。例えば、記憶の断片にマンドリンが欠けているとか、したり顔の生徒ちゃんの後頭部が痛々しいことになっているとかとかとか。

Expectation

正常ならどんな動作になるはずか

英語で800文字まで。

「バグのない状態ならどうなっているはずだったか」ということを記入します。「どうあって欲しい」という要望を記入する欄ではありませんのでご注意ください。

クラッシュの報告なら「クラッシュは起きません」と明白ですね。

バグかどうか疑わしい(仕様かどうか判断できかねる)事象の場合は、「バグかどうかハッキリしないが、こうなるはずだったのではないかと思う」と書くと、もしバグではなかった場合でも開発者に「なるほど、そう受け取られるのだな」と紛らわしい事象であるということが明確に伝わります。

Attachments

添付ファイル

8MB x 3ファイルまで。

事象が起こった時に運良く動画を撮っていることは 管理人のように常に録画している変人を除いて 稀です。起こった後でもいいので、デバイスのスクリーンショットを撮って添えたいところです。

再現を試みる場合は、可能であればゲーム内録画・スクリーンショットではなく、画面収録やデバイスのスクリーンショット の方が望ましいです。プレイヤーがどんな操作をしているかが一目瞭然となります。実はこれがあれば上の「How to Reproduce the Bug」は不要なんじゃないかと思います。

動画やスクリーンショット添付の仕方はいろいろありますので「動画の圧縮」も参考にされてください。

添付の際、SkyID、連携アカウント情報、通知、コントロールセンターでの表示など、個人情報が含まれてしまっていないか厳重にチェックしてください。

Additional Information

追加情報

英語で500文字まで。

送信の途中で補足事項を思いついたり、ちょっとした間違いを訂正したりする場合に使うと便利です。βの場合は、Liveでも起こるのか(起こるのであればLiveのビルドナンバー)、なども追記したいですね。

これが正しい使い方なのかどうかは分かりませんが、管理人は「Describe the bug」や「How to Reproduce the Bug」が800文字を超えた時には、無理に削って収めようとせず、入りきれなかった分をここに書いてしまいます。

また「Device Info」にも書きましたが、Androidでのクラッシュやグラフィック関係の事象の場合は端末情報がとても重要になります。詳細にわかる場合にはこの欄に詳しく追記するのも一つの方法です。

例)
Device specs
Manufacturer: Samsung Electronics
Brand: Samsung Galaxy
Model: Galaxy A53 5G
Japanese models: SC-53C (NTT Docomo)
System on Chip (Chipset): Exynos 1280 (5 nm)
CPU (Processor): Octa-core (2×2.4 GHz Cortex-A78 & 6×2.0 GHz Cortex-A55)
GPU: Mali-G68

遊馬さん ありがとうございます!

知っていると便利かもしれない知識

あまり馴染みのない単語などは「技術系・その他」「バグ・グリッチ」にあるかもしれません。 これ以下はちょっとあやふやなところもあるので、間違いなどありましたらぜひご指導ください。 思いついたら随時追記していきます。

  • 翻訳の抜けや間違いなどはフィードバックからそっとお知らせしてください
  • Home、孤島〜天空までのそれぞれは地方(Realms)
  • 地方内の一つのマップデータがレベル(level)←ここはちょっと不安
    例えば草原交流広場と蝶々フィールドは同じレベルの別エリア
  • レベル間の移動は遷移(transition)
    例えば書庫1Fから2Fへ行く時のホワイトアウトはカットシーン
    3Fから4Fへは遷移
  • ムービーと呼んでいるもののほとんどはカットシーン(cutscene)
  • フレンドへのワープ
    星座盤からは参加(join)
    エリア内では参加(join)またはテレポート(teleport)
  • サーバーと呼んでいるものは一般的な呼称ではインスタンス(instance)
    ※便宜上開発者もサーバーと呼んでいるので、サーバーでOK
    ※物理サーバーがそんなにがいっぱいあってたまるか!(参照
  • サーバー統合とは、別のサーバーの野良さんやエリア状況ごとマージされた時
  • エリアにフレンドや野良さんのフレンドなどが参加(移動)した時は「インスタンスへの出入り」

その他のバグレポートカテゴリー記事

  1. まずは読んでください:バグレポートの前に
  2. トラブルシュートなど:既知の不具合・トラブルシュート
  3. 開始・取下・中断など:バグレポートの送信について
  4. 作成に必要な基本情報:バグレポートの作成
  5. 作成の各項目詳細情報:バグレポート作成のコツ(このページ)
  6. 最大の壁、動画の圧縮:動画の圧縮
  7. 作成した後の送信画面:バグレポート送信画面翻訳
  8. 時間帯と時差について:時間表記と時差について