（学習ノート）JSTQB アジャイルソフトウェア担当者 2.2 アジャイルプロジェクトでのテストステータス
はじめに
アジャイルテスト担当者のシラバスを読んで、重要なところを引用し、感想をつけた学習ノートをまとめました。この記事は「2.2 アジャイルプロジェクトでのテストステータス」が対象です。
アジャイルでのコミュニケーション
進捗の記録、可視化のツール
バーンダウンチャート
リリース全体または、各イテレーション内の進捗を追跡できる
リリースまたは、イテレーションに割り当てられている時間に対する、完了すべき残作業の量を表す
引用：https://www.graat.co.jp/blogs/cjssfx1r6ozkf08300162zcdm
引用：https://www.graat.co.jp/blogs/cjssfx1r6ozkf08300162zcdm
アジャイルタスクボード
目的
イテレーション計画で決まった各タスクのステータスを一目で詳細に分かるように表現する
使い方
色分けしたカードを使用してタスクの種類を判別する
タスクをタスクボードの未着手（to do）、仕掛り（WIP）、検証（verify）、完了（done）などの列に移動させて、進捗をマネジメントする
タスクのステータスが意図した速度で変化していない場合、何らかの問題が進捗を妨げている可能性がある。
進捗の伝達ツール（プラクティス）
デイリースタンドアップミーティング
目的
進捗を妨げる可能性のある、あらゆる問題をチーム全員が認識し、状況に応じて解決する
参加者
アジャイルチーム全員（テスト担当者を含む）
報告内容
前回のミーティング以降に完了したもの
次回のミーティングまでに完了する予定のもの
進捗の妨げとなるもの
品質の伝達
顧客満足度調査
メトリクスの収集
欠陥検出率
再テストと回帰テストの結果
欠陥密度
要件カバレッジ
コードカバレッジ
コードチャーン（バージョン間の追加・変更・削除コード行数）
回帰リスクのマネジメント
回帰リスクが増加する要因
コードチャーンが多く発生する
ビジネスニーズを満たすために、 以前にデリバリーされたフィーチャに対して変更が行われる
回帰リスクをマネジメントする
自動テスト、手動テストケース、テストデータ、他のテスト成果物など、すべてのテスト資産をイテレーションごとに最新にする
すべてのテストレベルでテスト自動化に取り組む
⇩
回帰テストを管理し、自動化する
回帰テストのマネジメント
テスト資産の管理
手動／自動テストケースから回帰テスト用のテストスイートを選択
関連性のなくなったテストケースを削除
（管理時のポイント）
自動化に適しているかどうかを考慮する
各イテレーションで時間を確保して、行う
すべてのテストレベルでの自動化
目的
プロダクト品質に関するフィードバックを迅速に獲得できる
方法
自動ユニットテスト
ビルド検証テスト
自動受け入れテスト
回帰テスト
テストタスクの自動化
自動化可能なテストタスク
テストデータ生成
システムへのテストデータのロード
テスト環境へのビルド＆デプロイ
ベースラインへのテスト環境の復元
データ出力結果の比較