バグチケットはQAエンジニアが意思を持って優先順位を提示していこう
QAエンジニアとして業務をすると、バグを検出し、それをレポートすることが多くなると思います。
リリースまでの限られた期間に、多くのバグレポート（バグチケット）を報告はすると思いますが、件数が多くなればなるほど、どのバグから改修すべきかの判断が難しくなる。
一般的には、POなどが改修の順番を判断したり、エンジニア側が現象を見て改修したりするかと。
ただ、チーム全体で共通の認識とルールなどで改修すべき優先度の共有はなかなか難しいというのもあります。
そこで、僕が実際に取り入れてチーム内で運用していた内容を今日はシェアします。
前提となりますが、バグチケットはQAエンジニアが意思を持って優先順位をつけていくことが大事という考えの元、以下の内容を書いています。
優先順位について
限られた時間の中で、効果的に、効率的にバグの改修を進めるために優先度と深刻度の2つ軸を使っていきます。
1,2,3は改修必須
4は問題の内容や、状況によっては次回移行のリリースにスライド
5,6は時間に余裕があれば修正する。
修正コスト＆検証コストが軽いものであれば修正。
基本的に次回以降のリリースで計画的に対応していければ良い。
修正しないと積極的に意思決定するのもあり
未来永劫修正しないという判断が出来るならチケットはclose
次回移行、どこかで修正するかもしれない場合は、塩漬け
補足
表の中に - の部分が3箇所あることについて。
パターンとしては存在しますが、実際は使わない（使いにくい）ので、あえて組み合わせから除外しています。
一応、以下にそれぞれの扱いのイメージを整理しておきます。
深刻度 Minor かつ 優先度 High のケース
こちらは、QAの進行に影響がある時点で修正は必要なので、 深刻度もいっそMajorとして扱っても問題ない
深刻度 Minor かつ 優先度 Minor のケース
こちらも、QAの進行に多少でも影響があるのであれば、深刻度もMajorの中にまるめても問題ない
深刻度 Critical かつ 優先度 Low のケース
こちらは、そもそも深刻度が Critical な問題なので、優先度は Middle として扱っても問題ないですし、むしろ優先度Lowをつけてしまうと混乱するので除外
深刻度の内訳
深刻度はユーザーへの迷惑度を考慮して付けます。
Critical
リリースブロッカーとなる問題
サービスが提供できなくなる重篤なバグ
ユーザーの資産を脅かす、または損失させてしまうバグ
例）
決済だけが完了し、コンテンツは提供されない
個人情報の流出
常にレスポンスが遅い/アプリが落ちるなどサービス提供に影響がある
誤った情報が掲載されている
Major
リリースブロッカーではないが、サービスを正しく提供できなくなる可能性があるバグ
ユーザーがよく操作するシナリオで発生しているバグ
例）
発生頻度が非常に低いクラッシュやメモリリーク
表示系のバグでユーザーに対してミスリードとなるバグ
Minor
軽微な問題
リリースまでに必ずしも修正する必要はないもの
軽微な事象かつユーザー不利益がなく修正しなくても支障のないもの
修正しない場合でも、備忘録として「修正しない」という結論を残してチケットをcloseすることをおすすめする
後々、これ前に修正しなかったけ？など、混乱につながる可能性あり
現象の内容としてはMajorだが、ユーザーがあまり遭遇しないと考えられるレアケース
例）
視認性に問題が無い程度の表示崩れ
再現頻度が極端に低い画面のちらつき
QA優先度の内訳
主にテスト実施に影響があるか否かでつけます。
High
修正しないとテストの進行の妨げになる問題
改修されると、再テストする範囲が大きい問題
リリース日に影響が出る可能性があるので、優先して改修してもらう必要がある問題
Middle
修正後の修正確認や、再テストの範囲がスケジュールに影響出るほど大きくない問題
Low
ユーザーから指摘が上がったら修正するくらいの温度で済ませられる問題
リリース前のテストで僕が大事にしたいことは、バグなどの問題をアウトプットすることに遠慮が無いこと。
ただ、リリース日が近いのに、いつまでも指摘が出てくると変な空気になりやすいです。
しかし、空気を読んでアウトプットに遠慮や躊躇いが生まれることは、結果的に良くない。
だからこそ、問題を指摘する側のQAエンジニアが情報を整理し、どうすべきと考えているのかの意思を伝え、チーム内で最終的な決断までのハードルを下げるべきです。
僕が一番伝えたいこと
POは常に先を考えるタスクでいっぱいです。
エンジニアもバグとして報告されたら、大小かかわらず改修したくなると思います。
QAエンジニアの立場からしても、検出したバグは改修してほしいものです。
バグは改修したほうが良いか？
こんな質問を投げたら100％「改修したほうがよい」という回答になるでしょう。
QAエンジニアは品質の計測と評価は行えますが、直接的に品質の向上をする術を持っていません。
品質を直接的に向上させることが出来るのはエンジニアによるコードの改修です。
しかし、リリースまでの時間は限られています。
エンジニアの工数にも限りがあります。
リリース日をいつまでも、自由に延期出来るなら話は別ですが、ある程度区切って行くことも必要です。
だからこそ、QAエンジニアという立場から、検出したバグに対して、限られた時間の中で行える一番効果的な改修の優先順位を提示するべきです。
今、改修しなくて良いバグはどれか？
こういった質問を投げましょう。
今の部分を「次回のリリースまでに」という言葉に置き換えてもいいです。
最終的な改修の有無は、POが行うべきかもしれませんが、POがゼロから全て把握し、判断する必要は無いと考えます。
まずはQAエンジニアが判断をする。
その結果をPOやエンジニアに共有する。
チーム内で認識が揃えばよいのです。
最後に
僕に至っては、誰よりもバグを改修しなくていいんじゃね？っと発言しているくらい、率先して発言しています。
バグを未来永劫改修しないと言っているわけではありません。
眼の前のリリースまでに改修しなくて良いものを見定めようとしてるのです。
こうやって書いて見れば、QAエンジニア何だし、当たり前なんじゃない？っとも思いますが、ここまでやろうとおもうと結構大変です。
今回はソフトウェア的な意味でのバグに関する話でしたが、この他にも使用不備や要件漏れといった、エンジニアでは解決しきれない問題も、検出する問題としては存在します。
その話は、また別の機会に。
リリースして、新たな価値を世に出すことが一番大切です。
それを軸足にし、チーム内の誰よりも品質に意識を向けて、チームを、事業を良い方向に向けられる存在。
それこそが魅力的なQAエンジニアなのではないかと、僕は考えています。