バグ（不具合）が生じる傾向を分析。危険な不具合を予測して発見するコツ

今回はこの点について言及していきます。

バグ（不具合）って予測して発見できる？

バグ（不具合）がどこでどう起きるのか、
これが最初から分かっていたらテストとしては相当楽になりますよね。

というより、それが分かっていれば、
エンジニアに「この点注意して実装してください」とお願いすれば、
そもそも不具合を起こす事なく開発が終わることになります。

そんな予言めいたことを100%完全に的中させることは不可能ですが、
可能性を上げることは可能です。

必ず開発チーム毎にウィークポイントというのは存在していて、
「前もこんな不具合が出た気がする。なんか同じような失敗を繰り返している気がする」
というような事がよくあります。

そのウィークポイントが生まれる要因は、

など様々ですが、
これらの問題がゼロの開発チームはほぼ存在しないと経験上断言できます。

そういった点を踏まえつつ、
以下の辺りの「分析」と「見定め」をする事で、

「今後発生する可能性のある不具合の予測を立てる」

「危険箇所を早期にテストする」

という事が可能となり、
不具合の防止や早期発見の効果が期待できます。

尚、
今回はそれらを踏まえて「デバッグチームとしてできること」として、
「どうやって早期に不具合を発見するか」という点にフォーカスして話をしていきます。

（エンジニアや開発チーム全体でバグに取り組む事が一番効果はありますが、まず、デバッグチームとしてできることは何だろうというところで、今回はお話をさせていただきます）

バグ（不具合）が生じる傾向や見定めをどうやって行う？

チームの過去の不具合傾向（端末関連系）

まず過去に同タイトル内で発生した不具合を見直してみるところから始めます。

そうすると、
ポツポツと「同じような不具合を繰り返しているな」というようなものが見えてくると思います。

今回はスマホゲームを一例として、
「よくある繰り返しがちな不具合例」としては以下のようなものがあります。

上記のように、
端末Aでは問題ないが端末Bでは問題がある、というようなケースがよくあります。

必ずと言っていいほど繰り返し起こる不具合なので、
その観点を狙って早期にテストをする事で問題を早期に見つける事が望めます。

①について、
表示周りでは、
通常の16:9のようなスマートフォン端末では問題ないが、
タブレット端末では表示が崩れてしまうといった事がよくあります。

例えば、ボタンの位置がおかしくなってしまったり、背景の両端が切れてしまったりなどです。

どんな端末であっても正しく表示されるようにすることをレスポンシブ対応と言います。
この点はよく対応が漏れる筆頭なので、
新しい画面が追加されたらテスト開始時にいくつかの端末でまず確認してみて、
対応漏れがないかチェックすることをオススメします。
（この点は大体の場合が、想定外の不具合というよりは、エンジニアの対応忘れである事が主です）

②について、
動作周りでは、
iPhoneでは問題なくサクサク動くがAndroidでは動作がカクつくといったような事はよくあります。

昨今のゲームはどんどんクオリティが上がりリッチになっていますが、
それに伴い端末に求められるスペックのハードルも上がっています。

リッチなゲーム且つ、しっかりとした対策をしているゲームは必ず「軽量化や最適化」という工程が開発の中に含まれます。

見た目はリッチで高クオリティであっても、
それがほんの一握りの高スペック端末じゃないとプレイできないとなると、
プレイ人口は限られてしまうので、収益に大きなダメージとなってしまいます。

また、逆も然りで、
発売直後の最新スマートフォンや最新OSverに対応していないために、
ゲームが正常に動作しないといったこともあります。

スペックの高低差に加え、新しい端末やOSにも対応する必要があるとは分かっていても
なかなか対応が追いつかないこともよくありますので、
表示周り同様にまず最初は動作においても、最低限いくつかの端末で確認することで発見できることはあると思います。

③について、
バックキーというようなAndroidだけにある特有のボタン（一つ前の画面等に戻るボタン）がありますが、
OSによって差異があるような部分も漏れる事がよくありますので注意が必要です。

チームの過去の不具合傾向（ゲーム内機能関連系）

この点も同様に、過去に同タイトル内で発生した不具合を見直してみる事で見えてくる点があると思います。

同様にスマホゲームを一例として、
「よくある繰り返しがちな不具合例」を挙げます。

ゲームの機能について上記の点は比較的起きやすい不具合になります。

