My featured article in the new issue of Better Software Magazine is now live as a featured blog on Stickyminds.com! Check it out and let me know what you think: http://ow.ly/ojGv30gbc43
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? 😉
How many times has QA played the medic role at the end of a software release cycle?
Gaining great advantages due to its adaptivity, guerrilla warfare tactics closely resemble many of the same methods used by the QA organizations I’ve been involved with in that:
This has been my experience thus far on my 19+ year march in QA land. Though I’ve been part of many successful and innovative teams I have much to learn and will enjoy being a student the rest of my life.
Plus, it’s a bonus for me that students tend to get away with being more the rebellious sort, which suits me just fine.
Guerrilla QA seemed to encapsulate my experience very efficiently and conjures a less-than-center attitude.
I believe that every QA team, no matter what discipline or technology, have gone through or are currently going through some level of challenges that force them into guerrilla tactics.
Assume change, value adaptability and precision with the highest regard, reward your teams for self-sufficiency and creativity, and never ever assume you have found all the gotchas.