説明｜【モンキーテスト】ゲームの話にかこつけて仕事の話をしようかな
はじめに
テスト業界、デバック界隈…
「テスター？やめとけやめとけ、薄給なのに責任が重く、加えて途方もない量のテストをさせられるからな。」
なんて言葉はしばしば耳にしますし、よく見ます。
これは世間一般のソフトウェアテスト、あるいはデバッグの世界が、広大な砂漠のどこに埋められてるのかわからないバグを見つけるかのようなイメージを持たれているから。なのかもしれません。
事実、一般ユーザーを呼んで実施される発売直前のβテストなんかは、参加した側から見てみればそういう印象を持たれるのも詮無きこと。
気になるゲームを先行体験できるという特典があるからいいものの、バグも見つけてくださいね？なんて言われても、とてもとても…。
…よっしゃ、そんなら猿になろうぜ！！
1｜猿になって
今回は、テスターじゃなくても今すぐに試せてしまうテスト手法についてご説明。
その名も「モンキーテスト」。ウキャキャ！ウキャホッキャキャキーキキホッハハキキャーキャ！ウキキ？
………
……
…
まずは辞書的な意味と、類似するテスト手法から押さえます。
①モンキーテスト
テストの項目は用意せず、思いつく限りのランダムな操作を行い、開発者が思いもよらなかった不具合を見つけるテストの方法です。仕様やデータ、テストの実施結果を想定せず気楽にあれやこれやと操作を行います。
②アドホックテスト
テストの項目は用意せず、自身の経験や業務知識、過去の不具合から想定される操作を行い、ある程度のあたりをつけて不具合を探す手法です。「●●という機能の不具合を探す！」などの目的を定めてテストします。
③探索的テスト
テストの目的、期待するテストの結果、大まかな操作方法を定めて、システムの動作を確認していきます。その確認の中で、テスターが必要だと考えた確認操作を行い結果とその操作を記録していくテスト手法です。
イメージとしては、①→②→③の順番で「テスト」に対する知識やそのシステムに対する知見が必要になっていきます。「モンキーテスト」は誰でもできる…むしろ何の思い込みもない人にこそ触ってほしいテストの方法でもあります。
もちろん、ある程度の不具合が出そうな箇所について狙いを定められるならそれに越したことはないんですが、テストをお願いする立場からすると「なんにもしてないのに壊れたんです…」という状況を意図的に作ってほしくてやってもらってるところがあります。
2｜君のための休憩タイム
ゲームのバグ探し、当たり判定の抜け探し、砂漠に落とした砂粒を拾う…無間地獄エピソードは上記のような、テスターにテストの操作をゆだねるタイプのテストで紡がれるとおぽのは考えています。
ここで３つの手法のメリデメを上げてみましょう。
①モンキーテスト
メリット：開発者も想像だにしなかった不具合を見つけられる！
デメリット：再現性がなかったり、製品側とは別の問題の可能性がある。
②アドホックテスト
メリット：見つけにくいところに潜んでいた不具合を見つけられる！
デメリット：割とテスターの能力頼みになってしまう可能性がある。
③探索的テスト
メリット：再現性のある不具合が見つかって、効率的なテストができる。
デメリット：難易度が高く、テスト実施時の目的共有が必須。
ちょっと概念的でわかりづらいですかね。でも一番知っておきたい、３つの手法全部に関係するデメリットを抑えていれば大丈夫。書いておきましょう。
それは『始めると楽しくなっちゃってずっとテストをやってしまう』というところ。ん？何か変なこと言いましたか？
このランダム性のあるテストをやることになる段階だと、重大な故障はほぼほぼ修正されています。よってほとんど出てこないはず…なんですが、これが以外にも、まだ不具合が見つかるんです。
前段階のテストで取りこぼしたのもあるでしょうが、ランダムな操作ならではの不具合がボロボロボロボロ……。
見つかると楽しくてしょうがない。なん百なん千と試行を繰り返す中で見つかる不具合は、もはやSSRといっても過言ではない。ガチャ回してる感覚に近い。だからずっとやっちゃう。
今でもたまーにゲーム系の記事で「XX年ぶりにあの『▲▲』で壁抜けバグを発見！」などの興味ない人には心底どうでもいいニュースが流れてくるのですが、これも一般のユーザーによる「モンキーテスト」の結果といえます。
「モンキーテスト」というのは、要するに辞め時がないテストなんです。
しかしそんな危険なテストを、意味ある形にまとめるのは実は簡単です。
時間で区切ればいいだけ。無限にできてしまうのであれば、管理する側は例えば「１時間のテスト、３０分のフィードバック」のような、一つのテストスパンを作ってしまえばよいのです。
よくよく考えればあたり前なことですが、これをしっかり最初に定めないことが多いこと多いこと…。「今日は6時間モンキーテストやって」などと雑に言われたら張り倒していいです。
3｜このバグはどこへ行く
ところで、バグ探しって"仕事でなければ"結構面白い作業（仕事だとプレッシャーもありますからね…）だと思うんですよ。
「SSRのバグを引くガチャの感覚」と表現して茶化していましたが、実際不具合を見つけてみると、ほかの人が知らなかった、開発側も見つけられなかった未知の領域に足を踏み入れてる感覚がおぽのにはあります。
おそらく、人生の中で裏技とかバグ技とか、そういうゲームの「秘密」に触れる機会が多かったからだと思っています。
「モンキーテスト」はまさにその、「秘密」探しにうってつけです。
1時間、●●という機能でいろいろ操作してみるか…
と自分でルールを決めてやってみます。すると、発売されている製品の不具合っていうのはそうそう見つからないようになっていることに気づくと思います。すなわち、そこまでの度重なるテストを潜り抜けてきた証左に違いありません。
発売後に不具合を見つけたら結構なラッキーなんです。いやいや、アンラッキーでしょ、と思うかもしれません。
ただ自分が見つけたゲームの秘密を、しかるべき窓口から報告することで、自分がバグを探したいほど好きなゲームが今よりもっと良い状態になる可能性があると考えると、やはりラッキーなことではないでしょうか？
バグ報告の方法も書いておきましょう。
報告は「なんか知らんけどバグで壊れた！返金せぇ！」という無茶苦茶な要求ではいけません。基本的に5W2Hを押さえて簡潔に伝えると、関係者は喜びます。
＜報告に必要な要素＞
件名：概要を1文で簡潔に書く（WhatとWhyをまとめるといい感じ）
例）●●画面で、××をn回押したとき、▲▲が発生
なにを？：件名の詳細を書きます。
いつ？：自分が見つけた日時
どこで？：そのゲームのバージョン情報、操作したデバイスなど
誰が？：大体報告者、省略可
なぜ？：その不具合が起こる直前にやった操作
どうやって？：不具合が起こるまでの操作手順
どれくらいの頻度？：n/m回（これが非常に大事）
上のリストを埋めるだけで、どなたでも簡単に不具合報告ができます。報告は、作文するのではなく、列挙していくことが大事ですね。最後に「どれくらいの頻度」？というのは本当に大切です。
これを不具合の「再現性」といいますが、この再現性のない不具合の場合、原因の特定が非常に難しいのです。なんだったら報告者側の環境が悪いから…の可能性もあります。1/1回起こったから問題だ！直せ！ではなく、不思議なことが起こったからもう一回起こるかやり直してみよう…と可能であればリトライすることが肝要です。
おわりに
今回はおぽの自身の仕事に一歩踏み込んだ話題を選んでみました。「モンキーテスト」は息抜き感覚でやってみると結構成功します。
本来なら根詰めてまでやる手法じゃないとおぽのは思ってるので、この場では、誰もが準備も知識も不要で気軽にできるテストとして説明しました。
自分の大切なゲームデータをぶっ壊さない程度に、好きなゲームであれこれやってみると新しい発見があるかもしれません。
「どうするとぶっ壊れるか」？
うーん、一番簡単なのはデータのやり取り中に非正規な方法でゲームをストップさせるのが壊れやすいです。「ゲームセーブ中に電池切れを起こす」とかね。自分で遊んでいてヒヤッとする瞬間を思い浮かべてください。大体それがあってます。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？