We are developing a desktop application and I am responsible for GUI testing. Currently we have around 500 tests which take 8 hours to complete.

The tests are testing almost every button/menu/field etc. in the application. Some functions are taking 3 - 15 minutes because the application is actually measuring something, but most of the tests takes around 2 minutes.

The biggest problem I see is that a lot of tests are doing same steps before the "main test action" can proceed, for instance start with import of documents to use for testing, which takes several seconds.

How to reduce this time?

Parallel testing or some fancy execution environment is probably not a solution or what I ask for. I am more interested in the design of the test or some tips for decreasing the repetition of work.

  • are these tests automated? Commented Mar 26, 2014 at 13:56
  • did you consider running these at several machines in parallel?
    – gnat
    Commented Mar 26, 2014 at 13:59
  • 1
    Yes, the tests are automated. And I wrote that paralellization ins't applicable.
    – ne2dmar
    Commented Mar 26, 2014 at 14:10
  • 2
    "Automated GUI tests take too long" I see nothing weird here.
    – Euphoric
    Commented Mar 26, 2014 at 16:05

3 Answers 3


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.

  • We tried using preconfigured databases that already included imported documents, however it took the same time to restart the application as the import.
    – ne2dmar
    Commented Mar 26, 2014 at 16:07
  • +1 for your third paragraph. Chunking together some the tests to reduce the number of setups (despite your assertion that it is suboptimal) seems like the most logical alternative here. Commented Mar 26, 2014 at 22:21

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.

  • We tried this by choosing some essential tests (1 hour) that was executed on each scm commit and by running the main battery during night. Problem was that testers sometimes got build which would fail on the main battery because of some auxiliary function. As I see it now, it was management issue because only the version which passed full battery should ever get to testers. Now we are trying to do "branch-per-task" workflow and each branch has to be fully tested before it can be integrated to production branch.
    – ne2dmar
    Commented Mar 27, 2014 at 6:55

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.

  • 1
    This approach makes sense when you are using human testers where the goal is to get a feel for how the application is behaving, but in automated tests, you will end up with tests succeeding because of an effect of a previous test. Running the tests separately is extra overhead, but without it, your results are not reliable. Commented Mar 26, 2014 at 15:09
  • Agreed however if the OP is finding that tests are taking way to long, if structured well, some time can be gained by not repeating steps that are redundant.
    – scunliffe
    Commented Mar 26, 2014 at 21:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.