test objects design

As I am reading Robert Martin’s old Engineering Notebooks on Iterative and Incremental Development I came across a business argument, perhaps the best non-engineering argument of which I have many; against following Waterfall software methodology. You are welcome to download all his PDF docs from ObjectMentor’s site via this googleq:

The iterative process is producing data about the schedule. The completion times of the slices are giving us unambiguous empirical measurements that help us predict when the project will be complete. There is a wonderful thing that mangers can do with these measurements – with this data managers can… manage. They can stop dictating, stop motivating, stop losing control Don’t let this article mislead you. If you follow the advice above and begin developing projects in an iterative and incremental way, bluebirds will not fill your sky. Schedules will still be missed, there will still be bugs, problems, and mis-aligned expectations. Software is, after all, software; and software is hard. However, what you will be doing is using a process that produces data; whereas waterfall produces none. With that data, managers can try to manage the project. (…)a process that produces data can be managed. A process that does not produce data, cannot be managed.

I dig this argument: producing data about the schedule. I can see why in Scrum you should be keeping track of past Sprints and why you should be looking at how many backlog items are “YET TO BE DONE” and not DONE VERSUS PLANNED as happens to be the model in Waterfall. I think this is an important distinction. - In traditional Waterfalll you Plan what will be done with the assumptions that no changes will occur - but what if you can produce data everyday about how many items are yet to be done? how many are planned? you can calculate your running conversion, hence burndown chart, hence velocity as a measure of effectiveness.

I don’t have much experience with Scrum since most of my work has been on Test Design in what I would call Waterfallish type of project, however I must admit that my engineering process for Testing software has been iterative. I devised plans that were based in uncertainty but I never tracked data about my schedule, partly because I never designed it nor have never been on teams that designed it. Since Test Management is about repeatablitlity let me make a strong recommendation to myself and my team now to implement such a measure.