プロダクト・開発チーム
どのリリースにも、同じ基準を。
スプリントが変わっても、判定ルールは変わりません。pushでスモーク、PRでケース提案、リリース前に3エンジンで回帰検証。失敗には証拠が付いてきます。
変わること
毎回のリリースに、4つの仕組み。
pushごとにスモーク
リポジトリ・ブランチ・変更パスで自動実行ルールを設定します。即時、または承認後に実行できます。
PRごとにケース提案
PRの変更から追加・変更・削除するケースを提案し、承認されたものだけをセットに追加します。
リリース前に回帰検証
Chromium・Firefox・WebKitで同じケースを実行し、結果の反転をエンジン別に追跡します。
1つのリリース判定
失敗の重要度・隔離・要件カバレッジをまとめ、PASS・CONDITIONAL・FAILで判定します。
ケース管理
ケースが、コードの変更についてくる。
新機能ごとに一から手で書く代わりに、文書・コード・画面から下書きを作成します。PRを開くたびに、変更が必要なケースを提案します。
- シナリオ・前提条件・入力値・期待結果・優先度まで下書き
- 検証できない下書きを作り直す
- 17カテゴリーのチェックリストで不足を確認
- 韓国語・英語・日本語への翻訳
検証の信頼性
不安定な検証で、FAILにしない。
同じコミットでの結果の反転を直近20回で追跡し、反転率が20%以上になると自動隔離します。
- 隔離された検証も、実行と報告を継続
- 隔離された検証はFAILの原因にしない
- 隔離がある場合はCONDITIONAL
- ブラウザエンジンごとに測定
1週間の流れ
月曜のpushから、金曜のリリースまで。
-
push
変更パスに合うスモークを実行し、結果をブラウザ通知で受け取ります。失敗はスクリーンショットとログですぐに確認できます。
-
PR
変更からケースを提案します。QA責任者が承認するとセットに追加し、却下した場合も履歴を残します。
-
リリース前
3エンジンの回帰検証とセキュリティ警告から判定します。CONDITIONALは人が確認し、FAILは修正して再検証します。
失敗をJiraの課題として作成し、実行結果に関連付けます。
よくあるご質問
製品チームのよくある質問。
QA担当者のいない開発チームでも始められますか？
はい。ケースの下書き・実行・判定はプラットフォームが行います。計画の確認や結果の分類など、人が必要な業務はマネージドQAに範囲を決めて依頼できます。
既存のE2Eテストコードはどうなりますか？
既存のコードからケースを読み取り、下書きを作成します。重複を整理し、検証できない下書きは除外します。
ステージングがない場合は？
ステージングを推奨します。アクセス可能なURLとテストアカウントがあれば実行でき、対象環境は導入相談で決めます。
CONDITIONALだと、リリースできませんか？
自動的な停止ではなく、人の確認が必要という合図です。軽微な失敗・隔離・カバレッジ不足のどれが理由かをカードに表示します。リリースはチームが判断します。
通知はどこに届きますか？
承認依頼・実行完了・FAIL判定・隔離・カバレッジ不足・ケース提案を、ブラウザ通知で受け取れます。
1つの組織で複数の製品を管理できますか？
案件ごとにリポジトリ・対象URL・テストアカウント・自動実行ルールを設定し、ダッシュボードで最新の判定を一覧できます。役割はQA責任者・テスター・顧客の3種類です。
次のリリースから、同じ基準で。
リポジトリとステージングURLを1つずつ用意して、デモでpushから判定までを確認できます。
sales@qoretix.com+82-33-242-0210平日 10:00–18:00 KST