Before you can jump into recording or scripting your transactions, you need to have a good understanding of your transactions. Having a good plan before you start recording your transactions eliminates false starts, skipped steps, and highlights aspects of your transactions that you need to think about before your script goes into production mode.

Step 1: Know your transactions and map them

Not all transactions are built the same. A good way to get a deeper understanding of your transactions is to map them out. To get started:

  • List the key tasks your users need to do on your website or app.
  • Generate flow charts of your user's journeys. Think about the different paths the user may take to achieve different goals on your site (there may be multiple paths to the same goal).
  • Make sure you’re mapping out both your happy paths (the all-goes-as-planned path) and the unhappy paths (user errors and system failures). Examples of unhappy paths include difficulties such as failed user authentication, out of stock inventory, invalid credit card information, failing supporting systems like merchant services, or database errors. You want to test these common problems to make sure your system responds appropriately and guides the user back to the happy path or redirects them to the appropriate error messages.

Below, we detail out the key functions and user journeys for a simple e-commerce site. The diagram describes several happy paths a user may take. Some tasks depend on the successful completion of other tasks, and we could break down some tasks further.

Chart: Sample e-commerce transaction map

To simplify things moving forward, let's consider the shopping cart functionality only. The shopping cart functionality is the simple task of selecting an item, adding it to the cart, and editing the cart.

The temptation is to expand the shopping cart functionality to include testing for the search or the checkout process. We recommend you keep the functionality compartmentalized so that you’re testing one key task at a time.

Chart: The shopping cart user journey

Step 2: Practice your transactions

You may think this sounds silly because you know your transaction. Right? We’re sure you do, but having had rehearsed your transaction a few times makes the recording process go so much easier for you. Of course, you can always delete the recording and start over, but it's nice to get it done the first time.

Also, you may discover other things about your transaction that you maybe haven't thought about before. What you discover may be as simple as an added step you hadn't considered before such as logging off or clearing a shopping cart, or something serious like your regularly scheduled test resulting in real merchant fees. That brings us to Step 3.

Step 3: Consider the data impact and real-world consequences caused by your testing

Your transaction monitors load a real browser and act like real users on your site. So, you need to consider several things before starting your monitoring.


If a user needs to log in to perform a task, the monitor needs to log in too. Consider the authentication process and protecting logins and passwords. You can protect your authentication information in our vault, and hide them in your test results. Also, consider the permissions you grant the test user account from a security standpoint, and keep an eye on the user to make sure there is no suspicious activity.    

Synthetic tests can mean real consequences

Your monitor is going to perform very real transactions that may have real consequences on your system. The following are examples of things you should consider before bringing a transaction into production.

Your monitor selects products and makes reservations on your site just like your users. If your monitor causes a product to run out or fills all of the reservation slots, your monitor will generate errors and your users can't buy the items or make reservations either. Use products that won't run out and perhaps set up a special reservation list just for testing.

If you're testing a shopping cart, and your system reserves items while they sit in a shopping cart, be sure to empty that cart as part of your transaction. Otherwise, your tests will fail, and users can't purchase the item either when all of your inventory ends up in your monitor's cart.

Also, your inventory system may see the purchases for the items and start increasing inventory due to the activity. What steps can you take to prevent your other systems from responding to the activity?

Your monitors make real orders on products, so your system may generate pick tickets and actually ship product (we've seen it happen). Consider how you will prevent these other systems from firing.

Talk to the people that control the other processes. Learn how can you can safely test your end-user scenario from start to finish, without negatively affecting your business. 

Wait! There is more you need to consider

The above is a condensed list; we've got a broader list of caveats and tips in our Knowledge Base. Make sure you review the information, and really think about the processes connected to your transaction. If you still have concerns, please reach out to Support. Our support team has had a lot of practice foreseeing and helping people resolve problems associated with transaction monitoring.