📝

0から始めるバグチケット運用

2023/09/24に公開

e2eテスト

testing

idea

この記事は何？

とある開発チームに一人目のQA/Testerとして参画した筆者が、「バグを扱うならこういうフローだな」「バグチケットにはこの内容を書いてほしいな」をまとめたもの

なんで書いたの？

~~「いうてバグチケットなんてテンプレさえ置いとけば誰でも書けるやろ」と思ってたら意外とそうでもなかったので~~ 自分の考えや知見をテスト技術者以外にも共有するため

誰向け？

開発チームに一人目のQA/Testerとして参画する/した人
- 本記事のURLを共有する、コピペしていい感じに削る、などすれば起票の質を一定以上に保てる……といいなと思ってます
今までなんとなくバグチケットを起票・運用していた人
- 第三者検証会社で10社近くの現場を見てきた筆者が「バグチケットってどこもだいたいこういうことを書いてるな」「だいたいこういう運用だな」と思った点をまとめたので、ある程度は参考になるはずです
  - 「これ書いとけよ」「これは要らんだろ」というご意見もお待ちしております。お手柔らかに

扱わないこと

バグの集計、分析、それをもとにした開発プロセスの改善など
- 「現象の記録」「担当者の把握」の2つができればとりあえずOKとしてます
デバッグの手順や情報集積など、開発者寄りのこと
- シンプルに筆者の知識がないので
BTS(ITS)の具体的な設定内容
- エクセルでもスプレッドシートでもJIRAでもRedmineでもBacklogでも通用する『考え方』を書きます

フロー

現象検知＝バグだ！と思ったら……

起票！の前に

以下の2点を意識する
- 勘違いかもしれない
  - 手順が違う・抜けている、期待値（正しい挙動・表示）を勘違いしている、など
- 主観かもしれない
  - 『ブラウザ・アプリがクラッシュする』『出したくないエラーが出る』など誰がどう見てもバグな現象はあるけど、『読み込みが遅い』『アニメーションがカクつく』『遷移先に違和感がある』など主観を含む現象もある

内容確認

仕様を知っている・判断する人に確認する

誰なのかは現場によってまちまち
- 歴の長い開発者だったり、ビジネス寄りの人だったり
『手順』『期待値』『現象』を明確に記載する。
- 各項目の詳細は後述

「◯◯ページの××で、△△のアカウントを使って、□□の操作をしました（手順）。Aという挙動をすると思ったんですが（期待値）、Bという挙動でした（現象）。バグでしょうか？」

「バグですね」→起票
「バグではないです」→起票しない

起票

タイトル

現象のみを端的に書く。上記の『手順』『現象』の部分。

例：「◯◯ページの××で△△のアカウントを使って□□操作をすると、Bという挙動をする。」

どう動くのが正しいか、どう困るかは書かない
「～になるように修正する」も書かない
- どちらもチケット内に書く場所があるので

手順

「誰でもその現象を再現できる」ように書く
- その手順を実施する人がどのくらいいるか判断するのにも使える
クリック・タップ1回を単位にするとわかりやすい
- 1.どこそこメニューを押す、2.どれこれボタンを押す、みたいな
  - 「ログインする」「アプリを開く」など自明のものを書くかどうかはお好みで
使用したデータなどを具体的に書いておくとなおよい
- 変なデータが入っていないかを確認するのに使える

現象

意見・感想は含めず、「何が起きているか」だけ書く
- 「"XX"というエラーメッセージが表示され、前画面で入力した内容が表示されない」
- 「YYページに遷移する」　など
キャプチャ（画像・動画）を添付する
- 該当箇所を線で囲ったり、テキストで補足説明を入れたりするとなおよい
- 文章より動画で見せた方がわかりやすい挙動もある
- きょうびPCもSPもキャプチャ機能は標準でついてるし、大した手間ではないはず

期待値

「どういう動作が正しいか」を書く
- 「エラーメッセージが表示されず、前画面で入力した内容が表示されていること」
- 「ZZページに遷移すること」　など
  - 「～である（する）こと」と書けば、現象と区別がつきやすい
  - 根拠になる資料、Slackのログなどがあれば明示する

発生環境

本番なのか、stgなのか、devなのか
- どの環境でも起きているなら「全環境」と書く
- 「本番で起きていて、ユーザーに影響があるか？」「環境差分によって起きているか？」を判断するのに使える

発生端末

