Quality is something that has been in my veins for ages already. Although many around me might expect so, I cannot claim I was born with it. I can clearly recall my father rebuking me because of my sloppiness. Maybe that was just adolescent matters, who knows; long hair, careless attitude. Or maybe my father had never learned to just admit I was doing alright. Memory is selective and often not good in chronology. Nevertheless I dare to say I am good at quality, or at least I am into quality.
Why? Because I don't want to redo a job; economical; ecological… Because I want to be able to trust on the outcome of any endeavor. And not in the least: I want others to trust on me. And indeed, I don't like to be distrusted. Feels to me like, … like, … like failing my father's expectations probably.
Meanwhile you might wonder: where is he heading? Well, in our business quality is typically something we all want to deliver, or at least are expected to deliver. And frankly speaking: at the end of the day, that's what we get paid for by our customers.
Upstream!
Last week I picked up reading the book I had started a year ago, just released at that time: How We Test Software at Microsoft. Not sure where I had stopped reading, I was browsing through the table of contents, as I often do. Just to see what 'statement' would trigger me. I halted at chapter 16, Building the Future. Or more precise at the section called The Need for Forward Thinking. Right in the bull's eye! Quality 'all over the place'.
Page 389:
"Most software used today is too complex, too big, and too expensive to improve quality from testing alone"
Page 391:
"If you want to get a high quality product out of test, you have to put a high quality product into test" – quoting Watts Humphrey
Or in other words:
"If quality is not at the forefront of engineering processes, it is impossible to reach acceptable levels of quality in the end"
So how to deliver quality? How to improve quality? By driving quality upstream.
As often: once I start reading I don't stop and jump from one book to the other. So one more for the road from Steven McConnell's much appraised CODE Complete.
Page 24:
"If you start the process with designs for a Pontiac Aztek, you can test it all you want to, and it will never turn into a Rolls-Royce. You might build the best possible Aztek, but if you want a Roll-Royce, you have to plan from the beginning to build one."
Upstream! And what's 'to be found' upstream? Right, Requirements Specifications or Specs. In the next couple of blog posts I want to shed my light on this topic. On How I Reviewed Specs @ Microsoft. You're right I liked that title: How We Test Software at Microsoft. Especially the acronym made of it: HWTSAM.
So look out for HIRS@M part 1.
References
- Page, Johnston, Rollison, 2009, How We Test Software at Microsoft, Redmond, WA: Microsoft Press
- McConnell, Steve, 2004, CODE Complete, 2d ed. Redmond, WA: Microsoft Press