チェック項目で検出された内容は該当する作業に紐付けられ、各実行履歴は一つのログに記録されます。それぞれには特定の場所があります：
- タスクの検出結果これらはファクトリー内のタスクの品質セクションに一覧表示され、各項目の状態（未解決・修正中・修正済み・承認済み）が示されます。
- 特定のタスクに紐付かないテスト失敗例えば、予定通りに実行されたブラウザテストが失敗した場合、ファクトリーのレビュー欄に一時的に留まります。修正してタスクに変換するか、理由を添えて承認してください。
- 実行できないチェック項目例えば、プロジェクトにユニットテストフレームワークが存在しない場合、品質管理の「ユニットテスト」行にその旨が記載され、修正操作により対応するタスクが作成されます。
- 実行履歴各実行履歴の所要時間やコスト情報は、設定の「アクティビティ」欄に一覧表示されます。
作業全体にわたるパターン
一つのタスクで検出される内容は単なる詳細に過ぎません。30件のタスクで同じ内容が繰り返される場合、それはパターンとなり、そこから有益な判断が得られます。
注目すべきポイント：
- 繰り返し発生する検出結果複数のタスクで同じ問題が見られる場合、それは専門的な作業が必要な本物の技術負債か、あるいは自社の規約に合致しないチェック項目だと言えます。
- 誰も解決しない検出結果常に承認されるカテゴリは、本来の役割を果たしていないチェック項目だと言えます。
- 集中化最も多くの検出結果が生じているプロジェクトを調べれば、問題の所在が明らかになります。
実行履歴
アクティビティには組織内の全実行履歴が記載されており、エージェント、タスク、品質チェック、テストの情報が含まれます。結果、種類、プロジェクト、期間で絞り込み、該当する実行履歴を開けば、関連するチェック項目、結果、出力内容を確認できます。
ここでの有用なパターンは、関連性のないタスクで同一ステージにおいて繰り返し失敗が発生することです。これはコードの問題ではなくプロジェクト設定上の問題であり、タスクを再実行しても解決しません。詳細は以下をご覧ください：ビルドおよびテスト設定。
パターンを作業に変換する
繰り返し発生する検出結果はタスクに変換できます。それを把握する目的は、「このパターンが40ファイルに存在する」という事実を作業の対象とし、コードベースの永続的な状態にしないためです。
手動で確認するのではなく継続的に監視すべき状況においては、自動化がそれを検知して修正作業を開始します。
許容するのではなく調整する
検出結果が多すぎる場合、それはコードが特別に悪いのではなくチェック項目の調整が不十分だと言えます。
ほとんどの変更でチェック項目が発動する場合、それはコードベースの特性を示しているだけで問題を検出しているわけではありません。規約に合致しないルールか、あるいは容認している技術負債のいずれかです。どちらの場合もチェック項目を変更する必要があります。詳細は以下をご覧ください：品質ポリシーおよびゲート。