こんにちは。プロダクト品質部の後藤です。
システムの開発や運用時に切っても切り離せないのがバグです。
スパイダープラスでも開発・検証・リリース後で多種多様なバグの報告があがってきています。
今日は、日々不具合と格闘しているQAチームにおいて、「バグを活かす方法」について紹介したいと思います。
バグの発覚は避けるべき問題である一方で、発覚したバグの管理は、ソフトウェアの品質向上をさせるためにとても重要なプロセスといえます。
スパイダープラスではBTS(Bug Tracking System)にBacklogを使用しており、開発や検証時に不具合が発覚した時は以下のような流れで管理を進めています。
- BTSへ起票
- 不具合の調査
- 不具合の修正
- 動作検証
- 完了
検出されたバグをBTSに起票しただけで終わりにせずに、記載内容次第で多様な場面で活かしていけます。
具体的にどの場面でどのように活用できるのかを紹介したいと思います。
BTS(Bug Tracking System)へ起票
不具合の事象を起票する際に発生していた事象だけではなく、再現手順の記載・不具合が発生した時に使用した環境の記載・キャプチャ・再現時の動画を添付する等をすることで、不具合の調査をする際に原因を特定しやすくなります。
また、再現した時の状況を画像や動画で視覚的に見せることで、調査者と起票者のやり取りが減り、作業の効率化につながる事も期待できます。
私自身も不具合発見時に起票したり他メンバーの記載内容をレビューした時に、上記に記載した内容を気にかけて後工程に携わる人が効率よく作業できるように心掛けています。
不具合の調査~不具合の修正
不具合を調査する際に開発者がBTSに発生原因・流出原因・修正方針を記載しますが、修正前後の該当コードのみを記載するだけではなく、発生原因や修正方針などを詳細に記載することで、不具合修正後に実施するコードレビューや試験観点のレビューで、レビューアに対し不具合の概要を伝える以外にも、レビューでの仕様の認識齟齬による修正内容の矛盾や試験観点の漏れがないこと等を指摘しやすくなることが期待できます。
私自身も不具合修正後の結合試験の試験観点レビューをしたり、不具合修正後の試験項目の作成時に、上記が詳細に書いてあると実際起きた事象の解像度が上がりレビューや試験項目の作成がやりやすかったです。
動作検証
調査や修正の段階で開発者が流出原因・処置内容・影響範囲をBTSへ詳細に記載することで、テスターがテストを行う際にテスト仕様書に記載の項目以外にアドホックの観点で試験を行う際にも役立てることが期待できます。
不具合リリース後
BTS(Bug Tracking System)への記載内容が充実していることで、今後の仕様変更が発生した場合や試験項目を作成する際に不具合を流出させないために気を付けるべき点が明確になってきます。
また、各工程でBTSへ詳細に記載することで、今後市場で不具合を流出させないために役立てることができます。
私自身もテスト仕様書作成時に過去にBTSへ記載されていた不具合と似たような確認項目を作成したところ、検証時に不具合が発生したという経験があるので、BTSへの記載は後工程や不具合解消後の検証で似たような不具合を防ぐために有効な手段の一つであると考えています。
まとめ
私の経験を例に各工程での活用例を紹介しました。
BTS(Bug Tracking System)への記載内容が増えるとそれだけ手間が増えますが、開発プロセスの一環としてBTSへ有効な情報を記録に残すことで、不具合分析もしやすくなります。
その結果、製品の品質向上に繋がっていきます。
過去記事:不具合分析始めました
techblog.spiderplus.co.jp
スパイダープラスでは仲間を募集中です。
スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。