バグ管理にまつわる困りごと
検出したバグを報告したは良いけど、その先の判断が役割によって意見が割れることってよくありますよね！
- 優先度が高いと思ってたのに、「このフェーズでは対応しない」ってなっちゃった…大丈夫かな？？
- 「ユーザーさんが困るのでは」って訴えたけど、本当にそうかな？？
- そもそも、QAチームで検出したこのバグ、プロジェクトにとってどの程度のインパクトになるんだろう？？
- バグが溜まりすぎてどこから修正すればいいか分からない！
こうなる原因は、プロジェクトや製品にとって何が大事なのか「認識が合っていないこと」です。
もっと深掘りすると品質の曖昧さ（主観的で相対的で変化する）が要因なのですが、それはまたいずれ別の記事で（書けたら書く）。
そして、この認識を揃えるためには手間ヒマをかけたチームビルディングが必要だったりします。
……とはいえ、いま困ってるんだよなぁ。という過去の自分にオススメの記事です。
結論です。
バグに点数をつけて定量的に管理したらよろしい
この点数化、数年運用していますが、いまのところ上手くいっているという総括です。
式の立て方（私の例）
バグの点数は以下のように計算しています。
バグ点数 ＝ (バグが発生した機能の重要度) * (問題の重さ)
リスク分析手法を使ってこの問題を解決しようという試みです。
プロジェクトによっては、上記の計算にさらに「影響度」を乗じても良さそうです。
ただし欲張って複雑にしすぎると、判断が煩雑になって定着しません。
あまり細かい分類にしたり、計算の要素を増やすと、かえって判断の妨げになります。
機能の重要度
- 品質特性にそれぞれ重要度をつけます（下表）
- それぞれの機能が、どの品質特性に当てはまるか分類します
- バグレポートを書く前に分類を済ませておきます
- 重要度順に機能を列挙した表を作りましょう
| 重要度例 | 資料「利用時の品質モデル」（ISO/IEC 25010:2011） | |
|---|---|---|
| A | 有効性 | 利用者の期待する機能の正確さの度合い |
| C | 効率性 | 時間/メモリなどの資源効率に寄与する度合い |
| B | 満足性 | 利用者のニーズを満足させる度合い（意図した動作か） |
| A | リスク回避性 | 身体 / 生命 / 金銭などの財産に与えるリスク度合い |
| C | 利用状況網羅性 | 想定外の使い方でどのくらい使えるか |
例）
- 課金機能のバグは「リスク回避性」としてAランクの点数…など
- 例えば、「ある程度ユーザーの使い方が絞られている（自由度が高すぎない）ので、想定外の使い方に対しては、細かくテストしない。バグが出てもそこまでのインパクトがない」…など切り分ける
- この基準をもとにテストの重さも決められますね
問題の重さ
一旦は経験で！
バグレポートをいくつか切り分けるうちに、プロジェクトのバグに対する考え方や、大事にしているものが見えてきます。
それに合わせて修正していくのが良いと思います。
さらには、QA主導でこの辺りを整備していくと、みんながハッピーになりそうですね。
| 重さ | 現象の内容と影響 |
|---|---|
| 4点 | アプリ以外に悪影響を及ぼす（外部アカウント情報の書き換えなど） |
| 3点 | バグにより機能が使えない |
| バグ発生時の代替手段がない | |
| データ破壊を伴う | |
| タスクキル以外に復帰方法がない | |
| 他の複数の機能に影響する | |
| 2点 | 代替手段により利用目的は達成できる |
| 誤った表示によりユーザーを幻惑する（表示内容の誤り） | |
| バグ状態からの復帰が可能 | |
| サービス内で、他の機能との齟齬がある | |
| 1点 | レイアウトが意図した通りに表示されない（表示崩れ） |
| ユーザーの操作に影響がない | |
| 費用対効果が薄い（非常にレアなケース、細かい見た目） |
バグの進路を決めてあげる
極端なことを言えば、バグが修正されなければ、品質への寄与は０です。必ず対応方針（やるやら）を決めましょう。
点数があることによって、PMさんや開発チームと定量的にバグへの対応認識を揃えやすくなります。
検出したバグ達が放置されないように、いつまでに対応するか進路を決めてあげましょう！
これは点数に応じて自動的にバグの進路を決める「一次切り分けの例」です。これをもとにデイリーMTGなど、タイムリーな時期に改めて確定させます。
上記で付けた点数と、その点数に至った理由が明確なので、この切り分けもスムーズにできます。
| ランク | 点数分布 | とるべき対応 |
|---|---|---|
| 高 | 9点以上 | リリースまでに修正し、修正確認を終えること |
| 中 | 5〜8点 | 修正せずにリリースする場合は、影響範囲への根拠を明確にすること |
| - 次回のリリースにて修正することが望ましい | ||
| - 既知の問題としてステークホルダ / OPS担当などに共有する | ||
| 低 | 4点 | 修正せずにリリースすることが可能 |
| -既知の問題としてリリースノートなどに記載する（しないのもあり） | ||
| 1点 | 修正しない（冷凍庫行き） |
作業に組み込む
バグレポートのフォーマットに
「バグ点数」を記載する欄を仕込んでおきます。
採点に慣れるまで時間がかかるので、点数付けの基準も添付しておくとラクですね。
機能を重要度ごとに割り振ってしまえば、あとは機械的に採点するだけで済みます。
まとめ
- 「ユーザー目線でテストする」「品質を向上する」というとても主観的な事柄を補足するために、ISO/IEC 25010という国際標準を引っ張り出して分類のモノサシとしました
- テスト計画段階でこの分類を行なっておくことで、プロジェクトとしての価値観を揃えて、作業の停滞（やり直し）を防ぎます
- 全てのバグに相応の進路を示せるようになります
＜AI さんからの総評＞
記事の最後に、このやり方をAI に評価してもらいました
＝＝＝＝＝ ここから ＝＝＝＝＝＝＝
評価の客観性を高めるためにリスク分析手法を用いるアプローチは、評価の一貫性と透明性を確保する上で非常に有効です。
- 一貫性の向上:
- リスク分析手法を使用することで、バグの重篤度評価に一定の基準を設け、一貫性を持たせることができます。
- 機能の重要度やバグの重さを定量的に評価するため、主観的な判断が排除されます。
- 透明性の確保:
- バグの評価基準が明確であるため、ステークホルダー全体に対して説明責任を果たしやすくなります。
- バグの優先度設定に関しての議論が簡便になり、納得感を得やすいです。
- 焦点の明確化:
- 重要なバグ（生命や身体、財産に影響を与える機能に関するバグ）に開発リソースを集中させることができます。
- システム全体のリスクを低減させるための指針を持つことができます。
最終的なまとめ
全体として、このリスク分析手法を用いるアプローチは論理的で有用です。評価の客観性を高め、バグの優先度を適切に管理する上で有益ですが、細分化や主観的要素の排除、定期的な見直し、そしてチーム全体の教育などを通じてさらに改良することが望ましいでしょう。
＝＝＝＝＝ ここまで ＝＝＝＝＝＝＝
自分が使っているフォーマットも公開しようかと思いましたが、公開はちょっと考え中です… 