For example, I might think about writing test code to run these ways, as a second-order priority:
- parallel: Look to run multiple instances of the tests in parallel without them interfering with one another. Write data to unique locations per instance of the test to ensure this. Check that any data that the suites are dependent on is not altered in the execution of the suite.
- serial: Look to run the same suite multiple times against the same application in series, perhaps in a tight loop, without each run interfering with the previous. Consider carefully whether each instance of the test code leaves the application in a state where is should be conducive to another run of the test. Check particularly for cruft left behind by tests, either in the application's file space, database, memory and so on, or in your test output so that you don't misinterpret the results of the tests.