LoginSignup
11
1

More than 1 year has passed since last update.

開発から信頼を得るためのQAの取り組み

Last updated at Posted at 2021-12-23

はじめに

メリークリスマス:xmas-tree::xmas-wreath1::xmas-wreath2:

今回の記事は「開発から信頼を得るためのQAの取り組み」というテーマを書きたいと思います!
(あくまで一例ですのでこういうやり方もあるよ的な感じで読んでいただけたら幸いです)
12/24担当ということで大事な日に自分が記事を書いていいのか若干戸惑っておりますがよろしくお願いいたします!!

その前に軽く自己紹介をさせてください!

私は主にモバイルゲームの品質管理を担当しています。
市場不具合の再発防止のための傾向分析やテスト業務の効率化に日々頭を悩ませながらなんとかやっています!w
QA歴は5年目でとても経験豊富とは言えないですが、ゲームの仕様把握や開発とのコミュニケーションで個人的に大切だと考えていることを纏めていますのでこういったアプローチの仕方もあるよっていうのが少しでも皆さんに伝われば幸いです!

概要

まず、今回紹介する事例について、自分はリリース時からかかわっていたメンバーではないです。
前任の担当者から引き継ぎという形で現在は自分が担当しています。
一応、この案件の状況については軽く自分の耳にも入っていて、聞く感じでは運用の安定期に入っていた印象でした。

課題

引継ぎ作業もほとんど終わりこれからやっていくぞ!っていうときに一つ課題がありました。
それは開発とQA双方が仕様書に書いていないものについて全く考慮できていない点です。
どういうことかというと、テストするときに仕様書を参照してテストケースを作成しますが、仕様として記載されていない箇所や変更点の影響範囲が考慮されていないことが判明しました。
結果として、仕様書に書かれていることしかテストできず、開発内部で確認するのと変わらない結果になるのでは?といった厳しい意見をいただくこともありました。

それに加え、仕様書以外のことをテストしていない状況だとかなり初歩的なミスも起きがちです。
実例でいうと、達成が難しいミッションAと簡単なミッションBがあるとします。
それぞれの達成報酬として、Aは入手しやすいアイテムが、Bは入手困難なアイテムがそれぞれ設定されていたことがありました。
ミッション難易度に対しての報酬設計が間違っていることに気づけなかったというものです。
(テスター側にナレッジがないとそのアイテムの価値がわからない事象が発生します)

こういった少しでもナレッジがあれば防げるような不具合を検知することができず、
それと比例して品質面も低下していったので、開発からの信頼も少しずつ失ってしまいました。

取り組み

かなり絶望的な状況からスタートしましたが、当然投げ出すわけにもいかないので、改善するために以下の取り組みを行いました。

①ゲームをプレイ

ゲーム本来の遊び方や仕様を知らない人が、そのゲームをよくすることはできないと思っているので、まずゲームをプレイすることから始めました。

日頃からプレイすることはもちろん、QAチームでナレッジシートを作成して共有するなど、とにかくゲームに触れる機会を多くしました。
そのゲームがどういうサイクルでイベントを開催しているのか、エンドコンテンツは何かを理解することで仕様把握を早く進めるよう心掛けていました。
ゲームのナレッジが溜まっていくことで、普段のテスト設計やテスト実施にあたり、
各機能の影響範囲を纏めやすく、時には開発側ですら気づかないバグを検知するなど品質面で大きく貢献することができました。
ここで信頼をググっと手繰り寄せることができたのではないかなと思ってます。

余談ですが、私自身、ゲーム内のイベントをかなりやりこみました。
そのイベントではPtを獲得できるのですが、開発チームの中で一番多くptを獲得して
開発の方からはすごい!!猛者がいる!などお褒めの言葉もいただけましたし、
ゲームに対しての本気度をアピールできたのと、開発の方との距離感も縮めることもできました。
ここまでやる必要はないですが、やって損することはないので今ではやってよかったと思っています。

②探索的テストの導入

開発の信頼が落ちた大きな理由として仕様書以外の不具合を検知できなかったところなので、
仕様書・設計書から読み取ることのできない不具合を検知するため、探索的テストの導入を行いました。
簡易的なテストチャーターを作成することで、経験やスキルが少ないテスターでも進めやすくなるようにしながら、同時に細かすぎても探索範囲が狭くなってしまうのでバランスを意識しながら進めました。
多くはないですが、不具合もいくつか見つけることができたので良かったと思います。

③開発とのコミュニケーション

品質改善といってもQAだけで行うには限界があります。
QAで解決が難しいものに関しては、プロダクトにも協力をお願いしながら進めていきました。
仕様書に記載してほしい情報やデバッグツールなど、テストで必要なものに対して、それがなぜ必要なのか、どういうメリットがあるのかを明確にし、互いに利点が生まれるように説明する必要はあるのでその辺は腕の見せ所でもあります。

ただ、プロダクトに協力を仰ぐことは一定の信頼があってこそのものだと思ってます。
知らない人からお願いされてもなぜやらなければならないのかとなるだけなので、
協力を仰ぐ際の順序は気を付けたほうがいいと思います。

まとめ

取り組みとしては目新しいものはなく、当たり前のように感じるかと思いますが、
その当たり前の作業を地道に続けてきたことで少しずつ信頼を回復させることができました。
信頼を獲得することでQAとしても動きやすくなるので、現状に満足せずこれからも続けていきたいと思います。

以上となります。ありがとうございました。
それでは良い年末を!

11
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
11
1