やさしいバグ管理の説明をはじめよう
プログラマーに良い仕事をしてもらうためにオススメの環境はなんだろう？
最新のパソコン、長時間座っても疲れないイス、エディタ、スクラップ・ビルド可能な仮想イメージ（VM、AWS）環境、デュアルモニター、などが思いつく。
では、素晴らしいチームに良い仕事をしてもらうために必要な環境として最初に思いつくことは、、、バージョン管理システムとバグ管理システムである。
もし、あなたがソースコードを書いているならすべての見つけたバグ・見つけられたバグを記録し、状態を管理しなければいけない。見つけたときは覚えていて、他の優先する作業をしたり、新たなバグを見つけたり、仕様変更の相談メールを受け取ったりすると確実に忘れてしまう。後工程の最も忙しいときに限って、忘れ去られた小さなバグが再発見されたり、たぶん大丈夫と楽観的に考えていた不具合っぽい事象が不具合となって報告される。よくあるトラブルの始まりである。
バグ管理の基本は、記憶に頼るのではなく、記録する
開発者は自分が見つけた不具合を覚えているが、それをいつ解決したのか、対応したのか、を記録しないことが多い。さらにテスターが発見したバグは報告されたとしても、開発者の中では新機能開発が優先事項であり、開発の手を止めて対処しなければいけないとは考えない。そのため、開発工程の途中で発見されたバグは忘れ去られてしまうか、担当不在のまま放置されることになる。
だからこそ、正式な形でバグ情報とバグの経過を記録しておく必要がある。
プロジェクトがスタートした時点でバグ管理システムは必須のツールとなる。
バグ管理システムとは？
バグ管理システムは、Bug Tracking System（BTS、バグトラッキングシステム）と呼ばれ、バグの発生から原因の調査・発見〜対応履歴、最終的に解決した、対応なしを記録し追跡するためのシステムである。
オープンソースでは、Trac、Mantis、Redmineなど優れたバグ管理システムがある。自分たちで構築したり運用が難しいなら、商用版のクラウドサービスを利用することもよい。クラウドサービスであればサーバーを構築したり、ソフトウェアをインストールしたりする必要がなく、アカウントを作成すればすぐに利用開始することが可能である。
エンタープライズ向けのバグ管理サービスのご紹介。
株式会社オープングルーヴが開発した tracpath（トラックパス）というクラウドサービスはチーム開発に必要な十分な機能とエンタープライズの開発で使われた実績のあるサービスである。
バグ管理システムが持っている機能とメリット
多くの開発チームで何かしらのバグを記録するためのデータベースをもっていると思うが、バグを管理するための専用ツールであるバグ管理システムには多くのメリットがある。
バグ管理システムはソフトウェア開発で発生する障害を記録しステータスを管理するための専用ツールである。Excelなどの表計算ソフトをつかってバグ管理している現場を見るが、情報共有、ユーザビリティ、メール通知など、バグ管理ツールを一度でも使ったことがあればExcelを利用したいと思わないくらい便利である。
バグ管理システムの機能とメリットの比較
| 機能 | バグ管理システム | Excel/メール |
|---|---|---|
| バグ管理 | バグを管理するデータベース機能を持つ。バグを一元管理し複数メンバーによる同時参照や更新が可能 | ファイルやメールは最新版（状態）が保証されておらず、一元管理もできない。同時編集が難しくチーム共有に向いていない |
| ステータス管理 | バグの発生から完了までのステータス管理が可能。対応済み、対応中の状態により残バグ数を把握し対応漏れがない。 | 最新の状態のみ管理が可能、バグの対応履歴（だれが、いつ、どのような対応）がわからない |
| 情報共有 | チーム全員で同じ情報を共有、状況の確認 | ファイルを共有、同時編集はできず、ファイルの上書きなどデータ喪失する可能性がある |
| 検索機能 | 全文検索やステータス検索による高度な検索機能 | Excelの検索機能 |
| 関連・添付機能 | 添付ファイルやスクリーンショットなどの仕様や障害を説明する資料を追加 | Excelシートに添付、ファイルサイズの巨大化、データの再利用、Word/PowerPointなど画像以外の添付が不可 |
| レポート機能 | バグの発生数、解決数、残バグのレポート機能 | フィルタ機能で代用 |
| 通知機能 | バグの新規報告、対応に対するメール通知やチャット通知機能 | なし |
| 外部連携 | Git/Subversion バージョン管理と連携、コミットによるバグの解消、コードの修正を連動 | なし |
すばらしいチームが持っている共通のバグ管理項目はチームにとってのルールである。たくさんある便利な機能の使い方を覚える必要はなく、バグレポートとバグ管理項目の簡単なルールを守るだけでバグ管理システムは良く機能する。
バグ管理に必要なバグレポートが持つべき情報
バグ管理システムは、ソフトウェアの不具合をすべて記録し、問題が解決するまでの発生から解決までを管理することができるが、正しいバグレポートを作成することがとても重要である。バグレポートに必ず記載したほうがよい項目を説明する。
このバグレポートが持つべき情報はバグに対応する開発者にとって必ず必要な情報であることを覚えておいて欲しい。
バグレポートに必要な3つのこと
- バグを再現するための手順
- 本来の動作、期待されること
- 発生した問題の症状
をできるだけ詳しく記述することである。
まずはこの3つがあれば、開発者は調査し原因を見つけることが出来る。
1.バグを再現するための手順
バグを再現するための手順はテスターの腕の見せ所である。再現手順はできるだけ「簡潔に、単純に」を心がけるとよい。いつも多忙な開発者にとって、再現手順が簡潔で分かりやすいというだけで調査にかかる時間が短くなり、最小の工数で問題点を見つけてくれる大きな手助けとなるのである。バグ対応している工程はソフトウェア開発工程の中でとても忙しく次から次へと対応しなければならない問題が降ってくる時期である。この工程での作業軽減は精神的にも、作業工数的にもすごく助かるものである。
2.本来の動作、期待されること
次は本来の動作、期待されることを記載すべきである。期待されるべき本来の動作・仕様がわからなければ開発者にとってバグなのか、仕様なのか判断できないことが多々ある。「ボタンを押下したら、エラーメッセージが表示されました」という報告があったとしても、入力のバリデーションチェックによるエラー機能や削除ボタン押下による注意メッセージの表示機能など「だから何？」となるわけである。
再現手順と同じく、期待される結果を教えて貰えるだけで最小の工数で問題点を見つける手助けとなる。
3.発生した問題の症状
最後は発生した問題の症状・・・テスターの環境で発生した「何か」をできるだけ詳しく教えて欲しい。開発者は発生した症状を知るだけで何が起こっているのか問題発見の気づきを与えてくれる。
バグレポートが持つべき情報とは、より良いソフトウェアを開発するために、開発者がほしいと思われる情報を必要十分な量で伝えることである。開発者は本来の開発と問題点の解消に注力し、テスターがソフトウェアの品質を上げるという意識でチームは動くべきである。
バグ管理システムのワークフロー
バグ管理システムの中で最も重要な機能はステータス管理とワークフローである。
バグは発見から解決まで以下のようなフローを経由して、ステータスを遷移しながら完了する。
最も簡単なフローとステータス
- バグの発見（新規）
- 担当者への振り分け（割当）
- 担当者の対応（対応中）
- バグ対応済み（確認待）
- バグの完了（完了）
1. バグの発見（新規/NEW）
バグを発見した人はバグレポートに必要な情報を登録する。
バグレポートに必要な3つの「バグを再現するための手順」「本来の動作、期待されること」「発生した問題の症状」を記載するが、他にも発生したバージョン、緊急性、発生頻度、システムログ、エラーログ、画面のスクリーンショットなどバグを解析するための追加情報を添付する。
2. 担当者への振り分け（割当/ASSIGN）
発見されたバグは担当者に割当する。割当は開発チームに割り当て、さらに開発チームのリーダークラスのメンバーが対象バグの発生した機能を担当したメンバーに割り当てる。
3. 担当者の対応（対応中/ACCEPT）
割り当てられた担当者はバグの原因を調査し、内容に応じて対応を行う。プログラムの改修が必要であったり、再現しなかったり、仕様であったり…調査結果を記録する。
プログラムのミスが原因である場合、プログラムを修正し、単体テストまで実施する。単体テストで問題が解消していることを確認し、バグ対応済み（バグの発見者による確認待ち）とする。
担当者の対応としては他に「対応しない」「再現しない」「不正な報告」などがある。
4. バグ対応済み（確認待ち/FIXED）
バグの修正対応が完了したら、発見者、または開発者以外のテスターが正常動作を確認する。問題の解消が確認出来れば完了となるが、バグが再発したり、新たな問題が確認された場合、担当者にやり直しを指示することになる。（ステータスは再オープン/REOPENED）
5. バグの完了（完了/CLOSED）
発見者、または開発者以外のテスターが完了/CLOSEDする。
バグ管理をうまく機能させるためのルール
- バグの再現手順は最小限の手順で書く
- バグの完了は発見者、またはテスターが行う
- バグ解決のスタータスを利用する（「修正済み」「対応しない」「再現しない」「不正な報告」）
- 「再現しない」は安易にクローズせず発見者による再確認
- 正しいテストができるようバージョン管理を行う。テスターがバグが直っていないバージョンで再テストしないように。
- バグ対応は口頭・メールではなく、BTSのみとする
- チームはBTSによる情報共有を徹底する
- プログラマーであれば、BTSによる連絡を徹底することで利用しないメンバーにもBTSによるメール通知で利用を強制する
- マネージャーであれば、新機能開発やタスクをBTSに登録し、担当に割り当てれば良い。利用を強制する。
- バグレポートはシンプルさを維持する。バグレポートに新しい項目を追加したい欲求はよくある。例えば、バグの発生回数用フィールドやブラウザのバージョン用フィールド、対応見込み時間フィールドなど気の利いた項目である。これらをバグレポートに受け入れない。受入始めたら次から次へと異なるフィールドが簡単に増加していく。シンプルさを維持できなくなったバグレポートは誰も入力しなくなることを理解しておく。
バグ管理を上手く機能させるルールとして10個にまとめたが、うまく使いこなすコツは可能な限り「シンプルさ」を維持することを意識しなければいけない。プロジェクトチームの多くの人たちが毎日使うツールであり、シンプルでなければ使われなくなってしまう可能性がある。シンプルさを維持することがもっとも大切なコツである。
まとめ
プロジェクトチームがソースコードを開発するとき、複雑な機能を実現するための課題・タスク・バグをきちんと漏れなく管理し、 データベース化しておくことは重要なことである
プロジェクトの成果物やリソース、活動状況をすべて追跡できる仕組みを導入することで、問題を発見しやすく、製品の品質向上に直結する。バグ管理データベースがないことは品質の低いコードを出荷してしまうことと同意である。
最後にバグ管理のメリットについて
- バグデータベースが用意されることで障害についてチーム内の意思疎通がスムーズになる
– 標準化されたレポートは、自由形式の電子メールや机越しの話よりも正確に内容を伝えることが出来ます - データベース化することで、バグの通番管理(追跡と参照)が自動化され、レポートのための分析や報告が提供できる
- 開発チームは、プロジェクトチーム、マネージャ、顧客、ユーザのそれぞれにとって重要な観点から考え修正を進めることができる。
– バグ管理システムを使わない場合、開発者やテスターの声が大きい担当者の報告したバグほど早く修正されがちになる - バグの発見→レポート→担当者割当→解決について、全てのライフサイクルを通じたバグ管理が可能
– バグがどこかのライフサイクルに潜り込み、早期修正が必要なバグから注意がそれることがない。 - 開発チームやプロジェクトチーム、テスターの全員が最新の状況を簡単に入手できる。
- 解決したバグはナレッジとなる。
– これらのバグ情報は、出荷される製品に紛れ込み、サポート部隊のコストを上げる原因、売上の伸び悩み、使えないシステムという辛らつな評価につながる傾向を見つけることが出来るかも知れない。
参考情報
Joel on softweare
「やさしいバグトラッキング」
書籍
基本から学ぶテストプロセス管理 – コンピュータシステムのテストを成功させるために –
本ブログは、Git / Subversionのクラウド型ホスティングサービス「tracpath(トラックパス)」を提供している株式会社オープングルーヴが運営しています。
エンタープライズ向け Git / Subversion 導入や DevOps による開発の効率化を検討している法人様必見！
「tracpath(トラックパス)」は、企業内の情報システム部門や、ソフトウェア開発・アプリケーション開発チームに対して、開発の効率化を支援し、品質向上を実現します。
さらに、システム運用の効率化・自動化支援サービスも提供しています。
”つくる情熱を支えるサービス”を提供し、まるで専属のインフラエンジニアのように、あなたのチームを支えていきます。
No Comments