はじめに
運用タイトルの施策は、大枠は変更せずに中身のみを変更するいわゆる「定常施策」と呼ばれているものが多く存在します。
その定常施策のテストケースも、工数削減のために一部箇所のみを修正して流用することが多いのですが、その際に変更漏れや期待結果のミスなどが発生したことはなかったでしょうか？
今回は、私が担当したタイトルで取り入れた「レギュレーションテスト」についてお話をさせていただきます。
障害削減やテスト設計漏れに貢献しているものなので、興味のある方は参考にしてみてください。
「レギュレーションテスト」とは？
言葉通りとなるのですが、開発チームが作成したレギュレーションを事前に共有してもらい、
その内容に沿って設定されているかを複数施策にて共通で確認するテストとなります。
「普通にテストケースに盛り込めばいいのでは？」
と思うかもしれませんが、レギュレーションによって期待結果が異なる場合、
手書きによる誤記載や、更新漏れなどのリスクも発生します。
このような場合に、レギュレーションと確認観点のみを記載し、
期待結果をテスター自身に導き出してもらうというものを「レギュレーションテスト」と呼んでおります。
※注意①※
あくまでもテストケースを実行後にフリーテストと並行して実施しており、テストケースありきで準備しているものです。
当該観点のみで1施策のテストを実行しているわけではない点を予めご了承ください。
※注意②※
「レギュレーションテスト」は、担当タイトル内で使用している独自用語であり、一般的に使用されている用語ではありません。
どんな感じか実際に使ってみる
文字だけだと伝わりづらいので、
実際にどのようなケースで使用するか例題を用いて説明させていただきます。
以下のような仕様の施策があるとします。
※仕様書とマスタが一致している前提となります
※中身は完全にフィクションです
■イベント形式（タイプB）
| ボス情報 | |
|---|---|
| ボス名 | 実家の日本人形 |
| 属性 | 闇 |
| Normal | Hard | Very Hard | Challenge | |
|---|---|---|---|---|
| ステージ1 | 5 | 10 | 15 | 0 |
| ステージ2 | 5 | 10 | 15 | － |
| ステージ3 | 5 | 10 | 15 | － |
■イベント連動ガチャ
| ピックアップ① | ピックアップ② | ピックアップ③ | |
|---|---|---|---|
| 武器名 | 父のゴルフグローブ | 使いかけ消臭スプレー | 祖母の愛用手鏡 |
| 武器種 | グローブ | 銃 | 法具 |
| スキル | 慈愛のゲンコツ | ほんのり石鹸の香り | 全盛期の輝き |
| 属性 | 光 | 水 | 光 |
| 物理攻撃力 | 1375 | 820 | 250 |
| 魔法攻撃力 | 190 | 820 | 1,280 |
上で記載したように、仕様書とマスタは一致しているため、実機を確認しても同様の挙動となっています。
しかし、本施策には「3点」の不具合が存在します。
ここでレギュレーションテストを実施してみます。
お気づきになられましたでしょうか…？
結果は以下の通りとなります。
パッと見ではなかなか気づきませんが、レギュレーションからはずれているものがこれだけ存在しました。
今回のレギュレーションシートと照らし合わせて見るポイントを赤文字で強調してみます。
■イベント形式（タイプB）
| ボス情報 | |
|---|---|
| ボス名 | 実家の日本人形 |
| 属性 | 闇 |
| Normal | Hard | Very Hard | Challenge | |
|---|---|---|---|---|
| ステージ1 | 5 | 10 | 15 | 0 |
| ステージ2 | 5 | 10 | 15 | － |
| ステージ3 | 5 | 10 | 15 | － |
■イベント連動ガチャ
| ピックアップ① | ピックアップ② | ピックアップ③ | |
|---|---|---|---|
| 武器名 | 父のゴルフグローブ | 使いかけ消臭スプレー | 祖母の愛用手鏡 |
| 武器種 | グローブ | 銃 | 法具 |
| スキル | 慈愛のゲンコツ | ほんのり石鹸の香り | 全盛期の輝き |
| 属性 | 光 | 水 | 光 |
| 物理攻撃力 | 1375 | 820 | 250 |
| 魔法攻撃力 | 190 | 820 | 1,280 |
| これだけのボリュームの仕様書でも、レギュレーションテストで拾える箇所が多数存在します。 |
このような形で、過去の不具合事例や開発チームから共有を受けているレギュレーションを元に観点の追加を行い、すべての施策で原本を複製して確認を通しております。
実際に導入してみて
個人的にはなりますが、レギュレーションテスト導入後の所感です。
良かった点
■テストケース作成の工数が削減できる
一定のサイクルで実施するようないわゆる「定常施策」といわれるものは、テストケースの変動箇所をレギュレーションテストに切り出すことで、更新箇所が少なくなり、テストケースの作成工数の削減に繋がる
■テスターのナレッジの蓄積に繋がる
共有しているレギュレーションを元に正解が何かをテスター自身が考えて導き出すようになっているため、
予め期待結果が書かれているテストケースを消化しているときよりも「作業」になりづらい
ちょっと残念な点
■観点追加のタイミングが障害発生後
元々観点として抜けていたものや、レギュレーションが共有されていないことで検知が漏れることが多く、観点追加のタイミングが障害発生後になってしまう(どちらかというと再発防止対策)
ただ、こちらについては、開発チームからの施策共有会にて新規で作成するレギュレーションが存在するか否かを事前に確認するというフローを設けるだけでもだいぶ変わってくると思います。
さいごに
いかがでしたでしょうか？
簡素な説明になってしまいましたが、フリーテストの品質が上がらなくてお悩みの場合や、
色んなテスト手法を試してみたい場合などの一案として参考にしていただければ幸いです。