Let me give you the punch-line and then explain myself:
As soon as testing starts every “project” becomes a test driven.
If there is no formal testing period then that phase begin the moment customers/users start using the product.
I’ve recently been watching a slow motion train-crash, I had no power to avert the train crash and those I could alert didn’t want to hear me. So I was thinking: what will happen in the end?
The project has been forced on the organization by external authorities. Even if it wasn’t the budget allocated means it is too big to fail, it will take careers with it so it much succeed. It will be an exercise in pass the parcel with everyone attempting to show they did what was expected to avoid blame.
Anyway… in the end, I thought, they will enter a testing phase, as with all testing phases it won’t be just a test phase it will be a test-fix-test-fix until such time as the organization runs out of the will to continue. Just like every traditional project.
Which, when you think about it, means that when this project enters testing it will become Test Driven.
Sure the project will spend months “designing” and “implementing” but the project is so big nobody can understand it. Only when the parts are brought together, and the deadline is close, will people do what it required.
At that point they will be test driven.
Up onto that point all the planning, designing, implementing and what not is just shadow play, people avoiding doing what is needed.
This argument can be extended to every traditional project where testing is left to the end.
Between the start of work and the start of testing work might be done but how much of this is usable, how much of this is finally included in the solution is anyones guess. Once testing all work is test driven.
All software development is test driven, in the end.
| Reference: | Every project is test driven in the end from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog. |
