見出し画像

バグ(障害)報告で大事にしていること

過去に経験したテストの現場

私が過去に経験したプロダクト開発のリリースされるまでの大まかな流れは下記の流れです。
① 企画 
② 要件定義  
③ 基本設計 
④ 詳細設計
⑤ 製造 
⑥ 単体テスト(④の確認)
⑦ 結合テスト(③の確認)
⑧ シナリオテスト(②の確認)

⑨ リリース
このプロジェクトでは、テスト工程を別会社(私が所属していたテストチーム)へ外注していました。
そのため、設計工程まで完了したタイミングで私が所属していたテストチームへ引き継がれます。
私たちで、⑥単体テスト・⑦結合テスト・⑧シナリオテストそれぞれののテスト設計、テスト進捗管理、バグ(障害)報告、レビュー依頼、テスト品質報告を行っていました。

現在経験している上流工程

現在は所謂上流工程を担当しており、下記の①②⑧⑨を担当しており、③〜⑦を別会社へ外注しています。
① 企画 
② 要件定義
  
③ 基本設計 
④ 詳細設計
⑤ 製造 
⑥ 単体テスト(④の確認)
⑦ 結合テスト(③の確認)
⑧ シナリオテスト(②の確認)

⑨ リリース

バグ(障害)報告で大事にしていること

ズバリ「誰が見てもわかるように伝えること」です。
当たり前のことですが…。
前述したように私が検出したバグを報告する先は別会社の担当者になります。
そのため、概要だけふわっと報告してしまうと先方で事象の再現ができなかったり、何が原因となってバグが起きているのか事象の切り分けに時間がかかってしまいます。

お互いのためにも、具体的に下記のようなことを意識しています。
・事象発生時のキャプチャ
 →時間も伝えること
 →プロダクトであればその状態を提出すること
・手順
 →実際に行った1手順ごとに伝えること
  例)
  ①〜を押下
  ②〜へ遷移
  ③〜を確認
・試したこと
 →異なる条件で行ってみてその結果を伝えること(原因特定のために)
 


この記事が気に入ったらサポートをしてみませんか?