Why all the strum und drang you ask? Well, let’s start with a premise I thinking is lurking just under the covers of Rich’s article – that those of us in the business of software testing are not in the business of quality assurance and don’t even know it even though this is the title that we have been given by people who frankly don’t know it either. How does this happen? Well that’s pretty easy, most of us in the business don’t really consider what we are doing in support of software releases and have never considered the implications of this lack of introspection. Let me put it another way, has anyone really stopped and thought about the fact that quality assurance is a process improvement activity and quality control is a testing activity designed to uncover defects and report them? Now take it a step further and ask yourself, what do I and my team do every day - QA or QC?....
So, no big deal right? We’re just testing as fast as we can and we accept the fact that we’ll get blamed for the inevitable bugs found after implementation. Not a problem just part of the job right? Wrong! As Rich points out we are shooting ourselves in the foot, reloading the shotgun and passing it to others – my words not his….There are Implications that flow from how we look at this issue of QA and QC and how it relates to what we perceive ourselves to be doing on a daily basis….
As we look at providing a service to businesses that employ us the question should arise for all of us, what are we trying to accomplish? While I think we can all agree that we want to try to help insure that a quality product is provided to our company customers be they internal or external. I think we run into problems when we try to define everything in terms of testing so that we start to blur the lines between process improvement and execution in an attempt to justify our value proposition. This is a misleading and dangerous practice. We don’t need to do this. We need to embrace the difference between the two practices and help others understand the need for both. Let’s explore this further….
Consider the question of how we can consistently insure a quality software product release as software project professionals. The answer is with standardization. Let me say now that this is just one aspect of the puzzle, see my article on Embracing the Right Practices for another….We should all know by now that quality improves with standardization and repeatable processes. Why? Because as Rich points out they bring a predictive capability to the activity of delivering software and become easier and faster as a result. But this has risks of its own - the magic bullet syndrome just to name one. But, this should not deter us. What should give us pause is a bigger question that I often hear which is ….”But who owns this?” Who owns this vision and championing of practices and standards as a path to improved quality? Is it testing resources, project management, governance? Well, if you think about it, quality is everyone’s to own and embrace. And, the proof is in the putting. The active establishment, adherence and oversight of practice standardization by everyone (not just developers) assures measurable levels of quality which can result in predictive models which allow us to improve over time.
These are all points that Rich made in his article but this needs to be taken a step further. And I’m now going to respectfully disagree with Michael Bolton on this subject. QA needs a hand in influencing the practice of project delivery and not just one aspect of it and this vision needs to have a champion who understands what quality assurance is about. Testers don’t need to get out of the QA business, they need to start getting into that business so that they don’t spend their days drinking from fire hoses! Why? Because most of the problems that cascade down to the testing phase during a given project or software release are issues of poor project practice. Whether it is poor requirements practice, questionable design and development of poor or non-existent project management, these problems arise with shocking regularity . And they are issues of process failures. This is nothing but quality assurance….
We can and should start to revise our perception of testing to embrace a more comprehensive viewpoint. One which acknowledges the need to establish and test processes as a means to reducing risk and improving quality. We need to help PM’s and developers and CTO’s understand the need to normalize processes in order to insure that when we do call in project delivery support we can actually benefit from it. We need to understand and practice the activities of testing requirements using static techniques as well as encouraging the establishment of practice standards like requirements walkthroughs, requirements strategy documentation, effort estimation using work breakdown methods and other process improving practices….
Are we assuring anything or just reviewing. I think it’s a little of both but in the wrong mix. We need to start owning our role in process improvement and help others to respect and encourage it as well. We’re not just testers, we are professionals in project delivery who, amoung other things should be capable of providing testing support as well as support for process improvement…..Bravo Rich for starting this thread of conversation, I wish I'd done it first.....