はじめに

こんな記事です

異業種からゲームQA業界に未経験で転職してきた、つまり異世界転生してきた自分が、どういう過程で「テスト設計者」になったのか。
また、テスト設計業務に携わっていく上でぶつかった壁について振り返っていきたいと思います。
（この12月で設計者となり1年となります）

本記事はこちらのアドベントカレンダーに参加しております。
弊社社員が「スマホ/コンシューマゲームのテスト/QAに関連する情報」を日替わりで発信しておりますので、是非ご覧ください。
▶ AIQVE ONE ゲームQA Advent Calendar 2021

本記事で示したいもの

・「テスター」から「テスト設計者」を目指す際に意識して行うと良いかもしれないこと
・未経験者が設計者に任ぜられた際、どういう所に戸惑うか（教育担当者様向け）

自己紹介

【異世界転生前】
・前職ではメーカー勤務。表彰メダルのデザイン、仕入れ、生産管理業務を担当
・職人さんたちにバウムクーヘンを持ってお願いに上がったことは数知れず
・推しがイベントで優勝メダルをさげていたが、それが競合他社のメダルで超複雑な気分に
・みなさんが持っているメダルや、あの大会のメダルは実は自分が...？

【転生までのあらあすじ】
ある日、新しい仕入先を見学していると、突如現れた金色の光が辺りを包んだ。
呆気にとられる自分に、光の中から少女が訴えかけてきた。
｢どうか、この開発を助けて。伝説のテスト設計者たちよ……｣
やがて光が収まると、眼前には見知らぬ部屋、知らない天井が広がっていた。
そして「仕様書」や「テストケース」を目の当たりにし、ゲームQA業界に転生したことに気づく。

「テスト設計者」になるために意識していたこと

異世界転生をして、まず大事なこと。
それは、『この世界を知ろうとすること』だと思います。

つまりソフトウェアテストという考えをベースとした際、
一連の「テストプロセス」がどのように行われているのか。
「テスト設計」がどのように行われているのか。

私は「テスト設計者」となる以前、半年ほど「テスター」としてテスト実行業務を行いながら学ぶ機会を頂きました。
その中で「設計者」になることも意識しながら、思考のアンテナを広げていました。

テスト実行業務を通して

（テスターの一人として、任せられたテストケースの実行を行っていました）
　■「設計者」になるために意識して目を向けていたこと
　・設計者が各テスト対象に、どのような「テスト観点」や「パターン」を盛り込んでいるのか
　・設計者がそのテストを設けた「設計根拠」や「意図」は何か
　・不具合ナレッジの蓄積と、「この場合はどうか？」という別パターンは考えられないか
　・市場流失している不具合について、どういうテストをすれば防げたか

JSTQB FL資格取得に向けた勉強を通して

・開発ライフサイクルの中で、ソフトウェアテストが如何にして行われているのか
・ソフトウェアテストプロセスが如何にして回っているのか
・ソフトウェアテストプロセスを円滑に進めるためには如何なるマインドを持つべきなのか
（普段業務と学習のサイクルを回し、入社後1年未満で無事に資格取得できました）

⇒ 設計研修を経て、テスト設計者デビュー

「テスト設計者」になってぶつかった壁

簡易的にですが、図に整理してみました。
これ以外のところでも壁にぶつかりまくっていますが、代表的なものをピックアップ。

それぞれがどんな壁で、どう躓き、何を身につける必要があると感じたかを考えていきます。

「上手くいかない」とぶつかった壁

■設計作業において

1.「テスト対象の整理、把握はどうやればいい？」

＜ぶつかった壁＞
すべてを自分の頭の中や、メモに文字ベースで整理を行なっており「テスト観点/パターン漏れ」に繋がっていた

＜こうするようにした＞
・マインドマップを用いてフローを整理
・テスト技法ツール（GIHOZ）を用いて、視覚的に整理を行う

2.「設計し初めの方と終盤で、粒度ぶれぶれじゃない？」
3.「手戻りの調整で工数がかかりすぎるのですが...」

＜ぶつかった壁＞
・設計初めと終わりの方で「機能の名称」や「書き方」、「どこまで見るか」等がブレる
・後から全体を統一させる修正をかける必要が出てきて、工数を増加させる

＜こうするようにした＞
・設計方針をまず定め（何を、どこまで見るか）、明確に「どういうケースを作るか」という軸を持つ
・定められた設計方針がある場合は、しっかり読み込み、都度参照する
・休日明けから再開する際は、方針の再把握時間を少し設ける

