"To find how many, how fast, how much and for how long; to assist business w/ related technical and/or business decisions and/or; to support related improvement activities as prioritized by the business."That certainly doesn't mean that all performance testing efforts include every aspect of that mission, but I'm hard pressed to imagine something that I'd call performance testing that includes none of the aspects of that mission. It is also true that I have experienced all manner of secondary missions as part of a performance testing effort (missions related to fail-over, and denial of service attack security, for example). Those combinations, permutations, variations and additions are all where context comes into play.
However; when I was first asked to help out with some functional testing, I quickly realized that I didn't really know what was expected of me, so I asked. As you might imagine, folks looked at me like I'd grown a second head... a green one... with scales and horns. After about the 4th time I asked the question, got a funny look, watched as it became clear I was serious and received some variant of the answer:
"Find bugs"delivered with a tone that clearly communicated the unspoken "Well, duh!" I stopped asking.
It took me nearly a decade to figure out why that answer didn't work for me. It's because "Find bugs" isn't a mission, it's a task. Tasks are just things to accomplish. Tasks make no reference to "why." Tasks don't come with the information necessary to improvise (at least not effectively or reliably) when the task can't be accomplished as assigned. Missions, at least the way *I* learned about them, do all of those things.
To illustrate the difference, let's consider something more commonplace, like say, doing the laundry. "Doing laundry" is a task -- because it's so common, one can infer a lot from being given this task, but that doesn't make it a mission. A laundry related mission might be "Make sure all the clothes we want to pack for vacation are clean and folded before I get back from work today, so we can pack and get on the road before the traffic gets too bad."
See the difference? If your spouse simply sent you a text that said "pls do the laundry" would you think to do vacation clothes first? Would you immediately run to the store to get detergent if you were out so it would be done before the end of their shift at work? Would you drop what you were doing and go straight to a laundromat if the washer were on the blink? I dunno, maybe you would. I wouldn't. I'd be lucky to remember that I'd been asked by the time my spouse got home (I'm not making that up -- ask any of my previous cohabitants!) What if you'd been given the whole mission instead of just the task?
I admit, the distinction I am making is something I learned while I was serving in the Army. Please forgive me if you don't like "military talk"... I spent a lot of years not sharing certain lessons because *I* don't like "military talk," but a couple years back, I decided to get over it because the lessons were just too poignant to keep to myself. This is one of them.
Recognizing that "no amount of planning survives once the first round is fired" the Army has some rules about planning operations that make a whole lot of sense in context (from memory & without military jargon):
- Without a mission, there is no plan
- No mission is complete without:
- An overview of the situation (i.e. context)
- Who, What, When, Where, Why (the rest of the plan is "How")
- The mission of the next higher unit
- The missions of all adjacent units
- The mission of any unit upon which the accomplishment of your mission depends
- It's not a mission until every member of the unit can recite from memory when cold, wet, exhausted, hungry, wounded and pinned down in a foxhole by a sniper with no means to communicate with any other member of the unit.
Now *that* makes sense to me. Believing that "find bugs" is a mission is what leads to testers sitting in their cubes logging comma splices in draft content while everyone else is trying to figure out if the project is worth continuing in the first place, instead of taking the initiative to do something useful like a feature comparison between this product and it's top three market competitors, or scouring consumer reports, social media and forums to find out what the users of competing products are praising or complaining about.
What do those "useful" things have to do with "find bugs"? Absolutely nothing. Do you think it's something that testers could do well? Maybe even better than other people in the company? Which do you think you'd find more valuable if you were the project/product manager or the CEO? Which do you think is more valuable to the business that pays your salary, a detailed listing of comma splices in content that's due to go to the editorial team next week, or an organized competitive analysis?
If you answered "comma splices", please send me an email, so I can notify my entire network that you may be a good candidate for a job as a copy editor, but under no circumstance to hire you as a tester.
"But the truth is that testing does, or at least should, provide business- level value that can be monetized. Here are some examples of how:So, to all you testers I ask: "Do you *really* know your mission, do you have a task posing as a mission, or do you just do what you do because that's what testers do?"
- Testing can be the key to preparing for and passing regulatory audits, thus reducing both preparation costs and risk of having to unexpectedly invest in corrective action to pass a potentially more rigorous reaudit.
- Testing can be a very strong defense against claims of negligence, faulty advertising, and service level agreement (SLA) violations (of course, it can also be a very weak defense if the testing wasn’t done with this in mind), thus reducing the likelihood of legal action being taken against the company and reducing preparation costs should a suit go to court.
- Testing can help prepare support center staff to field questions about changes and known issues in the product prior to release, thus reducing call duration and callbacks while increasing customer satisfaction ratings of support calls immediately following release.
- Testing can provide you with relative quality and stability comparisons from release to release, thus reducing the likelihood of product reviews calling out a downward trend.
- Testing can provide you with necessary information for assessing the relative risk of releasing on schedule versus delaying a release to improve the product, thus allowing you to make an informed decision about which course of action will be less costly overall.
- Testing can provide information about weaknesses in the product, thus enabling you to develop risk mitigation strategies or make other executive-level decisions regarding the product or project.
- Testing can provide start-point data and cross-validation for capacity planning models, thus increasing the accuracy of the models and reducing the likelihood of either overspending or running into unexpected capacity limits.
- Testing can identify candidate builds for pre-release sales demos, along with training materials for sales staff, thus preventing the sales staff from stumbling upon defects and tarnishing the product’s credibility in front of potential buyers."
--
This is one of a series of posts related to various aspects of delivering Business Value throughout the entire product lifecycle for products that are, contain, and/or utilize software. Many posts specifically relate to software testing. To date, other posts in this series include:
--
Scott Barber
Chief Technologist, PerfTestPlus, Inc.
Director, Computer Measurement Group
About.me
Co-Author, Performance Testing Guidance for Web Applications
Author, Web Load Testing for Dummies
Contributing Author, Beautiful Testing, and How To Reduce the Cost of Testing
"If you can see it in your mind...
you will find it in your life."
No comments:
Post a Comment