Automation of any kind - programs written for customers, machines that build cars, video games, and, yes, tests too - are really instruments of process improvement. In every single case they have no less than one of the following effects on some value stream:
- They provide access to information which enables the completion of a step
- They reduce the amount of time a step takes
- They improve the quality of the outcome produced by a step
...and really, these all resolve down to a single impact:
Every piece of useful software reduces the amount of time required to complete some step in a value stream.
Whether or not the amount of time required without software made the step in question infeasible or caused the quality of its output to suffer is irrelevant, it's all a function of not being about to make a decision, come to a realization, trigger an action, store your findings, etc. quickly. There is nothing that software can do but we people cannot, given enough time. Even the fact that software runs the same way every time it is executed in the same context translates into an impact on the time it takes to get something done by minimizing the potential for rework.
It all comes down to time and process, which is what Lean told us in the first place. The customer for a test just happens to be the development team that will use the test to avoid releasing crappy software to their customers.
Why does this matter? ...because people bandy about all these different explanations of what tests "really are..."
- A test isn't really a test... it's a specification
- A test isn't really a test... it's process control
- A test isn't really a test... it's a performance metric
Tests have the side effect of eliminating the need for a lot of those things but, at the end of the day, a test is a piece of software that reduces the cycle time of a development team by eliminating delays between the introduction of a defect and its discovery.
A.K.A.: a "test."
