A Testing Phase – I just can’t quit you!

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:

  1. By the time you know there is an integration issue it is too late to do anything about it.
  2. You cannot correct mistakes early so if something is misunderstood the number of mistakes is huge.
  3. 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.


Author: Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: