We all know about Black Box Testing and we've all heard the debates about it versus White Box Testing and we all once wondered idly whether there's such a thing as Grey Box Testing and weren't particularly surprised, or bothered, when we found out that there is.
Wherever you fall on this greyscale spectrum (and the right answer is wherever you think the best result will be for a given piece of work) you'll definitely have had days, or weeks, when you're Black Hole Testing. Those are the projects where progress and then time, and then you, are sucked into a heavy and dark place from which no amount of effort can get you over the event horizon.
When you're in the middle of Black Hole Testing, your boss will doubtless be exhorting you to work harder, longer, faster, better, cleverer and weekends. His or her targets were the first things vacuumed up by the void, and they've now dropped out of an Einstein-Rosen Bridge several months in the future. Meanwhile, the no-hair theorem seems to link baldness and project management.
And what can you do? With the utmost gravity, approach your boss and tell them that it's not possible to escape from a black hole. Of course, mention the project triangle and the Mythical Man Month and, of course, spend some time going round in circles about the possibilities and how none of them are appealing, and then, of course, think once or twice more about getting the Dev team in to do some of the testing. And then roll your sleeves up and work out, based on clearly stated assumptions about relative risk, derived from whatever relevant data you have, how and where you're going to have to cut or compromise, what needs to be time-boxed, where you can be shallow and where you have to go deep. Then you might end up with a hole of a different colour.
Testing is always about the identification and management of risk and so you should be thinking, and documenting decisions, in those terms whenever you allocate your testing effort. If you do, you'll fall into fewer holes and when you're in one you'll be better prepared to pull yourself out.
Wherever you fall on this greyscale spectrum (and the right answer is wherever you think the best result will be for a given piece of work) you'll definitely have had days, or weeks, when you're Black Hole Testing. Those are the projects where progress and then time, and then you, are sucked into a heavy and dark place from which no amount of effort can get you over the event horizon.
When you're in the middle of Black Hole Testing, your boss will doubtless be exhorting you to work harder, longer, faster, better, cleverer and weekends. His or her targets were the first things vacuumed up by the void, and they've now dropped out of an Einstein-Rosen Bridge several months in the future. Meanwhile, the no-hair theorem seems to link baldness and project management.
And what can you do? With the utmost gravity, approach your boss and tell them that it's not possible to escape from a black hole. Of course, mention the project triangle and the Mythical Man Month and, of course, spend some time going round in circles about the possibilities and how none of them are appealing, and then, of course, think once or twice more about getting the Dev team in to do some of the testing. And then roll your sleeves up and work out, based on clearly stated assumptions about relative risk, derived from whatever relevant data you have, how and where you're going to have to cut or compromise, what needs to be time-boxed, where you can be shallow and where you have to go deep. Then you might end up with a hole of a different colour.
Testing is always about the identification and management of risk and so you should be thinking, and documenting decisions, in those terms whenever you allocate your testing effort. If you do, you'll fall into fewer holes and when you're in one you'll be better prepared to pull yourself out.
Comments
Post a Comment