はじめに
こちらの記事でも触れられていますが、
スマートフォンゲームをリリースするにあたり
QA担当者はリリースして問題ない品質であると保証することが必要です。
今回私は2つのプロダクトリリースに関わりましたが、
それぞれQAとしての状況や、残課題を可視化してリリース承認者に報告する機会がありました。
実際に報告の形式や相手などは会社により様々だと思いますが、
QAが守らなくてはならないこと、伝えなくてはならないこと
は共通だと思うので、その点について詳しく記載してみようと思います。
これからアプリのリリースを控えているQA担当者の参考になれば幸いです。
定量的な報告内容
紹介した記事で記載されていますが、以下の三つは報告が必要です。
| 報告内容 | 詳細 |
|---|---|
| テストケースの実行状況 | 予定していたテストケースが完了している。またはその目途が立っている |
| 不具合のオープン・クローズ件数状況 | 発生不具合がすべて解決している。またはその目途が立っている |
| 直近の不具合検知状況 | アプリの品質が安定しており、新規不具合が発生していない |
これらがすべてOKであれば、基本的にはアプリをリリースして問題ない品質であると言えます。
以降でそれぞれの内容の詳細に触れていきたいと思います。
1.テストケースの実行状況
既にケースが完了している状況での報告ができればその旨を伝えるだけで良いですが、
実際にはテストが完了していない状況で、完了目途が立っていることを示す場合が多いです。
その際にどのような内容を示すのが良いかの実例をお見せします。
※グラフ上の各種数値はダミーの値です
上のグラフでは既に着地済みですが、途中の場合は青の実績が途中の状況で提出する形になります。
大切なのは、完了見積もりのグラフを示し、それに対する実績を示すことです。
見積もり通りもしくはそれを上回るペースで進捗していれば特に問題ありませんが
遅れている場合は、着地目途を出し直し、それでもリリースには問題がないことを示す
または、遅れることが問題の場合、見込み通りに着地させるためのリカバリプランを提出する
必要があります。
遅延の原因次第ですが、例えば以下のようなリカバリプランを検討し、プロダクトと認識合わせの上説明します。
・テスト人員の増員
・深夜/週末のテスト稼働
・不具合修正を行うエンジニアの増員/稼働増を相談
・リリーススケジュールのリスケ提案
2.不具合のオープン・クローズ状況
こちらも、すべての不具合が完了していれば特にエビデンスは不要かもしれませんが、
実際は不具合が残った状態でその解決目途を示すケースが多いです。
具体的にどのように報告しているかの一例を示します。
※グラフ上の各種数値はダミーの値です
ここで示すべきは発生した不具合が解決する目途が立っていることになります。
またもう一点、残存している不具合のうちリスクが高いものはどのくらいあるかも必要です。
高リスクの不具合が残っている = 修正に時間がかかり影響範囲が大きな不具合が残っている
ということになるため低リスクな不具合が複数あるよりも注意が必要となります。
すべて解決する目途が立っていれば問題はないですが、
リリース時に不具合が残存する可能性がある場合、対策を示す必要があります。
・不具合修正を行うエンジニアの増員/稼働増を相談
・残不具合の内訳を示して修正しなくてもリスクが低いことを示す（プロダクトと合意が必要）
・リリーススケジュールのリスケ提案
3.直近の不具合検知状況
仮に今発生している不具合がすべて解決しても、アプリに不具合が残存している可能性はあります。
可能性をゼロにすることはできませんが、リスクを減らしそれを示すことはできます。
具体的には以下のようなグラフを提示しました。
※グラフ上の各種数値はダミーの値です
こちらはリリース承認の会議まで、日々どのくらいの不具合が検知されたかを示したグラフです。
このグラフを作成するためにはデイリーで全機能をチェックし、発生不具合を記録する必要があります。
デイリーの全機能チェックを探索的に行うことにより潜在しているバグを掘り出して品質を高めつつ、
日々の検知不具合数を可視化することにより定量的に品質を示すことができます。
このグラフの表示上ではまだ品質は安定しているとは言い難いですが、
不具合数が減少した状態が一定期間継続すれば、アプリにおける不具合リスクは低い状況になっていると言えます。
ただし、このグラフを示すためには原則ビルド更新がない状態であることが前提になります（不具合修正や影響のない更新を除く）。
更新が入っている状況だと新たな不具合が混入する可能性があり、品質の可視化ができる状況ではないからです。
測定期間を考慮すると、リリースの二、三週間程度前には大きな更新が入らない状況になっている必要があります。
まとめ
今回紹介したものは、あくまで最低限このあたりのデータはあったほうが良いよ、というものなので、
プロダクトの状況、会社や承認者に合わせて内容は随時追加してもらうと良いかと思います。
最初でも触れた通り、大切なことは、果たしてこのアプリをリリースして大丈夫なのか？ という、
承認者の疑問や不安を解消し、正しい状況とリスクを伝えることです。
定性的な情報だけだとリスクを正常に判断できない可能性があるため、
定量的な情報を提供し、客観的に品質状況を判断ができる状況をつくることが大切です。
結果、関係者が納得した状況でのリリースにつながり、トラブルも起こりづらくなっていくので、
リリース時の報告の参考にしていただければと思います。