Who's In Charge Of Your Metrics? (January 2010)
Who's in Charge - You or Your Metrics?
We recently interviewed testing expert Michael Bolton to get his thoughts on the latest trends in software quality. One of the many things he touched upon was the issue of useless data - from the perspective of the customer anyway. Here's what he wrote in Part I of the interview:
"Some people enslave numbers. They make numbers work too hard, and too often. I’ve seen organizations collect piles of data about defect escape ratios and defect detection percentages. They hire market research firms and calculate the ratio of happy customers to unhappy customers. But the aggregated data doesn’t tell you anything specific on how to make things better for the unhappy customers.
When you enslave numbers, they eventually rise up, revolt, and enslave you! These organizations spend so much time collecting the data and talking about it and justifying it and trying to duck blame that they don’t seem to have time to do anything about the actual problems, which generally fall into two categories. One: the organizations are trying to do more work than they can handle with the approaches they’re using. Two: they’re not listening to people that matter—neither to their customers, nor to their own front-line staff, many of whom are closest to the customers.
VPs could learn a ton of useful business information from their own customer service and technical support reps, and they could learn plenty about the project by listening to their programmers and their testers. Product and project knowledge gets mediated by middle managers and numbers; it turns from information into data. When your car is about to go off a cliff, it’s a weird time to be thinking about gas mileage and drag coefficients; better to take the right control action — look out the window and steer or use the brake until you’re back on course. Once you’re back to being productive, then you can start thinking about optimizing, if you think you need to."
There's a ton of valuable information for VPs and upper management of software companies, so if you're interested, be sure to check out Part II and Part III of the interview.
Deep Thoughts on Software
"If the quantum view of the world is correct, does it mean that testers create bugs by observing them?" - Anonymous Found on "The Old Joel on Software Forum"
Revolutionize Your QA: A Free eBook from James Whittaker
As an author, professor and Testing Evangelist at Google, James Whittaker has learned a thing or two about effective testing procedures. He shares a few of these insights in his free eBook titled "Revolutionize Your QA." With advice for testers, managers and executives, this eBook can be the first step to improving your QA practices. Here's a sneak preview of what's covered:
- The key difference between experience code and infrastructure code
- The basics of testing tours - a new and fun way to approach QA
- Why testers should play a greater role in development
- Why it is that testing sometimes sucks
Check out the free eBook now. Ready to start testing your latest application? Contact one of our QA gurus, or visit our pricing page for more information on how to get started.
Why Can't We Be Friends? (testers and developers)
uTester Yvette Francino addressed this topic in her latest guest blog post, titled "Defective Baby: Six Ways for More Effective Communication with Developers." It's a lighthearted take on an often contentious situation, and well worth the read. Here are three of her six pieces of advice for testers:
- Don’t report the same bug multiple times: Know the code and application well enough to be able to determine if different scenarios are uncovering the same bug. If you suspect that one fix will address multiple symptoms, report the symptoms as a single bug, rather than multiple bugs.
- Don’t inflate the seriousness of the problem: It’s common for a tester to be proud of finding a serious bug. However, until the specifics are known it’s better to simply state the facts and not jump to conclusions that haven’t been proven. Avoid dramatics.
- Find some positive things to report: Though it’s important to report on the bugs and issues, the developers have worked hard at creating a product. Take some time to let them know of the tests that passed and appreciate the positive findings.
Bug of the Month
Oh Crap! Bug Causes Sewage Spill According to the Santa Maria Times, a software bug prevented about 17,000 gallons of "effluent" from being treated with the necessary amounts of chlorine, prompting local health officials to caution beach-goers against visiting that particular two-mile stretch of ocean.
