Skip to main content
Testing lets you validate a rule against real historical transactions before activating it. This helps you understand how many alerts the rule would generate, identify false positives, and fine-tune conditions before going live. The Rule Builder includes a dedicated Test step (step 3 of the wizard) with two testing modes: batch testing and single-transaction evaluation.

Batch testing

Batch testing evaluates your rule against a sample of historical transactions to measure its impact at scale.

Running a batch test

  1. Open the Test step in the Rule Builder.
  2. Select a time range — choose a preset period (last 7 days, last 30 days, etc.) or set a custom date range.
  3. Set the sample size — up to 1,000 transactions.
  4. Click Run Test.
Corsa pulls matching transactions from the selected period, evaluates each one against your rule’s current conditions, and displays the results.

Understanding batch results

After the test completes, you see:
MetricDescription
Matched transactionsHow many transactions triggered the rule.
Alert ratioPercentage of sampled transactions that would generate alerts.
Condition pathsBreakdown by which condition group (path) was triggered.
The results table lists every sampled transaction with its evaluation outcome. Click any row to see which specific conditions matched or failed.

Managing test tabs

You can run multiple tests with different configurations and compare results:
  • Each test runs in its own tab.
  • Rename tabs to track what you changed between tests (e.g., “Threshold 50k” vs. “Threshold 100k”).
  • Delete tabs you no longer need.

Single-transaction testing

Single-transaction mode evaluates your rule against one specific transaction, showing a detailed per-condition breakdown.

Running a single-transaction test

  1. In the Test step, switch to Single transaction mode.
  2. Enter the transaction ID.
  3. Click Run.

Understanding single-transaction results

The results show each condition in your rule with its pass/fail status:
ColumnDescription
ConditionThe property and operator being checked.
ExpectedThe value your condition requires.
ActualThe value found on the transaction.
ResultWhether this specific condition passed or failed.
This view is useful for debugging why a rule did or did not fire on a particular transaction.
You can click Switch to batch test to go back to batch mode, or re-run the single-transaction test after adjusting conditions.

Formula drift warning

If you modify conditions after running a test, the Rule Builder shows a warning indicating that the test results may no longer reflect the current rule definition. Re-run the test to get accurate results for your updated conditions.

Best practices

  • Test before activating. Run a batch test over at least 7 days of data to gauge alert volume.
  • Watch the alert ratio. A very high ratio (e.g., over 20%) may indicate the rule is too broad and will overwhelm your team with alerts. Consider tightening conditions or raising thresholds.
  • Use single-transaction mode for debugging. If a rule unexpectedly matches or misses a transaction, single-transaction testing shows exactly which conditions passed or failed.
  • Compare variations. Use multiple test tabs to compare different threshold values or condition combinations side by side.

What’s next?

Building rules

Return to the Rule Builder walkthrough to finalize and activate your rule.

Conditions reference

Adjust conditions using the full operator and aggregation reference.