QAサポート部が展開しているサービスは品質保証に関するもので『ソフトウェアテスト/第三者検証』を行っています。ではソフトウェアテスト/第三者検証とはどういった内容でどれくらいの重要性があるのでしょうか。
開発が大変だなというのはソフトウェア開発の経験がなくても何となく分かると思うのですが、ソフトウェアテストも非常に難しく奥が深い物になります。そこで今回はソフトウェアテストの重要性について説明したいと思います。

ソフトウェアテストの意義

人が作る物に完璧な物はありません。必ずどこかに間違いはあるはずです。それはバグだったり、ユーザーに不便さを感じさせる仕様など様々です。
例えばあるゲームを作ったとしても、すぐに発売できるような品質の物はできないと思います。
もしかしたら以下のような事が発生するのではないでしょうか。

・アドベンチャーゲームで、とある操作を行うとあらゆるイベントがスキップされてしまう。

・ロールプレイングゲームで、1回の釣りで入手できるアイテムは1つのはずなのに、とある操作を行うと大量にアイテムをGETできてしまう。

・3Dアクションゲームで、特定の武器を使い空中攻撃を行っている際にプレイヤーキャラクターの身体能力増強スキルを使用すると通常より高くジャンプ出来てしまい、普段は行く事のできないエリアに侵入できてしまう。

とても具体的な内容だなと思った方もいるでしょうか。
実はこれらは発売された後にも残ってしまっていたバグとなります。
ソフトウェア開発において品質を確認しておかないと、納期が遅れたり売上が下がるだけではなくブランド力の低下まで引き起こす可能性があります。
これがゲームではなく金融機関や公共交通機関のシステムだとしたら・・・・・ゾッとしますよね。
ソフトウェアテストは非常に重要な意味合いのある仕事になるという事がご理解いただけましたでしょうか。

ソフトウェアテストの7原則

ソフトウェアテスト業界も多くの人達が試行錯誤してテスト技術を磨いてきました。
ソフトウェアテストの7原則とはISTQB（International Software Testing Qualifications Board）という国際組織のテスト技術者資格制度であるFoundation Level シラバスにあるテストの基礎に記載されている考え方です。

・テストは欠陥があることは示せるが、欠陥がないことは示せない
テストをすることでバグを見つけることはできます。しかし、残念ながら絶対にバグがないとは言い切れないんですよね。（ないことを証明するのはとても難しいのですよ）
例えばUFOがいないということを証明できますか？　とても難しいですよね（汗）
どれだけテストしたとしてもバグが0だと言い切れる事はできません。
となると、限られた時間で如何に効率的にテストを行ってバグを見つけていくのか。最初の計画がとても大事な作業になってくるんですよね。

・全数テストは不可能
あらゆる状況・条件を、あらゆる組合せでテストを行うとすると膨大な日数が必要になるのは容易に想像がつきますよね。
例えばキャラクターメイキングで数千種類の組み合わせができるゲームにおいて、各組み合わせをチェックするだけでも大変だと思いますが、あらゆるシーンやイベントで全組み合わせが反映されているかをチェックするとなると・・・・・・・途方もないですよ。
ですので、実際は優先順位をつけたりしてテストを行っていく事になります。

・早期テストで時間とコストを節約
全ての実装が完成してからテストをしたとします。（そんなことやらないとは思いますが）
すると広い範囲に影響を及ぼすバグが見つかってしまい、結局は根本から作り直さないといけなくなる可能性が大きいです。
病気と一緒で治療するなら早期対処が大事ってことですね。
急がば回れとはよく言ったものです。

・欠陥の偏在
ロールプレイングゲームにおいてテキストバグの発生率が25%、グラフィックの表示バグの発生率が25%、ボイスが再生されないバグが25%、ゲームが進行不能となるバグが25%といったように満遍なくバグがある訳ではありません。
作るのが難しい箇所だったり、開発者のスキルによる所もありますのでバグが偏った所で多発するということは多々あるんですよ。
テストを行う者としてはバグの発生状況なども分析しつつ、注力する箇所をコントロールする事も重要ですね。

・殺虫剤のパラドックスにご用心
同じテストを繰り返しても各所に眠っているバグは見つかりません。同じ殺虫剤を使い続けると虫も耐性を持ってしまい効果が弱くなってしまうのと同じですね。ですので、これまでのバグの傾向を分析して、新たな観点で別のアプローチからバグを見つける必要があります。

