Test design evolves along with software design, but only in response to customer scenario changes: the source software is inaccessible to the tester
Test design evolves along with software design, but only in response to customer scenario changes: the source software is inaccessible to the tester.† The testerís interpretation of the requirements of the scenario is independent from the developerís interpretation of those requirements.† The tester will test that the requirements are met, not a particular implementation of them nor a particular architecture.
Making the software accessible to testers causes them to see the developer view rather than the customer view, and leads to the chance they may test the wrong things, or at the wrong level of detail. Furthermore, the software will continue to evolve from requirements until the architecture gels, and there is no sense in causing test design to fishtail until interfaces settle down.† This is a classic example of a generic pattern where communication proceeds along two independent channels and is cross-checked at the end to give us a degree of confidence that neither channel introduced an error.† The side effects reduce the amount of work the tester needs to do to track changes in the implementation.
One of the modern methods (XP) has the customer himself specifying the AcceptanceTests.† This should detect cases of misinterpretation by the developer, but re-introduces the possibility of CommonModeError if the approach is taken out of context.† In XP the AcceptanceTests are an additional interpretation, from the customer, of his requirements.