はじめに
QAスケジュールやQAの進め方については各タイトルごとに違っていると思います。
私が担当しているタイトルでは、だいたい半月分の施策を1度のQAですべて検証する形を取っています。
その中でも特にガチャの更新が非常に多く、過去には1度のQAでガチャを30個以上検証するということもありました。
そのような状態なので、作成が必要な項目書(私の現場ではテストケースを項目書と呼びます)の量も結構な量になっています。
幸いにも各施策で大きな仕様変更が入ることがほぼ無いので、基本的には同じ内容の項目で必要な箇所だけ修正する形で済みます。
が、とはいえ作成する項目数は多いので結構工数はかかります。
いかに(楽で)ミスが少なく、早く、効率的に項目書を作成するかを私なりに突き詰めていった結果、項目書をテンプレート化するという結論にたどり着きました。
ということで、こういう作成方法もあるんだという一例として紹介させていただければと思います。
サンプル
まずはスケジュールなどの情報を1か所にまとめて記載するシートを用意します。
そして次に項目。
よくあるガチャの開催期間の境界チェックの項目です。
少なくとも赤線部分の4つは、ガチャの開催期間が変わるたびに変更が必要ですが、上の画像の赤枠部分を参照するようにして作成すれば、2か所修正するだけで済みます。
VLOOKUP関数で黄色線部分に記載している対象のガチャ名をもとに日付のデータを切り替えているので、「イベントガチャ2」の項目を作成したい場合は、項目をコピぺして黄色線部分のガチャ名を変更するだけで完了です。
このような感じで、ガチャの価格やガチャ排出カード、確定内容などの更新が必要なデータをまとめたシートを用意し、項目側では該当のデータを参照するように作成すれば修正箇所を減らすことができます。
さらにIF文などで条件によって期待結果を出し分けを行うこともできるので、最終的に項目側に一切手を加えずに項目を作成することもできるようになります。
メリットとデメリット
メリット
- 項目作成の手間が減らせる。
- 作成手順を守れば、作成者が変わっても一定のクオリティが担保できる。
デメリット
- テンプレート化するまでに少々時間がかかる。
- 毎回大きく仕様が変更されるような施策では使えない。
- 複雑に作りすぎると、テンプレート自体の更新が属人化してしまう。
さいごに
この作成方法が使える状況はそう多くないかもしれないですが、使える状況であれば結構有用な方法ではないかなと個人的には思っています。
項目書は作成者によって記載方法が変わることも多いですが、こういった形であれば、誰が作ってもブレることがないので検証する側も、毎回同じ文言、同じ粒度で検証を行うことが可能です。
最終的には項目書作成の自動化くらいまでもっていけるといいなと思います。が、まぁ難しいですね。
最後までご覧いただき、ありがとうございました。
おまけ
項目の作成方法は自由だ！！！