・テストは状況次第
状況が変われば対処方法が変わるのは想像がつきますよね。
MMO RPGのテストを行う場合や、格闘ゲームのテストを行う場合、はたまたECサイトのテストを行う場合とでは考え方もテスト手法も変える必要があります。
あらゆる状況を柔軟に対応する事が大事という訳です。

・「バグゼロ」の落とし穴
多くのバグを見つけて修正できたからといって完全なシステムが構築できたかというと、必ずしもそうではない場合があります。
バグを修正した結果、使い勝手の悪いUIになっていたり、めちゃくちゃロード時間が長いゲームになっていたりするかもしれません。
バグがないからといって油断はできないんですよね。

テスト用語解説

ここではいくつかのテスト用語について解説していきます。
テストに興味を持ち始めた方、開発担当だけどテストを任されたので調べている方など参考にしていただければと思います。

・同値分割法
ブラックボックステスト手法の一つ。
同じ処理を行う入力値をグループに分割する事でテスト効率を上げる狙いがあります。
（同じ処理を行う入力値のまとまりを同値クラスとも言います）

例）
ロールプレイングゲームでスキルポイントをStrength（物理攻撃で与えるダメージに影響するステータス）に割り振る際に1～5ポイント（補正なし）、6～10ポイント（1.1倍）、11～15ポイント（1.2倍）、16～20ポイント（1.3倍）とそれぞれStrengthの値に補正がつくシステムだとします。
この場合、全パターンをテストするのではなく、それぞれのグループで代表する数値を選んでテストする事で効率化を行う訳です。

ただし、あくまでも代表値でのテストを行っているだけなのでイレギュラーなバグは発生する可能性がありますのでお気をつけください。

・境界値分析
ブラックボックステスト手法の一つ。
同じ処理を行う入力値のまとまりである同値クラスにおいて、隣り合う境界や前後の値ではバグが起きやすいという事を利用したテスト手法です。

例）
シューティングゲームでパワーアップアイテムを撃つ回数によって効果が変わるといったシステムの場合で、1～4回（スピードアップ）、5～8回（攻撃力アップ）、9～12回（防御力アップ）、13回以上（アイテムが壊れる）という場合は、境目になる数値を狙ってテストを行う事で効率化を行います。

・デシジョンテーブルテスト
条件と動作を決定表という表形式にまとめることで、複雑な条件が整理されてテスト漏れを防ぐ事ができます。

例）
格闘ゲームにおいてノーダメージで勝利した場合、10コンボした場合、超必殺技を使った場合などでクリア時のポイントが変動するといったシステムだと以下のように整理する事ができます。

・状態遷移テスト
同じイベントであっても状態によっては異なる動作を返すことがあります。
こういったシステムを状態遷移図や状態遷移表を用いてテストを行うことで、視覚的に内容を確認したり、イベントと状態の組み合わせを網羅して確認する事ができます。

例）
転職システムがあるゲームで、冒険者・騎士・重騎士・聖騎士へクラスチェンジできるのは以下のような仕様だとします。
・冒険者に転職の書を使うと騎士になる。
・騎士に転職の書を使うと重騎士になる。
・重騎士に転職の書を使うと騎士になる。
・重聖騎士になる。
・冒険者に聖書、聖騎士に転職の書／聖書を使っても変化はない。

この場合の状態遷移図は以下となります。

そして状態遷移表は以下です。

まとめ

ソフトウェアテストについてほんの入り口部分を説明させてもらいましたがいかがでしたでしょうか。ソフトウェアの品質を高めるためには様々な知識と技術が必要になります。
私の所感にはなりますが、ここ10年でゲームに関するソフトウェアテストの認識も変わって来たのではないかなと感じています。
開発工程において削減されがちなソフトウェアテスト部分の工数ですが、W字モデルが示す通り開発工程とテスト工程を同時並行で進める事でバグを早期発見・手戻りを防ぐ事が全体の品質改善につながるという認識は常識となりつつあります。

弊部ではWebサイトや業務システムのソフトウェアテスト、ゲームQAやメタバース関連アプリなど幅広い経験があります。
ソフトウェアテスト・第三者検証でお困りごとが御座いましたら是非ともお問合せよりお声がけください。