はじめに
今回はQA業務の一つ、テスト進捗を記録集計する中から見えるもので
どんなことを考えるのか希望も混ぜつつかなり主観的な感想よりの内容となりますが
記載していきたいと思います。
補足事項
運営型ゲームのテスト業務での内容で、開発期間は毎度一定の期間となっており
スケジュール重視の進め方のものとなります。
また主にテスト実行期間に範囲を絞っているため、テストプロセスの中でも
実装と実行にフォーカスしており、記載しているグラフなどは一部加工しております。
用語的なものとして下記のように表現しています
・ver：いち開発期間の意
・企画さん：主に企画/プランナー職の人たち、全体のスケジュール管理も担当
・開発さん：主にプログラマー職の人たち。開発さんの中でも担当範囲を区別して、
クライアントさん/サーバーさんと呼ぶ場合も
・QA：ここでは主にテスト業務の人たちの意で使用
・バグピンポン：報告内容が不明瞭であったり、不具合が修正不完全だったりで
やり取りが何度も行き来すること
・イレギュラーパターン：≒エッジケース。遭遇する可能性が低いバグの意で使用
主に集計しているもの
- テスト消化率
- 全体
- 機能別
- 不具合関連
- 起票した数
- 解決した数
- 起票から修正対応されるまでの期間
- 修正対応されてから修正確認が完了するまでの期間
等
集計例
【進捗概要】
QA開始の少し前から集計。
「テスト実装(緑線)」や「テスト実行(青線)」の進み具合や
「不具合報告数(赤棒)」、「修正完了数(灰色棒)」をまとめたもので
関係各所へ所感とともに概要をザックリ把握してもらうために利用します
【全体進捗_平均比較(左)とver別比較(右)】
テスト実行の進捗を過去の平均や各ver別で比較した際に、
今回のverがどういう温度感かを見るためのもの。上ブレすると嬉しい。
【不具合数_平均比較(左)とver別比較(右)】
不具合報告数を過去の平均や各ver別で比較した際に、
今回のverがどういう温度感かを見るためのもの。
下ブレするとホッとするけれど、下振れが過ぎるとちゃんと不具合検出できてるかなと
心配にもなってくるちょっと秋の空模様的なグラフ。
【機能別集計の一部】
機能別にテスト消化率や不具合状況を集計したもの
★マークはQAが必要工数から予測する難易度。難易度が高いものほどベテランを割り当てる。
★が少ないものが難航すると心拍数が上がってきたり……
【機能別バグ割合】
全体で見た場合の不具合の偏り確認
偏りがある部分へは注力比重UP！偏りが見えないと注力具合が悩ましく……
【不具合対応振り返り】
テスト完了後に自部署内外で進捗に影響をおよぼすようなものがなかったか確認するためのものの一例
赤いセルはボトルネックになったと思われる箇所
内容としては、主に不具合報告から対応完了までの期間(主に企画/開発側)、
不具合の対応完了から修正確認完了までの期間(主にQA側)が長くなっていないか、
バグピンポンせずに修正対応が1度で完了したかどうかを再確認しつつ、
修正確認の際に重要な情報となるビルドNoや原因、対応内容、影響範囲や
申し送り事項の連絡や聞き取りが成されたか等をチェック
赤い箇所が少ないとQAからは感謝感謝！
テスト開始前後
開発が遅れているものがないか、QA開始となったものの機能不全発覚や
テストデータの不備等によりテストできる状態になっていないものがないかを確認。
後述するどの段階でもですが、問題があればリカバリー可能かどうか
難しそうであれば機能の保留や先送り、テスト期間の延長の提案、
時にはテスト範囲の削減等を企画さん開発さんと相談。
テスト開始から1-2営業日で不具合報告数が過去と比べ数が多いようであれば
各部署に連絡しつつQA内で人員や探索的テストの割当具合を調整検討。
個人的に1番のドキドキフェーズ。
ここでまずい状況が見えると、大体しんどいことになるのでQAからも
準備や各種連携に懸念がないか注意して挑みたい。
テスト中盤
テスト進捗率、不具合報告/対応状況が想定内に収まっているかどうかを日々確認。
大体は2-3日目あたりで各機能別で傾向が明確になってくるので、開発さんに不具合対応等で
注力してほしい機能を改めて相談。
ときには仕様再検討なども入ったりするのでテスト設計も再確認。
全貌が見えてくるフェーズ。
ここで慌ててもしょうがない(遅い)ことが大半なので"やれることやる"というお気持ちで邁進。
テスト後半
主に重篤度の高い不具合の収束やテストブロック解消度合いに注視。
個人的に2番めのドキドキフェーズ。
探索的テストでイレギュラーパターンを掘りまくる時期でもあるため
進行不能(操作不能)、停止(フリーズ)、クラッシュ(≒ハングアップ)等の
Aバグ以上が出てきたら視界が一瞬ブラックアウト。
上記でなくとも、不具合修正後の影響範囲確認によっては進捗手戻りが大きことがある。
テスターによっては「デッカイもの見つけた！(ヒャホーッ！)」ってタイプや
「こんなタイミングで検出申し訳ない……(ぁゎゎゎゎ……)」ってタイプなど様々ですが
特に後者タイプには、ユーザーに踏ませなくてよかった！って想いでガンガン報告していこうの精神。
開発さんも同じ想いでありがたがってくれることがほとんど。
その後
テスト完了後にQAからの報告に関して部署内外での対応状況の振り返り。
重要度で言えば一番高いと言っても過言じゃないかなと思うフェーズ。
集計例の不具合対応振り返りに記載したようにボトルネックについて話し合い改善を進めます。
1つ1つは細かいことだし、一度改善されてもまた悪化することもあるけれど全体的には数十も数百もあり
全体的に改善が進めば効果は絶大。
場合によっては、手が加えられる機能別やその担当者による傾向にも目を向けて
準備やサポートの仕方を検討することで効果が出てくるものもあります。
責任を追求するのではなく、何故ボトルネックが発生したのかを考えて
関係者全員で地道に何度も改善検討を繰り返すことでverUPを重ねることで複雑化する開発の中でも
一定のコストで抑えられる状況に持っていけるかなと。
最後に
今回記載したものは特定のテストプロセスの中で、一部の観点からの勘案どころを
ザックリとではありますが稚拙ながら記載させていただきました。
定常的な開発スケジュールの中では、今だけでなく過去の状況とも比較し続け
特異点があれば原因を把握し対応を行い、今後の開発状況の健康度も保つための
基準を作ることがどこかで軋みが発生しいずれ大きな問題となってしまうことを防ぐ
重要な手段の一つだと感じています。
それにはQAだけでなく、関係各所の協力無くしては出来ないことで
現状迅速かつ丁寧な対応をしてくれている各部署に改めて感謝しつつ
今後も開発の一助となり続けていきたいと思います。
少しでも参考になれば幸いですし、何かあればご意見やご指摘のご縁があると嬉しい限りです。
その際はどうぞお手柔らかに
世の中すべての開発に幸あれ！