QAエンジニアのバグの扱い方

バグ報告

バグを見つけた場合、基本的にはバグ報告を行うはず。
しかし、忙しい中、頑張って読まないと内容がわからない書き方は、それだけでバグの改修が後回しになったり、改修されにくくなる。
ここでは、僕がこれだけは抑えて書こうという点をまとめる。

タイトル

タイトルはおおよそ20文字程度で、タイトルを読めば内容がわかるくらいシンプルかつ、ポイントを抑えたものにしよう。
目指すゴールとしては、タイトルだけ読めば、改修作業に入れるくらい。

〇〇だと✗✗となる

みたいな感じ。

タイトルがわかりやすいだけで、バグ改修の速度が変わるといっても過言ではない。

QAエンジニアの腕の見せどころ
どれだけ短い言葉で、バグを正確に伝えられるか。
このスキルがあるだけで、かなり重宝される（はず）

現象

何が起きているのかを書く。
これは、タイトルがわかりやすく書けていれば、特に書かなくてもよい。

再現手順

再現するためのStepを記載。
理想は、3から4Stepくらいまで、再現手順を絞り込むこと。
発見当時は、Step6くらいでも、少しずつ絞り込むと、Step3くらいまで少なく出来ることは多い。

QAエンジニアの腕の見せどころ
再現手順を最小に出来るかどうか。
ここは、仕様理解度や、センスなんかもあるかもしれないが、再現手順を減らすことは、実装者への負担を減らすことにもつながる。

期待結果

これが実は非常に大事。
期待結果が無い場合、何が正しい結果なのか？何も持ってバグと言っているのか？が伝わらない。
逆に、期待結果が書けないのであれば、書けるまで情報を精査したり、意思決定したいしないといけない。

厄介な物でいうと、パフォーマンスとか、触り心地系の指摘は伝え方が難しい。
その場合は、補足となる情報を集めたほうが良い。

• 他の類似サービスとの比較

• 色々な条件（端末やネットワーク）での結果の比較

• 今のままだと、何が問題で、どんなリスクがあるのかの説明

この期待結果を書いていない場合が、僕の経験上多かったと思う。
期待結果が無い場合、改修しても、何を持ってOKとするのかの基準も無いことになるので、結果的に自分の首を締める。

QAエンジニアの腕の見せどころ
誰が見ても納得感のある期待結果を記載すること。
期待結果自体を信頼されていなかったり、疑われたりしているようではまだまだ。

優先度や重要度の提示

QAエンジニアとして、報告したバグに対して、優先すべきかどうかなどの考えを添える。
サービスとして致命的と言える内容（毎回クラッシュするとか、データが保存できないとか）の場合は、誰が見ても優先して改修すべき内容だから良い。

QAエンジニアとして、提示していきたい内容としては大きく分けて2つある。
1つ目
テスト実施のブロッカーとなるバグの場合。
バグの改修が行われないと、テストの実施が行えない場合は声を大にして伝えるべき。
これは、シンプルにリリーススケジュールに影響が出てしまうからだ。
バグを早期検出しても、改修時期を誤るとリリースが遅れてしまう。
そうならないためにも、QAエンジニアが主体的にバグの改修をコントロールすべきたど考える。

2つ目
リリースまでに改修しなくても良いバグの精査。
改修するにもエンジニアの工数は必要だ。
しかし、エンジニアの工数には限りがある。
よって、検出したバグを上からとにかく改修してもらうのではなく、サービスとして、リリースに向けて必要なバグだけにフォーカス出来る状況を作り出す。
そのためにも、QAエンジニアがバグの精査をすべきである。

もちろん、現象としては軽微でも、なんか怖い部分のバグというものはある。
例えば、決済やお金が関わるところのバグだ。
その場合は、調査だけして、大きな問題がなければ一旦後回しにするなど、柔軟に対応していこう。

QAエンジニアの腕の見せどころ
出ているバグに対して、自分の意思を持ってバシバシ精査していく。
検出したバグを全部改修していたら、いつまで立ってもリリースすることができない。
本当に問題になるものだけを見定めていく力は必要だと思う。

バグのトラッキング

バグの報告をしたらそれで終わりではない。
報告したバグが、現在どういったステータスなのかは常に目を光らせよう。
報告したからには、最後まで見届ける責任があると考える。

改修されたら、修正確認をすべき。
再現できなくて改修できない場合は、再現させる。
どうしても再現できない場合は、どれだけやって再現しなかったのかを記載して、QAエンジニアがcloseする。

報告したら、完了（close）するまで神経を通しておくのがQAエンジニアの責任だと考える。

QAエンジニアの腕の見せどころ
リリースまでに改修しないと判断したバグを、その後の計画に乗せていく。
計画的に、すでに検出したバグを改修するという計画をプロジェクト内で通すことが出来るか？が腕の見せどころ。
基本的には、新機能の開発でエンジニアの工数は埋まるだろう。
しかし、バグの改修の必要性などを説明し、計画の中に食い込めれば、プロダクトの品質も徐々に固くなっていく。

最後に

組織や、チームの文化によってQAエンジニアに求められることの優先順位は変わってくるとは思う。

ただ、バグ（ソフトウェアの不具合）や仕様不備などに一番多く触れる存在にはなるはず。

問題や課題をわかりやすくシンプルに伝える。
何が問題で、どうなるべきなのかを添える。
このあたりのことは、どの場所でも必要なことだと思う。

僕個人のスタイルというか、求めている姿は

• どれだけテストしないでよいか

• どれだけバグを改修しなくてよいか

というところを常に探っている。
テストはしないよりしたほうがよい。
バグも改修したほうがよい。
そんな当たり前なことに対して、あえて逆を行く。

• テストしないわけにはいかないな。

• バグを改修しないわけにはいかないな。

と、自分自身の中で結論が出るまでやらなくて良いのではないか？を繰り返している。

QAエンジニアとして、ぜひともバグの扱いのプロを目指していこう。
自分の手で改修作業ができなくても、バグに対してやれることはたくさんある。