プロジェクトで障害が検出されたとき、検出された障害の内容はきちんと管理しておく必要があります。
これには大きく２つの意味があります。
a) プロジェクトの課題管理・進捗管理
b) 品質分析（障害分析）
a) プロジェクトの課題管理・進捗管理
検出された不具合について、漏れなくかつ正しく対処するための記録でありエビデンスとなります。
検出者は不具合の内容を詳細に記載したレポートを提出し、これを以って担当者に調査・修正を依頼します。
レポートはその障害に対して担当者がどこまで対処を終えたかを表すステータスを持ち、これを管理台帳で一元管理することでプロジェクトの進捗状況を把握します。
また、レポートは不具合の内容によって重要度が設定され、対処する優先順位を決定します。
b) 品質分析（障害分析）
検出された障害の傾向を見ることで、組織や開発プロセスの弱点を見極めます。
レポートには分析の指標となる項目を記載し、各項目を分類分けし集計することによって目立った傾向・特徴がないかを確認します。
例えば以下のように機能ごとや混入工程ごとの障害検出数を表やグラフで表します。
この例では、カート機能の障害検出数が多く、設計に問題はなかったもののプログラム実装が非常に難しい機能であったことが推測されます。
複雑な機能にしてしまっていたか（上流の問題）、あるいは開発者のプログラミング技術の問題なのか（下流の問題）を考察する必要がありそうです。
障害分析の詳細については「テスト管理ツール CAT を利用した進捗管理・分析の運用例」を参照してください。
参考： 障害管理のワークフロー
BTS 連携
障害の管理は BTS【Bug Tracking System】（バグ管理システム）や ITS【Issue Tracking System】（課題管理システム）を利用して行います。
Wikipedia では BTS は以下のように説明されています。
バグ管理システム、バグトラッキングシステムとはプロジェクトのバグを登録し、修正状況を追跡するシステム。バグ管理システムの多くは、ウェブサーバ上で動作し、ウェブブラウザ経由でアクセスできるようになっている。
近年、ソフトウェアの開発においてはバグの修正が重要な作業と考えられている。バグを漏らさず修正し、再発を防ぐには、バグの発見日時や発見者、再現方法、修正担当者、修正履歴、修正方法、重要度、テスト状況などの多くの情報を残し管理する必要がある。開発によっては数千という数のバグが発生し、また多数のテスト担当者や修正担当者が関わっていることを考慮すると、従来のファイルレベルの管理では追いつかなくなっている。このような背景から、バグを管理するソフトウェアであるバグ管理システムが生まれた。
Wikipedia
日本では Redmine や Backlog 辺りが有名ですが、こちらは主にプロジェクトに関わる課題の管理やタスク管理用であり、開発業務におけるテスト工程に特化したものではないため、障害分析という観点で見ると幾分残せる情報に物足りなさがあるかなという感じです。
テスト項目との連動や障害分析までしっかりと管理するのであれば、テスト管理ツールの導入がお勧めです。
qTest や TestRail、PractiTest、日本製だと CAT といったクラウドサービスがあります。
いずれも既存の BTS との連携が可能で、例えば詳細な障害内容の管理はテスト管理ツールで行い、障害の修正・進捗の管理は Redmine で行う、ということも可能です。
もちろんテスト管理ツールだけでこれらを完結することもできます。
BTS やテスト管理ツールのほとんどは 公開API を持っており、CI 環境などから容易に操作を行うことができます。
自動テストと合わせてこの辺りの障害管理も自動化しておくと日常業務がスムーズになります。
実際の BTS を利用した運用方法については「テスト管理ツール CAT を利用した障害管理の運用例」を参照してください。
コメント