While Nerrvana has the capacity to run tests in parallel, to take advantage
of this feature you need to configure your tests using TestNG or JUnit* and
grouping them in threads in your code. Most importantly, the tests themselves
should be written so as to eliminate interference between them (e.g., one
test fails because a parallel test deleted data as part of its logic).
For example, using TestNG, if your testng.xml thread-count parameter is set
to 2 and your tests are grouped into 2 threads, you should be good to go.
Just select the platforms you want to run your tests on, and 2 nodes per
platform, as shown below.
Note: Depending on the number of platforms selected, there are currently
limitations on the number of nodes available. This is due to hardware
limitations, which we expect to be rectified in the near future. We appreciate
your understanding as we work to expand our operations.
With the selection shown above, Nerrvana will create two grids with two nodes
each. Thus you would have four concurrent threads in the application being
tested (platforms x nodes = threads).
You may wonder why we create two grids with two nodes, instead of creating
one grid with four nodes, since this would probably save us one virtual machine
running a Hub. The answer is that (1) if tests hang on one platform, it won't
stop other tests from running; (2) if tests on certain platforms finish faster,
we can destroy a grid and reuse resources to start the next test run; and (3)
Hubs require a minute amount of hardware resources.
Even if you’re unable to configure your tests using TestNG or a similar
framework, you can still run 'quasi-parallel' tests in Nerrvana.
Let's say you have two 20-minute tests (A & B) that you want to complete in
20 minutes, instead of 40. You accomplish this by creating four test runs
(instead of just one) and start them simultaneously from the UI or with the
Nerrvana Jenkins plug-in. You still need to make sure tests will not interfere
with each other. Also, since results will be located in four folders instead
of two, you'll need to aggregate them after upload. However, if you generate
them in XML format, for example, and download to aggregate, it's fairly simple.
This workaround does require extra maintenance and thought, but it will allow
you to run tests much faster.
With all of these techniques, there's still the challenge of aggregating
reports from different platforms into a single report. You can read more about
how we're approaching this here
* - These are not the only options for parallelizing test execution. For
example, there is also Testoob