Quality Assurance vs. Software Testers
Is there a difference between a testing group and a quality assurance group? Our department is titled QA, but we seem to be doing testing work. We are testing the product and have become the last line of defense. As a QA department I feel that we should be assuring the quality of the entire development process. Are there any other opinions about this subject?
Peter J. Coviello
Re: Quality Assurance vs. Software Testers
Excellent topic. I think there is a difference between strict quality assurance and quality testing but I think that testing groups are subsumed within quality assurance. It is sometimes hard to say because you will find organizations that have "Content QA" and "Technical QA" and "Production QA" and so on and so forth and they are all different and under different leadership.
To my way of thinking (and this is only opinion): quality assurance should always be looked at as a system - a correlated series of actions and processes. Within this system you have two major processes: software development and software testing. The trick is to correlate the actions and processes of development with those of testing. That is how you can assure (or attempt to assure) quality.
QA, overall, should help further the notion that quality is built into the product from the start (software development) and then make sure that the quality is there in the final build (software testing). In other words, QA should make the quality that was built in visible.
Keep in mind: this is an ideal situation and conflicting personalities as well as business realities will not always allow this to the degree desired. But at least establishing the "global" nature of QA is a step in the right direction for me. It is, as I said elsewhere in these forums, a matter of process improvement as well as product improvement. You want to take a proactive role not only in the testing but the environment in which testing is performed and that environment will to a large degree be determined by the business cycles that dictate development efforts.
Consider that the testing group has two major concerns: designing for testability and designing for usability. I do not see how QA can attempt to further these concerns along without being involved in the development process. In fact, ideally you want to have a testing life cycle that mirrors, to some degree, your development life cycle. This is very much so in the case of automation: developers and project managers need to see that automation testing is a development effort as well.
But part of this, beyond automation testing, is showing that members of quality assurance have some domain knowledge. For example, when I work with internet companies testing Web sites, I like to make sure that I have design and usability issues firmly in mind so that it is realized that my testing duties are not just after-the-fact, but before-the-fact as well. I need that Web site to be built so that it is testable but I also have a concern about usability. (Especially so since usability is not really amenable to automation and is inherently subjective in the absence of glaring problems.)
To sum up (and sorry for the length) I like a centralized QA group, in which there is a definition of what quality means to the organization, that has various subgroups based upon specific areas of concern, such as usability testing, performance testing, automated functional testing, manual testing, etc. Each of these groups are relatively autonomous subtotalities and yet they all follow a common vision and methodology. Keep in mind as well that the overall quality assurance system needs to be flexible and change-tolerant. It should have built-in feedback loops, so to speak, that allow it to correct its own processes if they are found to be in error as well as prevent QA from becoming "totalitarian," for lack of a better word.