デバッグ報告は、伝える側が正しい報告をしないと、現場が混乱します。如何に必要な情報のみを簡潔に報告するのが肝要となります。ここでは、どのようにデバッグを行い、どう報告して、最後にどう決着するのかまでを解説します。
- バグを見つける
また、事前に何を調査するのか、表にまとめておくと良いでしょう。行き当たりばったりでバグを探しても、最初は出るかもしれませんが、そのうちバグが見つからなくなっていきます。100個のアイテムがあったとして、99個まで正常でも、最後の1個で問題が出る、それがバグなのです。
…寧ろその最後の1個はバグが出やすいです。
バグが出やすい箇所はあります。それはリミットチェックと呼ばれる方法であぶり出します。リミットチェックとは、例えばアイテムの所持最大数が 100個とすると -1, 0, 1, 99, 100, 101 に相当する、アイテム数が変化するタイミングを確認する方法です。100個までなら 101 はないだろうと思うかもしれませんが、99個のアイテムを所持しているときに、一気にアイテムを 2個手に入れたら、その瞬間は 101個になります。このように下限値と上限値の数値近辺が最もバグが出やすいのです。
また、時間によるバグも出やすいです。エージングチェックと呼ばれる方法です。デバッグ方法も単純で、電源を入れてから長時間ぶっ通しでプレーし続ける等です。メモリの限界を超えて暴走する系のバグは、このエージングチェックで発見されます。このようにバグの発見にはいくつかのやり方があります。慣れてくると、動いているゲームを見ているだけで匂うようになってきます。こうなるとシメたものです。
※本屋で見かけて以来、めっちゃ気になってます。
- バグを報告する
さて、客観的事実でプログラマが欲しい情報は以下の通りです。
- バージョン番号
- 発生機種
- 発生した箇所
- 何が問題なのか
- 再現させる手順と再現率
- 影響範囲（深刻度）
バージョン番号がアプリにない場合は、そのデバッグしているアプリの作成年月日-時間をバージョン番号の代わりとします。例えば、2021/12/25 11:45 に作成されたアプリであれば、バージョン番号は 20211225-1145 とします。バージョン番号は、プログラマが既に手元では直しているのに、もう一度チェックする時間的な無駄を省くために必要です。
再現手順と再現率は最重要です。言ってしまえば、プログラマの手元で再現出来るのであれば、そのバグはほぼ取れたも同然です。時間を掛ければ必ず取れるバグという事になります。厄介なのは再現する方法がないバグ報告です。これは、バグ修正が困難な上に、修正出来たとしてもそれを確認する方法がありません。このような再現不能なバグを防ぐため、デバッグする人は自分のデバッグをフルタイムでビデオ撮影するのがベストだと言えます。プログラマなら見れば分かる事も多々あるためです。
深刻度は報告者の感性で最初は付与されます。私は以下のような区分としています。
[S] ：進行不能（例／フリーズする）
[A] ：ゲームの進行に問題が出る（例／手に入るべきアイテムが出ない）
[B] ：ゲームは進行するが問題である（例／本来行けないはずの場所に入れる）
[C] ：要望や改善、あるいは見た目だけ等（例／画面の縁にノイズが出る）
この深刻度は、 ディレクターやプログラマも確認変更します。ディレクターは好きに弄れますが、プログラマは深刻度を深くする変更だけとする等のローカルルールが存在する事があります。
最後に状況報告ですが、感覚的な内容は避けて、客観的情報を元にします。例えば「高速スクロールが遅い」という報告は、件名であれば良いのですが、報告内容に記載するには情報が曖昧です。具体的に記述するのであれば、「通常時 30FPSだが小惑星帯に突入すると 15FPS前後まで処理が落ち込む」等と記載します。重いと言われても実際どうなのかと分からないものなのです。
※ こいつ…動くぞ！
- バグを修正する
プログラマは、バグ報告の再現手順を自分の環境で再発するか確認するところから始めます。再現した場合は、ほぼ間違いなく同時にデバッガで内容を追っていますので、バグの原因はその時点で大方判明する事になります。厄介なのは、バグが出た時点で、既に何かが壊れていた等です。これは、バグがしばらく潜在化していたことを意味します。本当の発生源を見つけるのは容易ではありません。
このような場合は、プログラマはテストケースをいくつか用意して、その結果の違いからバグの場所を推察する方法を採ります。それでもダメな場合は、バグが置きそうな場所にトラップやログを仕掛けたりと、プログラマの技量が試される事になります。…と、創意工夫でバグの場所を探し出して、見つけた時は単純なタイピングミスというのもよくある話です
バグを修正したら、次の更新タイミングでバージョンを更新の上、再度修正が正しく行われたかどうかを、バグ情報システムから依頼します。このとき、同時にチェックして欲しい事項もデバッガー向けに記載する事もあります。
- バグが修正されたか確認する
最後ですが、バグ報告と要望は分けて考えろとは最初に書いてますが、明らかな要望を [A] バグと称して報告する事例が後を絶ちません。たぶん、その報告者の中では [A] バグなんだろうと、今では私は諦めて、プログラマにバグ報告を見せる前に、私がフィルタリングしてから渡すようにしています。まあ、たまに要望に本物のバグ報告が混じっている事もありますし…。
コメント
コメント一覧 (2)
それまでレポート用紙にヅラヅラ書いていただけのものを
カテゴリ分け、発生条件や再現性についてをチェック、
箇条書きにしてまとめる報告書の
書式を作ったことを思い出します。
内藤時浩
が
しました