Finally as the rehearsals advance the musicians would want to practice in an environment that closely replicates the opening performance, so you would arrange the seating plan, the acoustics, the conductor, etc… to be the same each time, it would probably not be possible to leave it all set up in situ, so you would define the process: e.g. a seating plan, acoustic configuration, etc so you could consistently setup and clear away (ready for the next time), it may not always be the same people doing the setup and clear down so the instructions would need to provide a step-by-step guide. The setup and clear down would be time consuming and prone to human-error so you may look to use a robot that could be programmed to complete the task the same way each time, on demand.
Testing software is like this, the product is not a monolithic entity it is an ensemble of systems that will be ready at different times, so to reduce the dependencies between the systems and speed up the testing process we need to interact with these other systems even if they are not quite ready: just like the musician playing along with the other instrument sections without them actually being there. In testing terms this would be called Service Virtualisation.
Maintaining one or more persistent environments becomes costly, you wouldn’t do this in the orchestra metaphor, yet according to the World Quality Report 2018 31% of organisations still do this, from my experiences I suspect that this is much higher for so-called End-to-End environments. Relying on a person or team to setup and teardown environments introduces yet another bottleneck (their schedule) and potential inconsistencies (human error), nowadays we see much more infrastructure as code and tools that can automate the build and tear down process – like the robot above. This is a subset of a process called Robotic Process Automation.