①について、
新しい画面Xが実装された時、その画面に進むための方法が複数あるというケースに対して、
例えば画面AからXに進行した場合は問題ないが、
画面BからXに進行した場合はエラーになってしまうなど、
網羅的に対応できていないというのはよくあります。

正直なところ進入経路を絞る実装が一番安全ではありますが、
利便性の為にいろんな画面から進行できるようにしている、というのはあると思います。

そういったケースに対して、
網羅的に進行テストをする事は効果的です。

②について、
昨今のゲームでは「スキル」という必殺技のようなものを使うものが多く、
耳馴染みも多くスタンダードなものとなっています。
そんなスタンダードなものであっても不具合はよく起きます。

ただし、
スキルを単体で使用した場合には特に問題はないが、
他のスキルと掛け合わせるようなケースにおいて問題が起きる事が主です。

スキルの組み合わせチェックというのはデバッグにおいては必ず行う鉄板のテストですが、
スキルの種類が何百何千とある場合、全ての組み合わせをチェックすることは困難なので、
時間が許す範囲の中で優先度をつけてチェックをすることになります。

つまりテストの優先度を低くしてテストを行わなかったものから不具合が起きてしまうということも往々にしてあります。

（エンジニアも組み合わせは想定していますが、その数が多すぎると当然実装から漏れてしまうこともあります）

ではそのテスト優先度をどうするべきか、という点が重要ですが、
一度優先度を決めた上で「毎回全く同じ優先度でテストを行う」という方法では、
しっかりチェックすると部分と、全くチェックされない部分とがしっかり分かれてしまい、
リスクヘッジにおいてはやや不安が残ります。

ベースの優先度はありつつも、
「思いつく範囲で組み合わせた方がいいと思われるもの」
「エンジニアにヒアリングしてチェックした方が良さそうなもの」
については毎回テスト観点として取り入れる事で不具合の発見に繋がると思います。

③について、
これはいわゆる「カンスト」への対応になります。

カンストがあることはエンジニアもデバッガーも当然理解はしているものの、
うっかり漏れる事が多い点ではあります。

よくある例としては、
レベルがカンストした時に経験値の「次のレベルまで」の数値がおかしくなってしまったり、
あるいはまだカンストしていないような表示のままであったり等ですね。

上記の範囲であればまだ表示だけではありますが、
「カンストに到達するとエラーになってしまう」というな事があってはインパクトが大きいので、
早い段階でチェックする事をオススメします。

④について、
これは「オンラインゲームあるある」です。

オンラインゲームである以上、
通信を行いながらゲームが進行しているのは当然ですが、
Wifi環境などの何らかの問題で通信が切れてしまうというケースというのは必ず開発で想定しておく必要があります。

この点、案外実装が漏れてしまう事が多く、
本来通信が切れると「通信が確認できません（リトライ / タイトルへ）」のようなメッセージが出て、
通信を再接続した上で「リトライ」を行う事でゲームに復帰できるようなものが多いですが、
例えば通信が切れても何もメッセージが出ずにそのまま進行不能になってしまうなどのケースがあります。

場合によっては「貴重なアイテムを手に入れていたのに復帰できずに入手できなくなってしまった」
のような大問題に繋がることもありますので、
通信の観点は必ずチェックする必要があります。

バグ（不具合）が起きた時のインパクトが高いと想定される箇所の見定め

上記まではチームでの今までの傾向を見て対策をするという考え方でしたが、
それとは別に「もしもこの機能で不具合が起きたらヤバイ！（炎上しそう）」という点があると思います。

そういった点を考えつつテストする順番を考えると自ずと危険な不具合から先に検知しやすくなるため、
「テスト期間の最後の方で大きな問題が発覚する」というケースを回避できる可能性が上がると思います。

スマホゲームでいうと、
以下のような優先度の考え方が一般的になると思います。
（課金に近いポイントほどリスクが高いので先にチェックをしたい）

「もしもこの機能で不具合が起きたらヤバイ！」というのは、

・お金に関わる部分だからヤバイ

・ゲームとして成立しなくなるからヤバイ

という2点がまず大きくあるので、
このような優先度になっています。

もちろん最終的には他の部分も含め全ての不具合を防がないといけませんが、
まず上記のような大きな危険ポイントから先に防いでいく事が安全な進行と言えます。

この考え方は常に持つことがデバッグにおいては重要となります。

今回は不具合の傾向、分析、予測を踏まえて、
早期のリスクヘッジという点についてお話しさせていただきました。