Letting Test Drive the Process

When I read the term "test driven development" I usually think of the process of developers writing the unit tests before writing the code.  Richard Collins, a Development Strategist, uses it to mean something different.  He advocates that test be heavily involved from the beginning.  Instead of relegating test to the end of the process to pick up the pieces, involve them from the very start.  He gives the following advice:

1. Involve test during design.  Have them help make the product testable from the outset.


2. Release to test often.  This is just releasing regular builds and having test look at them every day.


3. Maintain a 1:1 test:dev ratio.


4. Build testability into the product.  Factor it so that each part is testable before the whole is finished.

Basically he is saying make test a first-order member of the team, design in testing, and test all the time.  My thinking on the subject tends to agree with Richard's.  Involving test early and as an equal partner is critical to modern software.  As complexity increases, seat-of-the-pants testing (often done by developers) becomes harder and harder to get away with.

To varying degrees, this is how Microsoft treats test.  We hire skilled test developers who can program instead of QA engineers who might understand some Perl.  We get test involved early.  In fact, we involve them not only to help look at the plans for testability but also for overall design.  As the representatives for end-users, they often have a very good eye for the little things that will make a design that much better.  Also, at Microsoft, testing begins from day one.  Every product I've ever been involved with at Microsoft has had daily builds from very early on.  Every product has also had what we call BVTs (build verfication tests) that are run every day right after the build completes.  If any of their tests fail, the product is held until they can be fixed.