Application Design is Bounded By Test Design

Problem: When do you design and implement test plans and scripts?

Context:

A system with mechanisms to document and enforce the software architecture, and developers to write the code. A Testing role is being defined.

Forces:

Test development takes time, and cannot be started just when the system is done ("when we know what we have to test").

Scenarios are known when requirements are known, and many of these are known early.

Test implementation needs to know the details of message formats, interfaces, and other architectural properties in great details (to support test scripts and test jigs).

Implementation changes daily; there should be no need for test designs to track ephemeral changes in software implementation.

Solution:

Scenario-driven test design starts when scenario requirements are first agreed to by the customer. Test design evolves along with software design, but only in response to customer scenario changes: the source software is inaccessible to the tester. When development decides that architectural interfaces have stabilized, low-level test design and implementation can proceed.

Resulting Context:

This provides a context for Engage QA and for Scenarios Define Problem.

Design Rationale:

Making the software accessible to the tester 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.

In short, test design kicks off at the end of the first major influx of requirements, and touches base with design again when the architecture is stable.

This is related to the (yet unspecified) pattern, "Testing first in last out," to the pattern Engage QA, and to the pattern Scenarios Define Problem.

Next: Engage QA