Proper preconditions: vital to (test) success

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.

ben-visser-marzoWhy did this made me happy? Because they were used to increase the controllability of the project rather than an excuse why certain things might go wrong,… and they’re not to blame.

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!

 

 

More information:

Ben VisserBen 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.

Anuncios

Deja tu comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: