Skip to main content

QA Testing

Before activating any treatment, you'll want to verify two things: that it looks right and that it reaches the right people. This guide walks you through both.

Before You Begin​

Ensure you have:

  • Access to Auxia Console
  • At least one treatment created (Draft or Published)
  • A test User ID for your use case (the specific user identifier used in your integration)

How QA Works in Auxia​

If you're coming from a traditional marketing platform, QA in Auxia works a bit differently. In most tools, testing means sending a proof to yourself or toggling a preview. In Auxia, QA is more structured because there's more to validate - treatments are personalized, governed by eligibility rules, and selected by AI models.

Auxia's QA workflow breaks down into two types of testing:

TypeQuestion it answersWhen to use
Rendering QADoes my treatment look and read correctly?New treatments, content updates, image changes
Guardrail QADoes it reach the right users under the right conditions?New launches, eligibility rule changes, config changes

Tip: For a first-time launch, run both. For content-only updates, Rendering QA is usually sufficient.

Rendering QA: Verify How Treatments Look​

Step 1: Set Up QA Users​

QA users are test accounts designated in Auxia's QA system. Once a user is set as a QA user, all normal rules stop applying - they can and will receive whatever treatments are assigned to them, even if those treatments are in draft or paused status.

  1. Navigate to Treatments & Journeys > QA and Testing
  2. Click Add QA Users in the User Configuration tab
  3. Enter the User ID for the QA user (this must match the user identifier for your use case)
  4. Optionally add QA tester names and tags for grouping
  5. Assign specific treatments to each user in preferred order
  6. Click Save

Important: Changes take up to 5 minutes to propagate after saving. Maximum 100 users can be inserted, reset, or assigned at a time.

Good to know:

  • QA works even for draft or paused treatments
  • QA ignores qualification criteria - the treatment will be sent regardless
  • If the user is missing data for a personalization field, the treatment still sends - the raw field string (e.g., ${personalization_field_1}) will be displayed instead

Step 2: Send a Test Treatment​

The next step depends on the type of surface your use case targets.

In-app / web-based surfaces (banners, carousels, in-app messages):

No manual triggering is needed. Once a QA user is configured with an assigned treatment, that treatment will automatically appear whenever the user navigates to the in-app or web surface.

Out-of-app delivery (email, push notifications):

You need to manually trigger delivery using the Test Treatments page:

  1. Within QA & Testing, click Test Treatments
  2. Enter the QA User ID (must match the User ID from Step 1)
  3. Optionally set contextual attributes
  4. Set Maximum Treatment Count (up to 10)
  5. Click Run Treatment Test
  6. If the status shows "successful", the treatment has been delivered to the specified surface

Step 3: Verify the Treatment​

Check the following on the target surface:

Email:

  • Renders correctly across email clients (Gmail, Outlook, Apple Mail)
  • Personalization fields show correct data (if a field shows a raw string like ${field_name}, the user is missing data for that field)
  • Images load properly
  • Links and CTAs point to the right destinations
  • Unsubscribe link works

Push Notifications:

  • Delivered to QA device
  • Title, body, and image display correctly
  • Deep link opens the correct page on tap

In-App / Web Banners:

  • Renders in the correct position on the page
  • Displays correctly across screen sizes (mobile, tablet, desktop)
  • Dismiss behavior works
  • Clicks point to the right destination

Guardrail QA: Verify Who Sees Treatments​

Testing Eligibility​

Eligibility testing checks whether a specific user qualifies for a treatment based on its qualification criteria.

  1. Navigate to the treatment on the Treatments & Journeys page
  2. Click Test Eligibility
  3. Enter the User ID
  4. Click Test - this reveals whether the user qualifies and why

What to test:

  • Positive test: Use a user who SHOULD qualify. Verify they do.
  • Negative test: Use a user who SHOULD NOT qualify. Verify they don't.
  • Boundary test: Test edge values (e.g., if the rule is "days_since_signup < 7", test with exactly 6 and exactly 7)

Running a Simulation​

Simulation validates your configuration at scale before going live. It tests a sample of your user base against your treatments.

  1. Navigate to the Simulation page in the console
  2. Define the number of users to include
  3. Select the treatments to test
  4. Click Run Simulation
  5. Review the results

What to look for in results:

  • Treatments with personalization fields appear in results
  • The percentage of eligible users aligns with your expectations
  • Treated vs. Control group splits match your experiment design
  • Traffic allocation matches your configuration

Red flags:

  • 0% qualification rate - rules may be too restrictive or personalization fields may be missing
  • 100% qualification rate - rules may be too broad or missing entirely
  • Skewed distribution - may indicate model bias or priority misconfiguration

Troubleshooting​

Treatment does not send to QA user​

  • Verify the QA User ID matches exactly (case-sensitive)
  • Wait 5 minutes after saving for propagation
  • Confirm the treatment is assigned to the QA user
  • For in-app/web surfaces: confirm the user is navigating to the correct page
  • For email/push: confirm you've triggered delivery via the Test Treatments page

Personalization shows raw field strings (e.g., ${field_name})​

  • This means the QA user doesn't have data for that field - the treatment still sends, but displays the raw string
  • Check that personalization field names match exactly in the treatment configuration
  • To see proper personalization, use a QA user that has data for those fields

Simulation shows unexpected distribution​

  • Review qualification criteria for each treatment
  • Check for overlapping or conflicting eligibility rules
  • Verify personalization field coverage across your user base

For issues not covered here, contact your Auxia support team.

Next Steps​

For deeper coverage including common QA scenarios, debugging live issues, and detailed checklists, see the Comprehensive QA Guide.