リリース影響評価と回帰テスト計画
例示ユースケースであり、顧客事例ではありません。
リリースの変更を影響を受ける構成、連携、テストに対応付けます。デリバリー責任者が範囲を決め、本番稼働の可否を判断します。
課題
ベンダーのリリースと自社の変更が、こちらで制御できないスケジュールで到来する。リリースノートを読み、何が壊れそうかを推測し、すべてをテストするか、覚えているものだけをテストしている。それでも欠陥はユーザーに届いてしまう。
現在の進め方
リリースが告知されると、アナリストがノートを読み、関係がありそうな点をチームにメールします。テスターは経験をもとに共有フォルダからスクリプトを選びます。連携先には遅れて伝えられます。本番稼働後、問題は誰もフラグを立てていなかった変更に遡って突き止められます。
シナリオを見る
ワークフローの例示です。字幕付き。
文字起こし
- リリースノートは届いても、チームは何をテストすべきか推測したままです。見落とされた変更は本番稼働後にインシデントになります。
- プランナーはリリースの変更を影響するアプリケーションとテストに対応付け、カバレッジの不足を明示し、何をテストしどう展開するかを提案します。
- 何をテストし何を後回しにするかはデリバリーリードが決めます。計画はレビューされ、テスト結果が本番稼働の可否を左右します。
- 測定するのはテストカバレッジと流出欠陥です。例示ユースケースです。貴社のケースについてご相談ください。
提案するワークフロー
- 対象アプリケーションのリリースノートと変更記録を取り込む
- 各変更を、影響する可能性のある設定、カスタマイズ、連携に対応付ける
- 影響範囲を既存のテスト一覧と突き合わせ、不足を明示する
- 回帰テストの範囲案と展開順序を下書きする
- テストと展開に進む前に、計画をデリバリーリードの承認のために提示する
人が判断を担う箇所
- 回帰テストの範囲と展開はデリバリーリードが承認する
- 対応付けできない変更は無視せず、手作業による評価のためにフラグを立てる
- 流出した欠陥は対応付けとテスト一覧にフィードバックする
プラットフォームの対応付けは、この構想を評価しうる環境を示すものです。実際の実装は、設定、ライセンス、API、データ、権限によって異なります。効果は定性的に記載しており、数値による主張には文書化されたベースラインが必要です。