ソリューション · リリースの回帰検証
3エンジンで回帰検証。判定は1つ。
pushとPRごとに3エンジンで回帰テストを実行し、PASS・CONDITIONAL・FAILの1つの判定にまとめます。不安定な検証を隔離し、失敗にはスクリーンショットと再現動画を添付します。
3ブラウザエンジンのマトリクス
3段階リリース判定
20回信頼性を追跡する実行履歴
80%要件カバレッジの目標
ケースの維持
回帰テストが、
コードの変更に追従する。
PR差分から追加・変更・削除を提案し、承認後に回帰テストへ追加します。リポジトリ・ブランチ・変更パスの条件に合わせて、pushとPRで自動実行します。
- PR差分の分析 → ケース提案 → 承認・却下
- 実行種別：スモーク · 回帰 · 新機能 · リリース前
- 承認待ち → 実行を承認
- 重複の整理と韓国語・英語・日本語への翻訳
検証の信頼性
結果が反転する検証を、隔離する。
同じコミットでの結果の変化を直近20回で追跡し、反転率20%以上で隔離します。実行と報告は続けますが、FAILの原因にはしません。
- 同じコミットで異なる結果になった場合に、反転として集計
- 隔離をCONDITIONALの理由として表示
- エンジン別に隔離：Firefoxだけで反転した場合はFirefoxのみ
- 隔離後も実行を続け、レポートに記録
リリース判定
1つの判定に、その理由まで。
致命的・重大な失敗はFAIL、軽微・低影響の失敗や隔離・判定保留はCONDITIONAL。すべてが初回で通過すればPASSです。ただし要件カバレッジが80%未満なら、全通過でもCONDITIONALになります。
- CONDITIONALは、条件付き通過ではなく人の確認が必要という合図
- 判定とともに、要件・チェックリスト・画面の検証範囲を表示
- FAIL・隔離・カバレッジ不足をブラウザ通知
- 修正コミットの再検証を、以前の判定に関連付け
よくあるご質問
回帰検証を始める前に
既存のテストケースを作り直す必要はありますか？
ケース生成は文書・コード・人の3つに対応します。コードから作成したケースと手動のケースを、同じ回帰テストと判定にまとめられます。
どのタイミングで実行されますか？
リポジトリ・ブランチ・変更パスに応じ、pushやPRで実行します。承認フローを有効にすると、承認後に実行されます。GitHub Actionsと併用できます。
FAIL判定で、PRを自動的にブロックできますか？
FAILはブラウザ通知と判定カードですぐに確認でき、失敗をJiraの課題にできます。PRチェックやデプロイを直接止めるリリースゲートは、プレビューです。
本当の不具合かどうかは、誰が判断しますか？
失敗ごとのスクリーンショット・再現動画・ログで、チームが確認できます。マネージドQAでは、専門家が結果を分類し、再現する不具合を特定して再検証まで行います。
要件カバレッジは、どのように計算しますか？
要件文書から検証可能な記述を抽出し、実際の実行で裏付けられた割合を計算します。コードカバレッジとは異なり、未実行のケースは含みません。
1つのブラウザだけで失敗した場合は？
結果と隔離をエンジン別に記録します。特定のエンジンだけの失敗は、その名前とともに一覧に残り、重要度に応じて判定に反映されます。
次のリリースから、判定を。
ステージングURLとリポジトリ1つから、通常約5分で初回実行へ進めます。デモで実際の判定カードをご確認ください。
sales@qoretix.com+82-33-242-0210平日 10:00–18:00 KST