System test scenarios can easily get quite complex, involving several concerns and obfuscating the actual use case that is to be tested.

In order to manage the complexity of scenarios it makes sense to first craft the procedure of the test case without writing actual code. Defining the required steps in comments, or even on paper first, provides a good overview of what the test scenario is about. Implementing the actual test case afterwards with regard to reasonable abstraction layers will result in more maintainable test cases, with potentially reusable functionality. We will cover this approach in an example later in this sub-chapter.

It's important to take test data into consideration. The more responsibilities a scenario holds, the more complex it will be to define and maintain the test data. It makes sense to put some effort into test data functionality that is being used commonly in the test cases. Depending on the nature of the application and its domain, it may even make sense to define a specific engineer role for this. Providing reusable functionality that is usable effectively can provide some relief; however, it may still be necessary to at least define and document common test data and scenarios.

Ultimately it doesn't help to ignore the complexity of test data. If the application domain does include sophisticated scenarios, ignoring this situation by leaving out certain test cases or postponing test scenarios until production doesn't improve the application's quality.

In order to craft predictable isolated test cases, the scenario should run as stateless and self-sufficient as possible. Test cases should have a starting point similar to production and not rely on a certain state of the system. They should consider other potential tests and usages running simultaneously.

For example, creating a new car should not make assumptions about the number of existing cars. The test case should not verify that the list of all cars is empty before the creation or that it only contains the created car afterwards. It rather verifies that the created car is part of the list at all.

For the same reason it should be avoided that system tests have an impact on the environment life cycle. In situations that involve external systems, it's necessary to control the behavior of the mocked systems. If possible, these cases should be limited in order to enable to execute other scenarios concurrently.