#はじめに
今年もお疲れさまでした。
今回のアドベントカレンダーでは、モバイルゲームのソフトウェアテストだけでなく、カスタマーサポート、コンテンツに対する法的側面からの審査などの視点の記事も取り入れて様々な視点から品質向上に取り組んだことをまとめていく予定です。
ぜひこのあとの記事も楽しみにしてください！
その一日目として私からはこの一年でモバイルゲームの開発現場がどのように変化してきたのか、QA視点でいくつかピックアップして伝えたいと思います。
変化の多い業界で求められていることの一例かつ概要レベルの内容ではありますが、少しでもヒントになれば幸いです。
#変化と取り組みをピックアップ
これまでも取り組みとして進めてきたものもありますが、開発現場で以前より対応が求められるようになったり、品質の安定化に向けて優先度が上がってきたと感じている点を3つピックアップしてみました。
| 開発現場の変化 | QAとしての取り組み |
|---|---|
| 経営層からリリース時の品質を詳細に知りたいという声が増えた | 品質状況をより定量的に見せるためにテストレポートを改修 |
| 市場にテスト担当者が不足している中で効率良く、精度の高いテストが必要 | アドホックテストから探索的テストにする |
| ヒットの確度を上げるためにお客さま視点のフィードバックが求められる | 魅力的品質へのアプローチとしてユーザーテストをブラッシュアップ |
| #1.リリース時の品質をより定量的に見せる | |
| 「予定していたテストが全部完了し、検知された不具合も全て修正済です。」 | |
| これだけでリリースしても問題ない品質と判断することができるでしょうか？ | |
| リリースという重大な局面に対して、上記では情報が不足しているかもしれません。 |
もしかすると開発終盤にかけて一気にテストしたため、回帰テストが十分でない可能性もありますし、検知した不具合の周囲を追加テストすることで関連した不具合が検知されるかもしれません。
では、どのように判断を助ける材料を提供するかですが、データで品質状況を定量的に示すことがあげられます。
必要なデータの一例を以下にまとめてみました。
①テストケースの実行状況
②不具合のオープン・クローズ件数状況
③直近の不具合検知状況
①と②は組み合わせてグラフにするケースを目にすることが多いと思います。
③が最近注視している点で、品質の安定度合いを判断する一つの材料になります。
①と②を組み合わせたグラフの例は以下となります。
テストの実行進捗と不具合の検知/修正状況を確認し、不具合検知数の増大、解決スピードの遅れなどを検知したときに開発チームと対応を協議するときに使用します。例でいえば、11月頭時点で不具合のOPENとCLOSEに開きが出てきているので、CLOSEを促すようなコミュニケーションを取ることができます。
リリース判断時には全体的な推移と、後半にかけてOPEN件数の増加が緩やかになっているかなどを確認します。
参考記事：[基礎から学ぶソフトウェア・テスト(6)][基礎から]
[基礎から]: https://xtech.nikkei.com/it/article/COLUMN/20060626/241754/
③のグラフ例は以下で、最終的なビルド（リリース時相当）に対して新規不具合の検知状況を確認し、品質の安定度合いを判断します。Sが最も重大でCが軽微な不具合を、また、右側にいくにつれてリリースが近くなることを示しています。
この期間は不具合修正以外に動作影響のある変更を入れないことを前提として、不具合収束を確認するために全体機能に対して一定の網羅性を持ったテストを実施します。
テストレポートにはこうしたデータを盛り込みつつ、リリース基準を満たしているかを伝えるようにしました。
#2.アドホックなテストから探索的なテストへ
モバイルゲームの開発では仕様変更の頻度が多く、詳細なテストケースを準備することが困難です。そのため、機能テストに補完するかたちで経験ベースでのテストを実施することが多いです。
よくある手法としては、テストケース等を用いずにテスト担当者にランダムにテストしてもらうものがあります。
（呼び方はさまざまですが、フリーデバッグ、フリーチェック、アドホックテストなどで呼ばれることがあるようです。）
一定の経験を持ったテスト担当者もしくは、多数のテスト担当者をアサインできる場合は、このテストによってある程度網羅性を確保することができると思います。
一方で、開発ラインの増加によりテスト担当者が不足し、都合良くアサインできないことも増えてきました。
このような場合、従来のアドホックな方法では網羅性の低下や想定以上にテスト工数が増大することが懸念されます。
弊社では何年か前より、アドホックテストから探索的テストのアプローチにできないか検討と実践を重ねてきました。
この方法では、詳細なテストケースの代わりに対象とする機能と一定の観点を盛り込んだテストチャータを用意します。
しかしながら、まだ体系的に進められていない部分が多いので、[JSTQBアジャイルテストのシラバス][シラバス]を参考にしつつ改良していきたいと思います。
[シラバス]: http://jstqb.jp/syllabus.html#syllabus_foundation_extension
#3.魅力的品質へのアプローチも重要
昨今のゲーム市場は拡大を続け、面白いコンテンツが次々リリースされています。その中で少しでもヒットの確度を高めるためにユーザーテスト（モニタリング、ユーザーレビューと呼ばれることもあります）が重視されるようになってきました。
参考記事：[CEDEC2020紹介記事][紹介記事]
[紹介記事]: https://gamebiz.jp/news/275544
これまではQAから開発チームに提案して実施するケースが主でしたが、最近では開発チームから相談を受けることが増えてきたことを変化として感じています。これにより、開発チームと双方向で連携しながら進めやすくなりました。
開発チームとの連携において、実施する目的、テスト内容、フィードバックに対する対応期間などの計画を事前に合意して進めることがポイントで、それによりユーザーテストの効果を最大化することができます。
特にすり合わせる項目の例を以下にまとめてみました。
こうした項目は必要に応じて追加/削除しつつ、より効果的に進める方法がないかを模索しています。
| 項目例 | 説明 |
|---|---|
| 日程 | テスト準備、実施、報告の期日と、フィードバックの反映期間を確認します。 |
| 実施目的 | 初期離脱のリスク、チュートリアルのわかりやすさ、継続につながるか、などどこにフォーカスして実施するかを確認します。 |
| 対象範囲 | 目的を達成するために必要な実施範囲を確認します。 |
| 観点 | 使用感、継続意向、課金意向、没入感など、テストする観点を確認します。 |
| ペルソナ | 初心者、ベテラン、IP好きなどの属性を確認します。 |
| 人数 | 実施する人数を確認します。 |
#最後に
今回は3点ピックアップしてお伝えしましたが、これらはあくまで一例に過ぎません。
まだやりきれていないことも多々あるので、来年も色々テストアプローチを考えていきたいと思います。
参考にした資料再掲
・テスト結果のレポート
[基礎から学ぶソフトウェア・テスト(6)][基礎から]
・探索的テスト
[JSTQBアジャイルテストのシラバス][シラバス]
・ユーザーテスト
[CEDEC2020紹介記事][紹介記事]