I’m a simple man. Hard as I try to look cool, I’m but a simple being. And I sure get caught up in the details of things more than I really want to.
What I tend to find, time and time again, is that the root solution to all problems, issues, and challenges is usually a pretty simple one. And, it seems like the more years I walk this earth the more I seek out the simple answer first and try to reduce the over analysis and complicated stuff that invariably ensues. At least I try to, anyway.
One of the mantras I evangelize to my teams is “Start with what’s right, not with what’s available.” I’m sure their sick of hearing me say it. I admit it’s cliché, but it’s truth. My point in preaching this is to push them to stop, take a big fat deep breath, and bring there awareness up to broader level. In the case of test planning, it’s absolutely critical that you define your test scope based on what you should be testing, not just what’s available to be tested. For example, one of the areas that gets skipped over for some software teams is performance testing. They may not have the tools or expertise to pull off proper load testing so they don’t even consider writing up that test plan. They just focus on what then can cover in the moment and then hope that is good enough. Wrong…!
That’s lame.
I want to know what the RIGHT things to test are, regardless if I have tools or know-how or whatever. I want to make sure I’ve got the best damn map of the land I can get. THEN, and only then, do I start digging into the logistics of execution. That fact that I may not presently have a vehicle to get me from point A to point B does not mean that I’m stuck. It’s means I have some tactical logistics to figure out, and that’s an entirely different problem to solve. Which, likely, has a very simple answer. Like maybe I’ll just ask to borrow my mom’s car? 😉
