Lately I have gotten quite an awakening to the realities of waterfall testing processes. This has come in the form of writing tests for my current client as they are preparing for a major release.
So what have I learned? First, large development groups end up with large testing teams. This makes for challenges in coordinating efforts within the group. To overcome this I believe there needs to be well defined expectations and a single owner of the effort.
The second thing I have learned is that such testing generates volumes of documentation. This is documentation that need to be constantly revised and reviewed.
Of course the ever present question of our times is why are you not using TDD? In order to answer that I think we need to break it down into further questions.
Digging into this issue brings two main questions to mind. First, how do we ensure business partners that thorough testing has been done? Second, and this is very important, what does the environment we are in dictate?
The first question is exactly what the waterfall method is intended to address. The main problem is that it is very costly. If a missed requirement is found during testing not only does the problem have to be corrected, but all of the testing documents need to be scanned for conditions that might be affected. Cost is also increased due to the fact that these are not automated tests. There is no button that can be pushed that will rerun all the test. Weeks can be spent doing a proper regression test.
As a consultant the second question is a key consideration. A contractor can advise, but the client still has the final say on what methodology will be used. The best thing that you can do is present facts objectively in a way that highlights benefits.
The one main draw backs that I see with TDD is that while it self documents for the developer, it does not do the same for the business stake holder. Their one assurance is that they have been seeing the product in regular increments. Tools may help address this concern, but there are no silver bullets.
I am sure I am over simplifying the problem. In the end I want to have my cake and eat it too. I want to cover my butt with documentation, but I also want the benefits of finding out early when that documentation is not accurate. To that end I will continue to learn from experiences such as this.