レビューにおいて（レビューをもらう際）

1.如何なるマインドで臨むべき？
2.レビューしやすい説明は？

＜課題＞
・受け身になりすぎてしまう
・全部を伝えようとするので説明が長くなってしまう

＜こうしたらいい＞
・『より良くするためにはどうしたらいいか』をレビュアーと建設的に議論している意識を持つ
・1度で全部を伝えようとしない（相手もある程度わかっている、相手と積み上げていく意識）
・沈黙の時間は作らず、「自分が迷った部分」や「こういうの思ったんですが、」を提示する
・レビューしやすい分量に、ある程度のところで区切りをつけていく
　（初めてのレビューイの際、1時間ぶっ通しで説明してしまいました）

「これはどうやればいいんだ？」とぶつかった壁

初め戸惑ったけれど、周りの方に教示頂き乗り越えたもの

見積もり

・何を根拠として予想ケース数を出していけばいいのか
・予実との乖離が大きくなった際に、どう分析していけばいいのか

状況に応じたテスト

全数テストは不可能な中で、それぞれどのようなテストを行うべきなのか
・新規案件で検討すべきテスト（機能担保）
・施策運営案件で検討すべきテスト（データとその影響範囲にある機能）
・アプリ申請段階で検討すべきテスト（ガイドライン遵守）

今後乗り越えるべき壁

ゲームの内部構造的な知識を身につける（仕組みへの理解度向上）

ゲームの内部構造的な視点からテスト観点や、パターンを考える力がまだ不足している
　↓↓
＜学習を行うことで＞
（１）「どのようにして命令/判定処理が走っていて、どのようにしてデータを読んでいるか」という部分にまで知見が広がれば、テストに盛り込める観点やパターンも広がるのではないか。

（２）発見したバグやエラーの規則性への推測力（課題を発見する力、捉える力）が身に着けば、より効率的なテストケースを作成を行えるのではないか。仕様書の記載内容が抽象的な場合でもテスト観点不足を防ぐのに役立つのではないか。

具体的にどう学習を行っていこうかと思案している時期ですが、弊社アドベントカレンダーに参加している別メンバーの記事がとても参考になりそうです。
▶ ゲームプログラミングを理解し効果的なテストを行う

説明は台本だてて、「結論」からお話する（根拠をしっかり持たせる）

何を伝える必要があるのかを考えた上で。

この世界で生きていく... (To be continued)

ぶつかった壁の共通項

ぶつかった壁をまとめると、自分に欠けているのは**『根拠の設定』**のように感じます。

・見積もりの根拠を先方に示す
・設計したケースの根拠をレビュアーや先方、テスト実行側に示す
（「なぜこれをやるのか」「なぜこれをやらないのか」）

『根拠をもたせること』
それは何事においても、しっかり『狙い』と『方針』の軸を定めないと成り立ちません。

「根拠となるような知識を増やすこと」
「知識をしっかり根拠に昇華させること」
「慌てず、定め（られ）た時間の中で理解作業をしっかり行ってから根拠を醸成すること」

これらを自分の心に留めて、これからもこの世界で生きていきたいと思います。

今後学んでいきたいこと

自己学習
転職異世界転生以前から、エンジニア職にある友人たちを見ていると、「自ら学習していく力」、セルフプロデュース力が強いなと感じていました。
自分もそう在りたいなと、過ごしてきたここまでではありますが、「まだまだだね」とコートの向こう側で言われている気がしています。

勉強会
2~3ヶ月ほど前から業後や、土日の空いている時間にconnpassで開催されている「勉強会」に参加するようにしています。

ゲーム開発の仕組み、QAテストマインド、設計技法や自動化。
専門的な知識を学ぶ場としてはもちろんですが、この転生先の世界で、「プロ」として自分がどう生きていくのか、それを考える良い機会になっているように感じています。

先述しましたが、2022年は『ゲームの内部構造的な知識』をもっと身に着ける1年にしたいです。
効率性の良いテストケース作りを考えると、関数もゴリゴリと学習せねば。

「いつか、こういうお仕事がしたいな」という夢があるので、そこに向けてしっかり自分の価値を高めていきたいと思います。

それでは。
来年も、がんばるぞい。

リンク

・AIQVE ONE株式会社公式サイト
・次世代ゲームテスト研究所（品質管理のAIQVE ONEによる情報発信ブログ）
・AIQVE ONE ゲームQA Advent Calendar 2021