Recently I entered a project that was well underway for a while already and I was given an elaborate test plan and some recent progress reports to get up to speed. I’m not a big fan of elaborate test plans. Test plans, especially the elaborate ones, tend to end up at the bottom of a pile of ‘to do documentation’ or in the proverbial bottom drawer. But this time I was pleasantly surprised, because of the way preconditions and assumptions were stated and because they were addressed persistently in the progress reports.
Have you ever come across preconditions like “the test environment is properly set up and running by April 1st” (pun intended or “enough support is delivered by the supplier”. Never mind the vague ‘properly’ or ‘enough’, what I dislike about these preconditions is the fact that no one is responsible. Test environments don’t mysteriously get up and running by themselves! That requires al lot of hard work, let alone a test environment that does exactly what you need!
So, what made me happy was the explicitly stated responsible party for provisioning the test environment, in concert with the explicit reference to the mail in which the responsible party confirmed the agreement. The progress reports subsequently listed all the preconditions and their actual status as reported back by the responsible. So no surprise if the environment is provisioned one week late, or without a certain interface, or without …. what have you. That will all be anticipated. And it won’t surprise either if the environment is provisioned on time with all the trimmings!
So, project managers, client representatives, scrum masters, test managers, … etc. don’t settle for quick and easy ‘preconditions’ that will only allow for finger pointing and shifting blame, go for meaningful preconditions that are clear and actionable and have an owner!
Ben Visser is a highly experienced test manager and test consultant. In a career of over 15 years as a tester, he has fulfilled a wide range of test functions, from programmer of automated scripts, to test manager of a large international program. He has worked in traditional waterfall developments as a change manager responsible for test and acceptance environments, as well as model-based testing.
Based on this extensive experience, he co-authored Sogeti’s TMap NEXT® Business Driven Test Management (Nov 08) and more recently TPI® NEXT.
Philippe has worked with architecture related assignments since 1998 and as a educational facilitator since 2000.