Wednesday, September 23, 2009
What If Software Quality Got (Lots) Better?
I have been reading various things about testing and the QA role on Agile teams. This question occurred to me the other day as a result, I believe. Just what would we do or how would things be different, in software development, if the overall quality of software increased by a lot? There are a number of aspects to how one could answer this question.
Presumably, relationships with customers would improve significantly and people might be inclined to spend more money on software expecting that they would not be as disappointed in the results. Note that I did say “as disappointed” since others things beyond raw quality would affect a customer’s view of the results. For most, improving “quality” would go beyond defects, but let’s just stick with that now. Let’s assume the results include acceptable usability and coverage of functionality and that what we are concerned with is failures of the software to perform that functionality. I don’t want to get too hung up on a definition of “quality” at this point.
Of course, another question may be by how much would the improvement be that I am thinking of (i.e., what does “lots” mean)? That’s one of the things I’m going to leave up to those who comment on this post. What would the change have to be for you to think it is significant compared to today?
One thing that I would expect to be different would be some change(s) in process. Indeed, such change(s) would likely be required to even get to “lots.” What change(s) would you see occurring to get there are as a consequence of having gotten there?
My next thought was, what would happen to our view of the role of test staff? Would they just be able to do more comprehensive testing (since more software would work correctly at a basic checking/testing level)? Would it mean they could do different testing than required if confidence was lower in potential quality? Or would your definition of “lots” mean so few defects would exist that (at least some portion of) test staff would be moved to some other kind(s) of work either related to quality control or quality assurance or a actual career change/move?
Finally, and this is certainly not anything new to think about, what would we need to make a big enough improvement in quality to call it “lots”? Now there are many things being done today related to quality improvement, but what new thing(s) might have to occur to make a leap to “lots”? Would it be just more diligent practice of what we already know and (try to) do? Or is there something significant in the nature of how we create and check/test software that is needed?
I’d be most interested in what people think.
Subscribe to:
Post Comments (Atom)
Standards in software development are essential to efforts toward improving communication between customer and contractor, reducing software costs throughout the entire life cycle, and improving overall software quality. Today, organizations have a number of viable choices to consider when it comes to applying software quality process improvement methodologies. Three useful options—the V-Model, ISO9000, and Six Sigma—provide different approaches to helping ensure quality in the software development process.
ReplyDeletesoftware quality:
ReplyDeleteIn the late 80s, and early 90s, I visited Germany and discussed the V-model there (and in the UK), was trained as an ISO9000 TickIT auditor, and worked with people from both Motorola and GE (where Six Sigma started and took root). It has been at least 20 years, therefore, since these ideas have been around and I would have to say that, at least for software quality, these three have not had a dramatic impact. The argument I often hear is that this is because people are not doing them right or with correct management leadership. That certainly has been the case in implementations I have seen. But the "programs" initiated by folks looking to pursue one (or more) of these (or the CMM(R)/CMMI(R), or [name several others]), do not seem to have resulted in software quality getting "lots" better.
That organizational impact has occurred isn't in question, but all of these have usually generated more comprehensive process than substantially improved quality. None of them, however, can be blamed for this, per se, in my opinion. I'm just not sure that the problem(s) they envision themselves to be solving are actually the problems we have in software that need to be solved the most.
Perhaps you can say a bit more in detail about the specific things any or all of these things you mention can do to significantly improve the quality of software (at least as I define it above for the sake of this blog post)?