この記事は何か?
ソフトウェアテストにおいて、バグ起票は日常的な業務です。しかし、バグ票の記載誤りや不足によって開発者とのコミュニケーションに齟齬が生じ、修正漏れや手戻りにつながることがあります。
本記事では、筆者が実務で経験したバグ起票のミスと、その対策をまとめました。
目次
バグ起票ミス1: 影響範囲の確認不足
特定の画面でのみ発生すると判断してバグ起票したものの、実際には複数の画面で同様の事象が発生していたケースです。
起票内容
ユーザー登録画面で入力値のバリデーションが正しく動作しない事象を発見し、「ユーザー登録画面の入力値バリデーション不具合」としてバグ起票しました。
実際の状況
ユーザー情報変更画面でも同じ事象が発生していましたが、バグ票には記載していませんでした。その結果、開発者はユーザー登録画面のみを修正し、ユーザー情報変更画面の修正が漏れました。
その結果、ユーザー受け入れテスト段階でバグが発覚して、手戻りが発生しました。
バグ起票ミス2: 発生条件の特定不足
特定の条件下でのみ発生する事象について、その条件を明記せずにバグ起票してしまったケースです。
起票内容
経費申請画面のファイルアップロード機能で、アップロードボタンをクリックするとエラーが発生する事象を発見し、「経費申請画面のファイルアップロード機能不具合」としてバグ起票しました。
実際の状況
エラーはPDF形式のファイルをアップロードした場合のみ発生していました。開発者はJPEG形式のファイルで再現確認を行い、「再現しない」と判断してバグ票を却下しました。
その結果、QAと開発の間でコミュニケーションコストが増加し、原因調査に余分な時間を要しました。
バグ起票前の確認手順
上記のミスを防ぐため、バグ発見後すぐに起票するのではなく、以下の3ステップで確認を行います。
ステップ1: 発生条件の明確化
バグが確実に再現する条件を特定します。
記録すべき情報
- 操作手順
- 入力値の詳細（形式、文字数、文字種など）
- ユーザー権限
- ブラウザとデバイス
- 発生日時
再現性の確認
同じ条件で2回以上再現することを確認し、偶発的な事象でないことを検証します。再現率（常に発生／時々発生）も把握します。
ステップ2: 発生パターンの特定
発生条件を変更して事象の範囲を特定します。
確認項目の例
- ユーザー権限：管理者、一般ユーザー、ゲストなど
- 入力値パターン：全角/半角、必須項目のみ/任意項目含む
- ファイル：形式（PDF、JPEG、PNG、Excelなど）、サイズ
- 環境：ブラウザ（Chrome、Edge、Firefox、Safari）、デバイス（PC、タブレット、スマートフォン）
ステップ3: 影響範囲の確認
発見した事象が他の画面や機能でも発生しないかを確認します。
確認対象の例
- 同じ機能を持つ画面
- ユーザー登録画面 → ユーザー情報変更画面
- 新規作成画面 → 編集画面
- 同じコンポーネントを使用している画面
- ファイルアップロード機能を持つすべての画面
- 同じバリデーションロジックを使用している画面
まとめ
バグ発見時は焦って起票せず、発生条件の明確化、発生パターンの特定、影響範囲の確認を行い、修正漏れや手戻りを防止することが重要です。