If there ever was a “blueprint” for software development, I would have to say it would be a set of automated story tests. Experience so far reveals that a true specification for software must be documented using software.
Scenarios, as good as they are, cannot express the specifics of a software requirement as well as the automated version can. Automated scenarios add important elements to other forms of written specification:
- They express very specific uses of the system
- They express very specific data that the system maintains
- They express very specific results that the system must provide
- They introduce the language that developers use to talk about the system
Stories don’t specify software like automated story tests do, because they fail to demonstrate enough specifics to tell a developer what actually needs to be developed. The same goes for Use Cases and Software Specification Documents.
Scenarios can work as specifications because they do supply specifics to a point, but they still fail to express the real software context boundary in some important cases, and they take a very long time to repeat when change is made to the software.
The context boundary is the physical place where new software must interface with existing software and people. This boundary is often the cause of major issues. When these automated specifications are completed in advance of development, it distinctly separates the discovery work from the invention work by revealing this boundary in an objective way. This makes both intellectual activities easier by allowing smaller, more focused efforts to be made.
Automation requires that an external testing system know the precise behavior of the systems and people that the new system must interface with. These are things that those who request systems are responsible to provide, but often neglect by failing to adequately specify their needs. Sometimes, stake-holders completely disregard their responsibility and expect that developers would somehow already be aware of these external systems without any clear evidence that they understand. It is true that very valuable developers are aware of some important external systems, but there are so many, that general software practitioners would not be able to know all of the systems in even one industry. Just because a developer knows about an external system does not mean that they understand its importance to the business processes without business or customer knowledge.
It is obvious that the precise knowledge of a systems external interface is nearly impossible to know before any software is made. That is why we have agile software development. Agile software development doesn’t expect that all software requirements have to be stated up front. It just says that some specifications must be expressed up front in order to start.
When some of the software made, it’s like turning on the lights. Working software exposes places where more software is needed. The sooner the light shines, the sooner we know where to go next, and the fastest way I know of to get the lights turned on is to make automated story tests.