I had a similar thought about two completely different things recently. The first is merely an example from life – its’ one of those things that you really don’t want to think about and if you can avoid knowing it at all (which means you should skip the next paragraph) that’s probably a good thing.
The second comes from material I’ve been preparing to teach a class on testing. But, I don’t want to get ahead of myself …
So,is it possible to know too much and does that knowledge put you at risk or at least a disadvantage?
DON’T GO THERE! I DON’T WANT TO KNOW THAT!
A colleague and I were chatting and, I’m not quite sure how, the subject turned to that old kid-friendly dessert – gelatin (notice, I did NOT name a brand). It’s a staple of church suppers everywhere. We’ve consumed it with all manner of fruits (and even carrots) sliced and shredded into it. I personally have taken the square slightly more rigid kind and had contests to see who could make the little blocks stick to the ceiling.
Through all this, I never really considered one of the key ingredients – cow bones. Oh, yes I did go there … and it is probably some knowledge I could have lived without. I was even reminded this week as my wife made my daughter’s birthday cake and used a package of unflavored gelatin for the ganache that went between the layers. I still ate it, mind you, but somewhere in the back of my mind were those bones.
KNOWLEDGE IN WHITE, BLACK AND GRAY
So, laying aside the thoughts of “dessert”, we can focus on the rest of this article and me real point. As I said, these thoughts came around when I was writing some material on testing. There are many schools and approaches, but you can basically file actual testing into one of three major groups: White Box, Black Box or Gray Box. We’ll focus on White Box where the tester knows all the internal workings of a system. You can probably infer thoughts on the other methods and research them on your own. Our focus will be on the risks and disadvantages of “knowing too much”.
In White Box testing, I (the tester) end up assuming far too many things along the way. I have to because, in the end, I really cannot know as much as I think I do – even if I wrote the system. While I write tests for every known path, I skip the thought that paths may exist that I haven’t accounted for. My testing tends to be one or two dimensional: I do it with a distinct result in mind and I will manipulate my activities to get there. Placing all this focus on “success” means I don’t press the negative testing as much (or at all) and I proceed as if I have created the perfect, functional system.
That’s where the risk and disadvantage comes flooding in. By making all those assumptions up front, I’ve boxed myself into a narrow band of testing that doesn’t vary enough from the normal expectations. My testing, while appearing to check off all the boxes, ends up inadequate to really prove out the functionality once other “less knowledgeable” people show up and try to break it.
In the end, to lessen the risk and increase the advantage, you need to blend your system testing across the board and make it look far more Gray Box. Doing that, you don’t rely solely on your expert knowledge – and you end up with a richer testing base and broader outcome. Besides, nobody really needs or wants to know everything about everything … that’s exhausting and at times unappetizing.
Just another thing to think about as we all gorge during the Holidays!
Bio:
Mark Moore has held multiple professional positions in IT and business for nearly three decades serving organizations both small and large, public and private. With over half that time as a project manager, he has successfully managed major initiatives spanning multiple years with a cost of over $3 Million and teams of over 250 people. He has been a Project Management Professional since 2002, served as President of the PMI Western Michigan Chapter, and presented at multiple NCPMI Annual Events. Mark holds a Masters of Education degree from Colorado State University with a concentration in Adult Education and Training. He is an experienced writer, speaker and presenter on project management and team building topics. Mark is the Principal Consultant for Broken Arrow Associates, LTD. He and his family live in a rural area outside of Raleigh, North Carolina.
To contact Mark for opportunities or questions, send an e-mail to info@baa-ltd.com.