【JaSST'19】Tokyo2日目 セッションB5：ゲームのテスト
どもどもー！とのの@tonono2587です。
引き続きJaSST'19 Tokyoのレポしていきます。
参加セッション
2019/03/28（2日目）
三銃士モデルを適応してみた！ -Next Generation 次世代の挑戦-
JaSSTソフトウェアテストシンポジウム-JaSST'19 Tokyo-セッション概要
参加前の期待（気持ち）
- ゲームのテストってなにしてるかわからん
- 他の会社の方はどんなテストをしているのか知りたい
- 自社テストのヒントにしたい
セッションのメモ
□三銃士モデルについて
”ゲームテストをする人がらくできるようにしたい” のがきっかけ
- 世界観
- コンテキスト
実装 中心に「ユーザー感情」をおく
テスト観点を構造化する
構造化するとやりやすい- テスト設計方法の提案
組み合わせながら「設計していく」 - テスト合否判定をユーザー観点を使って行う
テスト関心事
テスト観点
テスト値
テストフレーム
テストケース
→テスト手順
ゲームカテゴリごとに、お客さんが気にすることが違う
- 観点・リスクから優先度づけして、アジャスト可能にしたい
- まずは小さく！
Q&A
［Q］「ユーザー感情」の集め方は？
［A］
一般的に他と比べるとどうか？とか（最終的に数値化したいけど、）を組織ごとにまとめながらすすめていくのがよさそう
ペルソナを分けて考え、対象ごとのターゲットに合わせてわけたりなど
［Q］「保守の人」などのユーザー感情を考えるときは、中心を（保守のある意味"ユーザー"へ）置き換えたら出せるのでしょうか？
［A］
ここで指す「ユーザー」はエンドユーザーに近いので、保守性/メンテナンス性など技術的なところは”実装”のカテゴリに寄せるといいのでは？
ゲーム業界の○○テスト？！
品質管理グループ
→テストチームの管理などをしているところ
■ゲームテストの世界って？
取り組み（今回のセッション内容）のはじまりは「ゲームテスト設計の 国際標準化 したい！」ところから
ISO/IEO/IEEE TR 29119-10 Games Testing
これにつける付録とは？
テストタイプ/テストレベル/テストフェーズ の体系化
テストコンテナの作成？？テスト観点の体系化？
テストフレームの作成？
□ゴール
テストコンテナやテストフレームをつくって、ゲームテストを体系的にまとめる！
では、ゲームテストの”テストタイプ”ってなんだろう？
■研究会でやったこと
〇〇テストの洗い出し
- プロモーションコードテスト：iOSアプリ限定、プロモーションコードを発行し、本番環境でテスト
- コリジョンテスト：壁をすり抜けたりしないか
- スキル検証
CBT（クローズドβテスト） などなど…
「○○テスト」ってたくさんある
他社でつかっている言葉で知らない言葉 があった
"おさわり会"
- リリース前の新バージョンのアプリを（他プロジェクトの社員含め）社員がさわって確認する会。UI/UX
- "乙女チェック"
- 女性向けアプリを乙女の気持ちでテストする。ユーザー心理的に重大なバグがないかを探すためには乙女心を準備する！！
いろんな「○○テスト」がありました。
標準化への課題
- ○○テストとは…の資料が社内に存在しない
- 同じ会社でも認識が違うかも
→自分の会社のテストについて、説明できるようにしよう！！
〇〇テストの分類
担当/担当部署・名称・目的…で分類していく
→テストにまつわる言葉が混在していて、整理が必要になった
（「○○テスト」はカテゴリAにもカテゴリBにも入れたい…）
○○テストの比較
「○○テスト」の名称、だれが、いつ、何を気にして、何を確認しているのか を確認することに
例）
- マスター差分チェック
マスターデータのダブルチェックのこと
- 素材を確認するテスト
画像/3Dモデルなどの確認のこと
→次は 〇〇テスト を体系的にまとめてみよう！！
テストコンテナ
直近の取り組み
認識合わせが終わったので、テストコンテナをつくろう！！
コンテナ - 企画 - 開発 - クリエイティブ：素材制作チーム
- ユーザー
- 版元
- プロセス
- LQA（ローカライズ）
などなど
- テスト
- 効率的な素材確認
- 素材そのものの確認
- 言語違い
- 音割れ
- 素材そのものの確認
他部署の内容がわからない… →連携していきたい
□テストフレームにいれたもの
- 機能名
- 条件、手順
- 結果、アウトプット
Q&A
［Q］
「乙女チェック」について、うまくいく方法は？
どうやって乙女心をつけるのか？
［A］
表示崩れがただのバグなのに、乙女にとっては重大なバグ！＝乙女心が足りない
→IPの勉強する時間をとって対策
［Q］
単語の違い、認識の齟齬は他社間だけではなく
外注の協力会社などとも合わないんじゃないか？？
［A］
結局、認識合わせした
三銃士モデルを現場適用してみた！
【背景】
エンジニアレビュー済みのテスト項目なども終わって、フリーデバッグだけ、
というフェーズになって重大なバグが見つかり、リリースが伸びた
ということが（結構）あった
「フリーデバッグ」とは？？
→仕様外の操作をしたりするテスト
課題解決
□解決のための動き
→でもこれだけではそこまで効果がなかった
□不具合を分析したところ…
- 期待結果の記述があいまいだったので、OKで通っちゃっていた（そのためベテランしか発見できなかった不具合）
- 機能の組み合わせが不十分だった（のでベテランしか）
- 上流工程で予想しない操作をした（メインパスじゃない、特定のパス）（だったのでベテラン…）
□どうするか？
- テスト手順書作成（実装）：期待値の記述を徹底して対策する？
- テスト観点組み合わせ（設計）：十分に組み合わせて対策する？
- テスト観点抽出：ベテランが出す？
→ベテランが対応する時間がない…
- 上記をできるように人を育てる！
→やっぱり時間がない…？？？
人材育成が先か、教育方法が先か？
（にわとりたまご論争）
→じゃあテスト観点をマインドマップで整理したら？？というアドバイスをもらった
□やってみた
「項目の粒度が作成者の力量に左右される」ことに対しては、
ベテラン作成者がマインドマップでまず観点を整理し、それを元に項目作成をおこなった
○よかった点
- マインドマップを再利用できるようになった
→機能ごとにメインブランチを切っていて、似た機能や改修などはそれをもとにちょっとなおせばすぐ使える
△注意点
- 「マインドマップ」そのものに慣れてないと効果が出ない
→結局なんなの？意味あるの？みたいに取られてしまう
（（（（（（さわれるまでテストさせてもらえない状況をやめたい）））））））
Q&A
［Q］
ユーザー感情の閾値などを握っていく（組織内で納得して定めていく）コツは？
［A］
似たような事例をみて、こんな感じ、とコミュニケーションとっていく
［Q］
考えることはできても、それを実現できるスキル、人材はどうしたら？
スーパープレイ、このステージ○秒以内でクリアとか
［A］
技術・技能の話
別の観点での人材育成が要るのでは
ベテランの、技能面でのレベル感をみて、そこを目指すとか
感想
- 認識合わせ大変そう
- 認識合わせのお話から、どんなテスト（○○テスト）があるのかほんの少し知れた気がします。
- 「乙女チェック」という強い言葉笑
- ↑印象的でした。視点によって対応の優先度、重要度も変わるんだという話だと認識しました。たしかにそうだなぁ…
- マインドマップすごくよさそう
- （話すごく逸れるけど）やったことの記録とっておこうと思った
JaSSTレポはもうちょっとだけ続く見込みです。
