How to load test a workflow system with stages linked by email

Question

I want to load test a web site that provides a workflow system. In this system, users register and then create a record. An administrator sees the new record in their task list on a web page; they modify the record in the system and an email is sent to the user with a link to a web page for the updated record. The user clicks the link and adds information to the record and the administrator's task list is updated. The workflow continue with administrator updates sending emails to the user and user updates being seen on the administrator's task list. This workflow is strictly sequential, records move from stage to stage with emails and task list updates providing links between the stages.

How can I handle the emails linking the stages of the workflow? I would like to access the links within these emails to get the correct page but I do not know how to read emails within a web test. There are also a concerns about the time that emails take to pass through the various email systems and the order they would arrive; but I am sure that these concerns can be handled.

The only test method option I have found is to load lots of records into the system's database before the test runs. This data would have records at each stage in the workflow. The test cases would be data driven with the URLs for handing each record.

Are there any other methods?

My test system uses Visual Studio Web Performance and Load tests.

Answer 1

I can see a few directions you could take with this situation:

1. Break it up: You could build load tests for each phase - that is, you have one test that registers a user, has an administrator open the task list, modify the record, and send the email. The next test opens the link (since you know the format of the email and the link this is doable), adds information, has the administrator check the task list and modify information, and so on, so that each group of steps between emails has a load test.
   • You'd want to run these in sequence first, in order to isolate load issues through the registration process without any other interaction masking potential problems.
   • You want to do this on a test server that mirrors the expected environment as closely as possible. Partly this is to reduce outside interference, and partly so you can use a known starting point.
   • Your starting point should be a database with a selection of records. You shouldn't need to actually send the emails and trawl them for links to click unless the link is generated on the fly with a random or quasi-random seed that isn't stored anywhere (this is unlikely, since that information is usually stored in the database for verification purposes).
   • You would want to restore your test database into the application database before beginning your tests. This ensures that every run of your load tests has the same starting point.
2. Run it together: You could use the test database to have a variety of records for each stage, and have your load test run actions from each part of the workflow. This is closer to the real-world usage scenario, and should probably be part of your strategy as well. Building a load test like this will make it more difficult to isolate specific load issues, but will give you a more accurate idea of your application's capacity, particularly if you can load to failure (this isn't always possible - I've seen load tests bring down the company intranet without stressing the application under load, and there are hard limits to some types of request queuing that could act as a throttle on your application).
3. Step by step: You could have a load test for each individual step, which you can then run in sequence or concurrently. That is, one test for registering users. One for the admin task list. One for user response. And so on. This approach would let you do a mix and match approach.
4. Build the links yourself: You could take an end-to-end approach by building the email links yourself from the data that should have gone into the application database after the administrator completes the edit, then going directly to that URL.

This isn't a complete list, just a few thoughts on directions you could take.

Answer 2

I have used something like Mailtrap.io to perform similar tests. I can send a request to create a user, then in a validation rule or post request event handler check the email service api to get the email link so the next step can then confirm the new user, etc. The problem I am having is that the free version of Mailtrap only allows 2 emails per second and if you have an email heavy workflow you don't get much of a load before you hit that.