> For the complete documentation index, see [llms.txt](https://docs.elevateab.com/elevate-helpcenter/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.elevateab.com/elevate-helpcenter/custom-code-testing/preview-and-qa-a-custom-code-experiment.md).

# Preview and QA a Custom Code Experiment

Pre-launch checklist for custom code experiments in Elevate A/B Testing, covering console errors, responsive behaviour, page targeting, and performance.

***

Custom code experiments need more QA than any other type, because the thing being tested is code you wrote rather than a configuration Elevate A/B Testing manages.

Do this while the experiment is in **Preview**, before launching.

### Code check

| Check              | What passes                                                                         |
| ------------------ | ----------------------------------------------------------------------------------- |
| The change appears | Your code executes and the intended change is visible on the targeted pages         |
| No console errors  | The browser console is clean on every variation, not just the one you built last    |
| No theme conflicts | Existing theme behavior still works: menus, galleries, variant pickers, cart drawer |
| Mobile and desktop | The change renders correctly at both widths                                         |
| Multiple browsers  | Chrome, Safari, and Firefox at minimum                                              |

### Targeting check

| Check                  | What passes                                                                                               |
| ---------------------- | --------------------------------------------------------------------------------------------------------- |
| Runs where intended    | The code executes on the pages you targeted                                                               |
| Does not run elsewhere | Visit pages outside the target, especially cart, checkout, and account paths, and confirm nothing happens |
| Excludes work          | Every path in **Exclude pathnames** loads without the code running                                        |
| Wildcards behave       | If you used `/products*`, check several different product pages, not just one                             |

### Interaction check

Click through the page as a visitor would. Add to cart, open the cart, navigate away and back, and start checkout. Code that works on load can still break a flow that runs later.

### Performance check

Compare load behavior between control and variation. Your control carries no injected code, so a heavy variation can lose on speed rather than on the idea.

If the variation is noticeably slower, fix that before launching. A performance difference is a second, unintended change.

### Tracking check

| Check                      | What passes                                                 |
| -------------------------- | ----------------------------------------------------------- |
| Events are arriving        | Visiting a targeted page produces an event                  |
| Correct variation recorded | The event records the version you actually saw              |
| Custom event fires         | If you added a custom metric, the action produces the event |

Experiment data is cached and refreshes every two hours. Select the refresh control next to **Experiment Settings** to pull live data.

### After you launch

Watch the first few hours. Custom code fails in ways that QA on a handful of pages does not surface: an edge case product, an unusual cart state, a browser you did not check.

If something breaks, pause the experiment. Traffic returns to your control immediately.

### Next steps

* Reading Results and Ending a Custom Code Experiment
* Troubleshooting Custom Code Experiments