In a forthright post each month, Robin dispels some truth that you otherwise might not realise with his regular Unconventional blog. In the latest instalment, Robin examines quality assurance weaknesses and how you can tackle these problems head on. Explore more posts in the Unconventional Wisdom series here.
—————————————————————————————————————————–
Like baseball’s antithetical triple threat (“can’t hit, can’t field, can’t run”), software quality assurance suffers a three-pronged “conventional we’s dumb” that dramatically diminishes its effectiveness.
Actually, SQA conventional we’s dumb has several prominent components which people may emphasise differently. Thus, one person will say SQA is “X” while another person says SQA is “Y.” Ironically, each person still feels what they call “SQA” should be resisted or just ignored. We’ll look individually at each of the three ways conventional SQA fails and analyse why it’s ineffective. Then we’ll briefly describe how Proactive SQA™ instead turns it around to produce REAL Value in ways that can turn resisters into advocates.
SQA Is Software Testing
Most of the folks with “QA” in their title whom I encounter consulting, at conferences, and in my seminars come from organizations that equate QA with testing. It’s actually quite a problem because many of the people attending my QA seminars expect them to be on testing. I’ve had to compromise by making testing be half the content.
However, classic QA is different from testing. Testing is the most common form of Quality Control (QC), which examines software products. Classic QA is concerned with the processes producing those products. QC is one, but only one, of those processes. Classic QA makes sure processes such as QC get done, but that doesn’t mean QA does them. If your QA function only does testing, then it’s not doing actual QA. Thus, most organisations are missing the value QA offers beyond testing.
Regardless whether or not called “QA,” testing also experiences its own resistance, though perhaps in some different more passive aggressive ways than classic QA. For example, testing typically isn’t given the time, resources, or clout testers believe are needed in order to do an adequate job. When schedules get squeezed, the even-limited amount of planned testing often is the first thing cut.
Most testing is reactive, coming at the end and focusing largely on what’s been written. Such reactivity is a major reason typical testing frequently fails to catch many of the defects it could and should catch, which along with overestimating the quality of their code causes developers to be sceptical of the need for testing.
Moreover, although testers do not create defects, nonetheless the testers often get blamed for the defects they do find. That along with actual poor defect detection, due in part to inadequate budget and schedule, then get cited as justifying further withholding time, resources, and influence testers feel they need and deserve. Without classic QA, such dysfunctional software processes aren’t recognized or fixed.
In contrast, my Proactive Testing™ applies traditional test techniques along with less-known more powerful special techniques in ways that not only find more defects sooner but also prevent many of the ordinarily-overlooked most important showstopper defects. That turns resisters into advocates (also see here).
SQA as “Traffic Cop”
The second common QA role reflects IEEE Std. 12207’s traditional depiction of QA’s purpose as “provide assurance that work products and processes comply with predefined provisions and plans.” Thus, many QA functions focus on reviewing documents and activities, typically as a “traffic cop” enforcing compliance with rules and procedures that often are not perceived as inherently valuable. It’s easy to see why QA loses whenever executives are asked to choose between a project team’s delivering useful work or spending time jumping through QA’s procedural hoops that don’t really seem to contribute value.
SQA as Busywork Creator
New QA people and functions often don’t really know what they should do. It’s very common for them to start by writing standards and procedures to define how they think various work should be performed to produce desired quality. Such well-intended documents tend to be voluminous, though volume can be harder to see in today’s electronic form than when printed. SQA then acts as traffic cop to enforce compliance with these unwelcome predefined provisions.
Not surprisingly, people tend to read and follow documents in inverse proportion to their size and complexity; and they generally object to being told how to do their jobs and second-guessed, especially by QA folks with possibly questionable relevant knowledge. QA tends to react to resistance by writing additional, even more onerous standards and procedures, which of course also are ignored or resisted. And so it goes until the QA function is put out of its misery or persists as walking dead.
Proactive SQA™ Actually Works
Proactive SQA™ aims to create an environment that helps people produce the quality they want to produce. Those with SQA titles are charged with assuring processes can and do produce needed quality. Assuring means involving those with relevant skills and knowledge to define what to do, how to do it well, and how to confirm it is done and done well– not doing it all themselves unless they in fact have suitable capabilities. A book and online training are being developed. Contact me to discuss your needs and how we can help.
“It isn’t what we don’t know that gives us trouble, it’s what we know that ain’t so.”
– Will Rogers
Welcome to my Unconventional Wisdom blog. Much of conventional wisdom is valid and usefully time-saving. However, too much instead is mistaken and misleadingly blindly accepted as truth, what I call “conventional we’s dumb”. Each month, I’ll share some alternative possibly unconventional ideas and perspectives I hope you’ll find wise and helpful.
