The temptation with synthetic user journeys is to create a single, long running journey that checks everything in one go and run it every 5 minutes. This may sound like a good idea because one journey is cheaper than five or because there’s fewer scripts to maintain, but it will make your life much harder and is likely to still cost as much due to the total time it takes to run. Therefore a good approach to user journey monitoring is to create atomic journeys.
The process for defining journey flows is not too dissimilar to normalisation theory in database design. You start with the main requirements in their fullest form, then iteratively break that down into smaller, atomic components. This is where the term ‘atomic journeys’ comes from. To illustrate this technique, let’s say you start with this flow called “New User Product Search, Checkout and Payment” and you wish to run it every 5 minutes from 1 region:
- Visit homepage
- Click “Register”
- Register a new user
- Return home
- Search for a product
- Select a product from the results
- Add the product to the basket
- View the basket
- Go through the checkout process
- Submit dummy payment
This script will take a long time to write, touch many parts of the target website and will require in-depth knowledge and a lot of care to maintain. It also produces 288 results per day (12 per hour). So the first step here would be to break it down to its main requirements:
- New user registration
- Product search
- Add to basket
- Checkout process
- Payment check
Depending on the architecture and behaviour of the target website, these 5 requirements could each be their own journey, however, this is unlikely to be the case as the payment check would probably require a checkout process to get to it. Also, depending on how the inventory works, adding an item to a cart inside an authenticated user session might tie that item to an account for longer and therefore use up inventory that real people might want.
So, a new set of journeys would be proposed (including frequency and subsequent results per day):
Once daily (1/day): New User Registration
- Start on the homepage and navigate to the registration page.
- A new user is registered on the website.
Every 3 hours (8/day): Product Search
- A search term is entered on the homepage and submitted.
- The results are validated against the search term used.
Every hour (24/day): Direct Add to Basket
- Start on a highly available product’s page.
- Add the item to the basket and verify the success.
Every 15 minutes (96/day): Existing User Login
- Start on the homepage and navigate to the login page.
- Enter and submit test login credentials then verify the success.
Every 15 minutes (96/day): Add to Basket and Checkout Process
- Login to an account with a product already in its basket.
- Start the checkout process and work through it.
- Attempt a dummy payment.
This final strategy will mean the target is tested for its most important functionality at least every 15 minutes, with other functionality checked less frequently to preserve costs. The total results produced would be 225, therefore cheaper to run. If your customer base spans two continents then the temptation with the first strategy would be to increase the test regions to two. This doubles your results produced and therefore dramatically increases costs. The proposed strategy would enable you to set some journeys to one region and some to another, thus keeping the results output and cost the same, but increasing the geographical test coverage.
Benefits of Atomic Journeys:
- Faster script writing – lower test times mean the build process is quick.
- Faster fault finding – atomic journeys make fault finding quicker.
- Lower maintenance overhead – fewer components means fewer things to juggle.
- More regional coverage – each journey can run different test regions for no extra cost.
- Better test coverage to cost ratio – this strategy produces 225 results per day from up to 5 regions, whereas a single 5 minute journey in 1 region would produce 288.
