この記事は何か？
本記事は、筆者がQAエンジニアとして働く中で経験した、バグチケットの書き方のよくある失敗例と改善案をまとめたものです。
目次
1. バグチケットのよくある失敗例
1.1. 「現在の動作」や「期待する動作」が曖昧
- 「現在の動作」や「期待する動作」の記述が曖昧で明確でない。
- 「現在の動作」の記述で「おかしい」や「間違っている」などの主観的な表現を使用している。
- 「期待する動作」の根拠が曖昧。
- 例：「要件定義書のどのページを参照」などが記載されていない。
問題点：開発者が正確な修正方針を立てられず、修正の手戻りが発生する場合がある。
1.2. 再現手順が不正確
- 具体的な操作手順が記載されていない。
- 手順が簡略化や省略されている。
- 前提条件（アカウント状態や使用するテストデータなど）が明記されていない。
問題点：開発者がバグを再現できず原因調査に時間がかかる場合がある。
1.3. 1つのバグチケットに複数の事象を記載している
- 異なる事象を1つのチケットにまとめて記載している。
- 開発者の混乱を招いて修正漏れの原因となる。
- バグの修正確認時も修正確認漏れの原因となる。
問題点：一部の事象だけ修正される場合がある。
1.4. 事象が発生した環境やバージョンが書かれていない
- QA環境やSTG環境など、どの環境で発生した事象か記載がない。
- バグが発生した端末（OS、ブラウザのバージョンなど）の記載がない。
- アプリケーションのバージョンやビルド番号が記載されていない。
問題点：開発者がバグを再現できない場合がある。
1.5. エビデンス（スクリーンショット、ログ、動画）の添付がない
- バグが発生した状態のスクリーンショットが添付されていない。
- ブラウザのコンソールログなどのエラー情報が記載されていない。
- 再現が難しいバグの場合、操作を記録した動画が添付されていない。
問題点：開発者が事象を正確に理解できなかったり、バグを再現できない場合がある。
2. バグチケットの改善案
2.1. 主観的な表現を客観的事実に置き換える
2.1.1. 良くない例
【タイトル】
ログイン画面の動きがおかしい
【事象】
ログイン画面の動きがおかしくてログインできない。
- 「おかしい」という主観的な表現が使われている。
- 本来どうあるべきかが記載されていない。
- どのような操作をしたのか記載がない。
2.1.2. 改善例
【タイトル】
ログイン画面でログイン後にブラウザが真っ白になる
【現状の挙動】
ログイン画面でログイン後にブラウザが真っ白のままとなる。
【あるべき挙動】
ログイン画面でログイン後にダッシュボード画面に遷移すること。
（根拠：要件定義書「ログイン画面」参照）
【再現手順】
前提: test001@example.com のテストアカウントを使用する。
1. ログイン画面でメールアドレス欄に test001@example.com を入力
2. パスワード欄に test001@example.com のパスワードを入力
3. 「ログイン」ボタンをクリック
【環境情報】
- 環境: QA環境
- OS: Windows 11
- ブラウザ: Chrome 120.0.6099.129
- 「おかしい」などの主観を排除して、客観的な事実のみを記載。
- 「どうあるべきか」を具体的に記載し、根拠も明示。
- 誰でも事象を再現できるよう明確な手順を記載。
2.2. 必要な情報を網羅的に記載する
2.2.1. 良くない例
【タイトル】
ユーザー登録画面の不具合
【事象】
ユーザー登録でエラーになる
【期待値】
ユーザー登録できること
- 具体的なエラーの情報が記載されていない。
- どの画面でどのような操作で発生するのか記載がない。
- どの環境で発生したか記載がない。
- OSやブラウザのバージョンが不明。
- アプリケーションのバージョンが不明。
2.2.2. 改善例
【タイトル】
ユーザー登録画面でユーザー登録時に500エラーが発生する
【現状の挙動】
ユーザー登録画面でユーザー登録時にエラーメッセージ「500 Internal Server Error」が表示される
【あるべき挙動】
登録完了画面に遷移して「登録が完了しました」というメッセージが表示されること。
（根拠：要件定義書「ユーザー登録画面」参照）
【再現手順】
1. ユーザー登録画面で全項目を入力する
2. 「登録する」ボタンをクリックする
【環境情報】
- 環境: QA環境
- デバイス: iPhone 16
- OS: iOS 18.1
- ブラウザ: Safari 18.0
- 具体的なエラー情報、操作手順、環境情報を記載
- どのような事象が発生しているか開発者に正確に伝わるようになる。
2.3. 1チケット1事象の原則を守る
2.3.1. 良くない例
【タイトル】
ユーザー登録画面の不具合
【事象】
・メールアドレスのバリデーションが機能していない
・パスワードの文字数制限が機能していない
【期待値】
ユーザー登録画面のバリデーションが機能すること
- 異なる事象が1つのチケットにまとめられている。
- どの事象を優先すべきか不明確。
2.3.2. 改善例
チケット1
【タイトル】ユーザー登録画面でメールアドレスのバリデーションが機能していない
【現状の挙動】無効なメールアドレス形式でもユーザー登録できてしまう
【あるべき挙動】無効なメールアドレス形式の場合、エラーメッセージ「有効なメールアドレスを入力してください」を表示すること
（根拠：要件定義書「入力バリデーション仕様」参照）
チケット2
【タイトル】ユーザー登録画面でパスワードの文字数制限が機能していない
【現状の挙動】8文字未満のパスワードでもユーザー登録できてしまう
【あるべき挙動】8文字未満の場合、エラーメッセージ「パスワードは8文字以上で入力してください」を表示すること
（根拠：要件定義書「入力バリデーション仕様」参照）
- 1つの事象につき1つのチケットに分割。
- それぞれの事象が明確になるため優先度付けしやすくなる。
- 修正確認も事象ごとに実施できる。
3. まとめ
バグチケットの書き方が不適切だと開発者がバグを再現できなかったり、修正に時間がかかったりする場合があります。
効果的なバグ報告を行うためには以下の3点が重要です。
- 主観的な表現を避け「何が」「どうなった」か事実を記載する。
- 再現手順、環境情報、エビデンスで誰でも再現できる情報を提供する。
- 1チケット1事象で、事象と影響範囲を明確にする。