ゲーム開発の最後の砦!? QAチームについて
はじめに
初めまして。QAのリードをやっているものです。
QAとはゲーム開発においてクオリティを担保するための重要な砦として存在する部署です。
今回アールフォースで行っているQAの流れを説明します。
アールフォースのQAについて
まず初めにQAとは何かについてになります。
「QA」とは「Quality Assurance=品質保証」の略称になります。
会社によってはQC(Quality Control=品質管理)と言ったりします。
一言で簡単に言うと「デバッグ」になります。
デバッグと言われてイメージするのは長時間壁に向かって走り続けるようなすり抜けのチェックを思い浮かべる方もいるかもしれません。
そのようなデバッグをやることもありますが、アールフォースではそのデバッグ作業をメインでは行っていません。
作業の概要を端的に説明しますと
・クオリティを担保する為に必要な調査/提案
・クオリティを上げるためにテスト計画を立て実行
などを行っています。
もっと具体的に作業を説明しますと以下のような順番で作業を行っています。
- 仕様書レビュー
- テストプランの作成
- テストケースの作成
- チェックシートの作成
- テストパスの作成
- テストスケジュールの作成
- BVT(Build verification test)の作成/実行
- バグプロジェクション
- バグトリアージ
- ポストモーテム
上記をざっくりとした説明ものが以下になります。
仕様書レビュー
開発の初期から仕様書を確認し、仕様漏れやユーザビリティ、ユーザーエクスペリエンスについての指摘/提案を行っていきます。
テストプランの作成
開発中期に作成する資料で、テストの計画書になります。
テスト範囲や環境、テストスケジュール、人員計画等をまとめ、どのようなテストが行われるか事前に確認してもらうものになります。
テストケースの作成
開発中期に作成する資料で、チェックシートの設計書のようなものになります。
どの機能に対しチェックシートを作成するかをまとめます。
チェックシートの作成
テストケースに記載されてる機能に対して仕様通りの挙動になっているかチェックするための資料になります。
確認するための操作とその結果どうなるのが仕様通りか、データの数値がどうなっているのが正しいのかなどがまとめられています。
また組み合わせチェックでは無数にあるパターンを記載しテストプランで決めた範囲をチェックしていきます。
テストパスの作成
すべてのチェックシートの確認に必要な時間と作業者の人数をまとめた資料になります。
すべてのチェックシートの確認が終わる事で1回のテストパスが終了となり、テストパスを13回行えば、致命的なバグはすべて発見できると考えています。
テストスケジュールの作成
テストパスを基に、13回すべてのチェックシートの確認を行うことができるスケジュールを作成します。
スケジュールは予定通り、想定外、理想など3通りほど作成し、プロジェクトに提案します。
BVT(Build verification test)の作成/実行
テスト用のアプリ作成時に必ず行う簡易的なチェックシートになります。
アプリの安定性向上やデバッグを行うための準備を目的として行います。
バグプロジェクション
過去プロジェクトのデータを使用し、バグ報告のピークがいつになるか、報告件数はどれくらいになるか、修正可能件数は何件か、どのようなバグが多いかを予測します。
予測を基に、安定したリリースを行うためピークが来る時期を調整します。
バグトリアージ
残っているバグが多い場合に、対応すべきバグとそうでないバグを仕分けます。
対応すべきものを明確化することで、やるべき作業に注力し、スケジュールの延期またはクオリティが低いゲームをリリースしてしまうことを防ぎます。
ポストモーテム
開発終了後に行う反省会のようなものになります。
次回の開発の際に同じ轍を踏まないように、問題点に対し改善策を出していくものになります。
各セクションでまとめたものをリーダーたちで共有することで開発の度に成長していく組織を作っていきます。
まとめ
結構発言を軽視されがちなQAですが、最初にも言ったように実は最も大事な部署だと思っています。
QAやデバッガーがいないプロジェクトは開発を行いながら自分でデバッグを行い、バグを直しきれず、ユーザーに発見してもらうという状態になってしまいます。
そのような状態でリリースしたゲームはユーザーの皆さんに長く遊んでもらえない事が多く、そうならないための砦としてQAは存在していると思っています。