はじめに
この記事はグリー品質管理 Advent Calendar 2021の16日目になります。
昨年までは自動化などについて実装例を踏まえて技術的な記事を書いていましたが、今年は自身の担当領域の変化などがあったため、ゲーム開発プロジェクトの中でのアジャイルテスト担当者の心構え、アプローチなどを備忘録的に綴ります。
アジャイル開発自体の手法やチーム全体としてのアプローチの話ではなく、あくまでテスト担当者がどう向き合うかにフォーカスしています。
アジャイル開発と一口に言っても、採用しているアプローチや体制はチームにより様々かと思いますので、一つの参考として頂ければ幸いです。
どんなチームか
モバイルゲームアプリの開発プロジェクトです。エンジンはUnityを使っています。
自分はα開発が終わりβ開発が始まるころに、数名のテスト担当者のリーダーとしてジョインしました。
アジャイル方法論としてどの様なアプローチを行っているかなどは記載しませんが、アジャイル開発宣言にある以下の価値観を共有しているチーム、としておきます。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
このアジャイル宣言ですが、従来型の開発サイクルのQAの考え方だと
ドキュメントよりも動くソフトウェアを
計画に従うことよりも変化への対応を
この文が特に気になるのではないでしょうか。
自分も実際にジョインした時には仕様書がほとんど無く、スケジュールも厳密には管理されていない状況に面食らいました。
また、チームは基本リモートでの開発体制になっていて、週に1，2回オフィスに集まる様な状況でした。
アプローチ
リモートでのコミュニケーション
コミュニケーションは基本的にSlack, Zoomを使って行っています。
Slackでのやり取りで済むことも多いですが、ちょっとでも込み入った話であれば会話した方が圧倒的にスムーズに進みます。Zoomは画面共有もできるので話しながら不具合の再現などを見せるのにも便利でした。
また、通話に気軽に参加できるようにするのもポイントです。
- 常に開いているZoomミーティングを準備する
- Slackのハドルミーティングを使う など
BTSの活用
ツールよりも対話を重視するとありますが、BTSは活用すべきです。
それまではあまり使用されておらず、チャットやスプレッドシートなどでも不具合が報告されていましたが、BTSで一元管理するように働きかけました。
あたりまえですがBTSの方が不具合の検索やトラッキングがしやすいです。
また、元々チャットで報告する文化だったため、SlackからBTSに起票できる仕組みを導入し、チームメンバーが不具合チケットを作成しやすくしました。
テスト、品質意識の啓蒙
プランナーやエンジニアが自身の実装をテストする文化は根付いていましたが、アプリ全体の品質に関してはなんとなくしか把握できない状況でした。
テスト担当者としては、各自の実装に責任を持ってもらうことは維持しつつ、機能ごとのテスト状況、不具合状況などと共にアプリの品質状況をチームに随時フィードバックし、品質とリスクを正確に把握できるようにすることが大事です。
開発環境の導入
弊社の前例ではQAが開発環境を用意することはなかったのですが、ドキュメントがない場合成果物であるソースコード、スクリプト、アセットなどを直接確認する必要があるのと、速いイテレーションに対応するためにQAも開発環境を導入しました。
基本的にはテストは実機上でビルドされたアプリに対して行いますが、リーダーやテスト設計者はUnityで最新の実装状況の確認ができればビルドを待つ必要がなく、テスト工程が効率化できます。
テストツール、テストデータの作成
また、テストツール、デバッグ機能、テストデータを作成する際にも開発環境は必須です。これらは要件を伝えて作成を依頼するよりも使用者であるテスト担当者が作成することで、要望通りのものが作れ、ウェイトタイムも無くなります。
探索的テスト
ゲームのストーリーパートは選択肢によるフラグ分岐などもあるためスクリプトで作成されているのですが、仕様書は一切ありませんでした。
そこでスクリプトからフラグと分岐を抜き出すスクリプトを用意し、それらの一覧と必要なテスト観点をまとめたテストチャータを用意して探索的テストを行いました。
テストベースとトレーサビリティ
イテレーションの中で実装を確認して仕様の修正が入ることも多かったため、各機能毎のテストスイートには必ずテストベースを記録して紐付けて管理するようにしました。
仕様書がある場合は仕様書を、仕様質問したチャットのログやmtgの議事録、スクリプトなどをテストベースとしています。
どの情報を元にテストケースが作成されたのかを明確にすることで、仕様変更への対応ができているか把握しやすくなります。
まとめ
アジャイルQAではテスト担当者は従来よりも開発チームの一員としての立ち回りが求められると思います。また、テストツールの作成やテスト自動化の導入など技術的なスキルも大いに求められるでしょう。
現状でQA体制の構築とイテレーションを回すことはできているので、今後は実機での自動テストの導入などでより効率化を図っていきたいと思います。