ex-mixi Advent Calendar 2017 - Qiita 9日目をいただいた @kkakizaki です。
株式会社ミクシィの在籍期間は2008年から2016年までで、
QAマネージャーとして、次々に巻き起こる品質保証上の課題を何とかするお仕事をしていました。
現在は株式会社サイバードにて、同じく品質保証部門の長として、
品質保証だけではない様々な課題解決に勤しんでおります。
折角の ex-mixi なので、今回は この記事 の続きです。
開発現場に根強く残る8個のバグレポートアンチパターン
前回の記事は2012年に書かれたものですが、
現在も繊細なエンジニア達が死にやすい状況に変わりはなく、
影響の大きな死因の1つとして「イケてないバグレポート」が存在しています。
BTS にイケてないバグレポートが増殖してしまう現場の方は、
この記事をテスターに叩きつけてやってください。
アンチパターンその1：敬語
テスト業務が受発注関係で成り立つ現場に、
今も根強く残るバグレポートのアンチパターンが「敬語」です。
「○○の操作を致しますと……」とか「発生致しております」とか、
「大変恐縮ですが、ご確認の程を宜しくお願い致しまする」とか、純粋に読みづらいだけです。
バグレポートをうやうやしく書く必要はないです。シンプルに必要な情報だけ書くようにしましょう。
アンチパターンその2：別々の現象を1つのバグレポートに記載する
別々の現象を1つのバグレポートに記載する癖を持っているテスターも、
未だに開発現場には多く存在します。レポートの総数が増えると何か悪いことでも起きるのでしょうか？
1つのレポートに現象A、現象Bが記載されていて、
片方が修正できて、片方が修正できなかった場合、該当のバグレポートはクローズされないまま、
BTS に残り続けることになります。
そしてリリース直前になって現象Bが大問題に発展した……みたいな事例もあるので要注意です。
「1つのバグレポートには1つの現象」を必ず守りましょう。
※複数の現象を記載しても怒られないパターン
- 同一画面内の誤字脱字
- ワンアクションで同時に2つの現象が発生する 等
実際の現場では複数の現象を1つのチケットに収めることもあるけれど、
状況次第で即チケット分離を行う姿勢が重要。
アンチパターンその3：不具合が発生した状況から、更に色々な不具合を探す
ぼくのなつやすみの 8月32日バグ は興味深い不具合ですが、開発現場で同じことをやってはいけません。
まずは「8月32日がはじまってしまうこと」を不具合として報告し、修正を待ちましょう。
くれぐれも8月32日以降に発生する数々の怪現象をバグレポートとして量産しないように。
アンチパターンその4：クローズしたバグレポートをリオープンする
間違った手間の省き方の1つに「クローズしたバグレポートをリオープンする」というものがあります。発生した現象が過去に見たことがあるものだったら、そのバグレポートを再利用しようという心理が働いていると思われます。
リオープンは「修正したつもりだけど直ってなかった」時が使いどころです。
【正しいリオープン】オープン → 作業中 → 確認待ち → 直ってなかったらリオープン
【誤ったリオープン】クローズしたレポート → パッと見、同じ現象だからリオープン
何故クローズしたレポートをリオープンしてはイケないかというと、
「同じような現象に見えても発生原因が異なる場合がある」ためです。
原因が異なると不具合としては別のものなので、結局はバグレポートを別途起票することになります。
クローズしたバグレポートをリオープンして良いのは、
間違ってクローズしちゃったときと、間違ってバージョンが巻きもどちゃったときくらいのものです。
アンチパターンその5：クローズしない
信じられない話かもしれませんが「バグレポートをクローズしないで放置している」テスト現場が存在します。
QAテスターの役割の1つに「チケット駆動開発を円滑に進めるために開発チーム全体をナッジング(突付くの意)する」というものがあります。
バグレポートのリストを常に最新の状態に保ち、開発チームに情報を提供し続けるのはQAテスターの義務です。
バグレポートの動きが止まっている部分があったら、即座に開発チームとコミュニケーションをとって対策を検討しましょう。
アンチパターンその6：当て推量
開発の規模が大きくなってくると、情報整理の難易度も高くなるのは世の常です。
しかしバグレポートに当て推量を記載するような真似をしてはいけません。
「以前、こんな不具合があったので、今回の問題も同じだと考えられます。」みたいなコメントと共に全然関係ない事象のレポートのリンクを貼られても、エンジニアは対処に困ってしまいます。
その時々で観測できる現象を淡々と記載するようにしましょう。
アンチパターンその7：現象が変化したのにバグレポートを挙げなおさない
修正難易度が高い不具合、というものも世の中には存在します。
自然、エンジニアとQAテスターのやり取りも増えて、バグレポートのコメント数が多くなります。
時には、最初にバグレポートを挙げたときの事象と、修正を繰り返した後の事象が異なっていることもあるでしょう。
そんなときは最初のバグレポートはクローズして、新規にバグレポートを挙げなおすのが良い進め方です。
バグレポートの要約と内容のズレが解消できて、画面のスクロール量も減らすことができます。
適切にメンテナンスされているバグレポートは状況把握のコストを大きく低下させてくれるものなのです。
アンチパターンその8：現象が発生した時にすぐにバグレポートしない
不具合っぽい現象を発見した時に、すぐにバグレポートを起票しないQAテスターがいます。当然、下記のことが起こります。
- 報告そのものを忘れる。
- 現象を再現できない。
不具合っぽい現象を発見したときには、即バグレポートを挙げるようにしましょう。
バグレポートはQAテスターの重要なアウトプットの1つです。
まとめ
以上、最近またバグレポート界隈が乱れてきたため、警鐘を鳴らしてみました。
皆さんの周りで BTS が乱れていたら、テスターにこの記事を音読させましょう。
明日は @ekinoshita さんのエントリーです。
どうぞおたのしみにー！
