There are several approaches to attacking the time bloat of automated testing. Some of the approaches such as running multiple virtual environments and running the tests in parallel, and reducing the scope of what is actually tested may not not suitable for your workload, but are worth mentioning as possible strategies for other readers in the future.

One of the areas that automated tests can spend a lot of time, is getting the test run into the ‘test state’.

One suboptimal solution is group together the tests so that you only need to get into that test state once, and then you run all of the tests in this state as part of a group test. This is flawed, because you can have situations where tests only pass because of artefacts left over by an earlier sequences in the test run.

A more complete solution is to find a mechanism to quickly recreate your starting environment. Have a lot at the systemic effect of the import of these documents. Are they processed into different configuration files? are they updating multiple database tables? and then finding a more efficient mechanism for the injection of this state information into the test environment. However, this approach can be problematic if the format of the state information changes during product development, its a substantial job to recreate.

The solution I would probably use is to use a mechanism that allowed rollback. It might be virtual environment that could rollback to a snapshot, or perhaps using LVM below the file system and then at the start of each test, we just roll back to the start point, losing the artifacts from the previous run.

One strategy I see used is to group your tests by duration. Let’s say you’ve got 300 tests. 100 of them run in 30 seconds or less. 100 of them run 30 seconds – 60 seconds, and 100 of them run longer than that (maybe do a little statistical analysis to break them into 3 or 4 groups).

If you structure your test execution process (for example, using tagging in Cucumber) so that they are grouped by how long they typically take, you can run your quick stuff maybe every day, your medium stuff every other day, and your long running stuff once a week.

It’s not ideal, but “ideal” costs money (parallel processing against a large virtual grid for example), and not every shop can afford the expense.

Which automated testing tool are you using? This will significantly affect answers.

As for shortcuts yes you can trim down some of your tests.

e.g. If your first steps are always launching, logging in, navigating to module X… querying for “thing-a-ma-bobs” then running 12 scripts that do something with one. you can split your tests up so that you have the option of running each one end to end, or if the initial launch/login/navigation part is done, just run the remainder of each of your tests from that point.

Each of your tests should actually be recorded/written in a fairly modular format so that you can combine many of them together as needed and/or swap out one that needs tweaking.

e.g. for a desktop app I would expect a bunch like:

• Launch App
• Login to App (if applicable)
• Navigate to Screen X (one for every major part of your app)
• Select/View an ${Item} (whatever your items are)
  • Rename it
  • Modify it
  • Assign it
  • Unassign it
  • …

Hopefully (if needed) you can skip the first few steps once you’re “in” and just run the individual tasks.