Finally I’m going to write about the problems I have had moving away from a sequential testing phase. I got side-tracked with some Monster analogies, but before I move on to discuss any other topics I need to fulfill my promise about writing about this.
To summarize, no other concept is personally easier to state and harder to do than a sequential testing phase. Even when I am coding or creating, my mind always thinks about creating sufficient inventory to then make the context switch to then test. Even though I know this is incorrect and I am losing quality and building inventory by doing this, I seemingly can not help myself. I was thinking about why this is and I may have a theory.
I wonder if this default behaviour on our projects is due to how we were educated? All through out our years we had the pattern of building up a sufficient inventory of knowledge in classes and then having a large test or two to validate that the knowledge was indeed mastered. I think back to university and my Mathematics exams worth 90% of the grade, the ultimate big bang approach. No concept of failing fast in those courses. Sure there was some assignments to practice, but even that was not consistent across all the courses. Ultimately most of my courses after Junior High had an exam of at least 60%. And of course the problems that caused were very similar to project issues:
- By the time you know there is an integration issue it is too late to do anything about it.
- You cannot correct mistakes early so if something is misunderstood the number of mistakes is huge.
- These large tests, don’t provide opportunities to learn. They only provide judgement.
This last sentiment has stuck with me the most and I remind myself of this fact to ensure I test as early as possible. I remind myself that the noble purpose of testing is learning, not judgement. With most traditional projects, the testing phase is almost viewed as a judgement being pronounced on the project declaring whether it is successful or not. Almost like we are grading the project and determining if it has to go to summer school. We need to fundamentally shift our focus in testing to be that it is an opportunity to learn and not an opportunity to judge.
When you do this shift, something very interesting happens. The value of a Quality Assurance Departments and Testing groups lessens greatly. Those structures are all about judgement. If testing is about learning, then the people conducting it only naturally should be the ones that will learn the most! And that would be the developers and clients. (Hopefully together!)
I believe our educational system has now moved to more frequent, smaller tests to ensure that the tests are about learning, not judgement. It seems only now has our Information Technology projects also understood that it isn’t about judgement.
I would propose that rule #1.a of Software Development should be:
‘Thou shalt test the deliverables before each and every status report is given and status meeting is held’ (this would be daily but weekly at the latest’)
This would ensure that testing is not a separate phase and that testing really is a learning activity by being integrated in the entire lifecycles of the project.
And really, how can we report on status if we haven’t tested????
Any guess to what Rule #1 is? Share your thoughts and I’ll tell you mine on my next post.
Agile PMO 