iOS/Android、Mac/WinなどのOS種類、特定の画面サイズ、など発生する端末が限られる現象もある
Androidだと機種のメーカーによって挙動が違うこともごくまれにある
OSのバージョンで挙動が違うこともそこそこまれにある
どの端末でも起きるなら「全端末」と書く
- 「現象を検知するユーザーはどのくらいいるか？」「端末の挙動差分が影響しているか？」を判断するのに使える

（Appendix）重要度

「今直す」「後で（いつか）直す」の2値でいいと思ってます
影響範囲・影響度でマトリクスを作って修正優先度を決める……っていう手法を実践したことがあるけど、効果を実感できなかった
- 範囲・影響度の基準を決めるのがめんどくさかったり、優先度を決めても開発の着手順に反映されなかったり
- 基準がきっちり決まって、開発の着手順に反映できるならやる価値はあると思う

改修依頼

起票できたら、開発者に改修を依頼する。
タスク管理用に別途チケットを作るか、バグチケットをそのままタスクとして扱うかはお好みで。

改修確認

記載した手順を再度実施し、現象が再現しないことを確認する

直った（再現しない）
- 改修を確認できた旨をコメントして閉じる
- 該当する画面・機能のキャプチャ（画像・動画）を添付する
  - やっていない現場も多いが、個人的におすすめ
  - 「何を見てOKって言ったんですか？」を聞かなくてよくなる
直ってない（再現する）
- 再度、改修を依頼する
  - 期待値の認識がズレている場合もある

閉じる

『直った＝改修を確認できた』『直さないと決めた』のいずれかで閉じる

例外：誤記票

『起票者の勘違いで、正常な動作をバグとして起票した』場合
- フロー内の『内容確認』で防げる
誤起票である旨と仕様の根拠をコメントして閉じる

どの場合でも、閉じる際は理由をコメントに残す

『改修を確認できたので閉じる』
『こういう理由で改修しないと決めたので閉じる』
『こういう理由でバグではない（誤起票）ので閉じる』
- 無言で閉じると、背景がわからない！
  - 今も発生するのか、改修する予定があるのか、本当にバグなのか、無駄な調査工数が生じる
  - 当事者はわかっても他の人はわからない
  - 当事者もそのうち忘れるし、いなくなるかもしれない

（Appendix）心構えとかの話

『直さないと決めた』について
- 間違いなくバグだが、様々な理由で修正しないことは往々にしてある
  - 対応コストが大きい
    - 金銭、人員そのほかもろもろ
  - 影響が小さい
    - 起きてもそんなに困らない
  - 影響範囲が狭い
    - 手順が複雑だったり発生する端末が限られていたりで、出くわす人が少ない
- 長いこと放置されているバグはどうせ今後も直さない（筆者の経験談）
  - 重要じゃないから放置されてる
  - なので閉じてもだいたい問題ない
  - その場合、バグが潜在することのリスクを周知する必要あり
    - 修正コストなんかユーザーには関係ない
    - 気にする人は気にするかもしれない
    - こちらから見て小さい割合でも、該当するユーザーにとっては『100％起きる』現象
事実と意見を分ける
- 『こうすると再現します』『こういう挙動をしています』は事実
  - 手順、現象はこっち
- 『こういう動きをしてほしいです』『こういう場面で困ります』は意見
  - 期待値、重要度はこっち寄り
  - 意見であれば根拠を記載すること
    - 『ここで決めたように、こういう動きが期待されます』
    - 『こういうユースケースがあるので、この現象が起きると困ります』
ログを残すのが大事
- 閉じる時に理由を書くのが最たる例
  - 直ったから？
  - 直さないから？
  - 起票者が間違ってたから？
- 「こういう仕様です」
  - いつ、どこで、誰が、(できれば)なぜ、言った/決めたか示す
  - Slack、Notion、そのほかもろもろのURLを貼る。口頭で決めたならそう書く
すべてはみんなのため
- 開発者、新規参画者、他チーム、他部署などなど
  - 正しく起票できれば、必要な情報を正確に共有できる
    - どうすれば起きる？　＝　手順
    - 何が起きている？　　＝　現象
    - どう動くべき？　　　＝　期待値
    - どういう背景？　　　＝　各種議事録、ドキュメント
    - どういう結論？　　　＝　閉じる時のコメント
- 『みんな』には未来の自分も含まれる
  - 明日・明後日は覚えていても、来週は怪しい
  - 来月、来年となればなおのこと