Slashdot Mirror
QA != Testing
gManZboy writes "Original author of Make and IBM Researcher, Stu Feldman has written an overview of what should be (but is sadly perhaps not) familiar ground to many Slashdotters: Quality Assurance. He argues that QA is not equivalent to 'testing', and also addresses the oft-experienced (apparent) conflict between QA-advocates and 'buisiness goals.'"
Quality assurance is a process that runs through the entire project, testing is a component of that process.
When building software there is a tendency to lump quality assurance and testing together precipitously at the end of a project. The distinction that is made in this article is an important one, true quality and successful projects are obtained by having quality assurance as a project long process. Then you have quality assurance during requirements, design, development and yes even testing.
testing can only prove the presence of an error, not its absence.
On another note, QA and QM methodes may sound incredibly dull and based upon "duh - how else should I do this, dumbass?", but are in fact highly sophisticated.
Not because they are not readical new, but because they are radically in their consistency. Think of something, and its error and faults, then of their causes, and their effects and impacts. Prefferably add fault probabilities, too. Then start over again.
It is constant feedback throughout the whole design process that is most important.
Powerful is he who overpowers his temptations.
IME what you normally get is :
a) Knowledgeable staff on average salary + unrealistic deadlines, somehow managing to motivate themselves to do a good job
and then
b) Average management using the abilities of said knowledgeable staff, getting all the praise for the projects somehow coming in on time, and getting a huge pay rise for their "efforts".
I think I may be getting just a little bitter and twisted about my career prospects.
"When the QA process starts,"
The QA process should start right at the beginning of the project, when you are developing the requirements (i.e. before the specification is created).
You are not using QA at your company. If you were, then you would have a proper, detailed specification and list of requirements, which benefits everyone (the customer, the designers, the testers - everyone).
People should not be afraid of their governments - Governments should be afraid of their people.
There are two parts to quality. The second part of the IEEE definition is "The degree to which a system, component, or process meets customer or user needs or expectations".
Although Feldman leaves out the second part (I believe it comes from another standard), he alludes to its importance in his discussion of how stringent QA must be, indicating that software for different purposes will have different quality requirements according to the needs of its users.
Quality Assurance is not possible in the absence of requirements and specifications. Although we (the company I work for) often receive requirements with minimal detail, we have addressed the quality problem by writing a (relatively) detailed specification up front, and presenting it to the customer. Effectively we're saying "this is what you're going to get for your money, okay?". It's just prudent practice, but it gives us a goal and a way to achieve quality (by both definitions).
You can find more on the combining the technical and business approaches to quality in my essay The Quality Gap.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
In fact, I've seen "Knowledgeable_Staff_On_Good_Salary + No_Deadlines" produce the worst kind of quality possible -- no working product at all.
I will agree that ignorant staff will degrade or kill quality, poor pay doesn't help, but tight deadlines can cut either way.
The real key to quality products of any type is:
1) deciding what you want to build, and deciding exactly (i.e., good specs);
2) deciding how you want to build it, and deciding exactly (i.e., good architecture);
3) ensuring that these two elements are matched to the capabilities of your team and budget (e.g., don't try to cram all the R3 featuers into R1); and
4) to create feeedback loops throughout the process to check that you are doing what you think you are doing (e.g., peer code review, pair programming, data acquisition and recording in manufacturing processes). Testing should be merely a "double check".
With these steps, and especially ensuring that the demands are only a bit beyond the capabilities of the team, even a basically competent team on modest pay can produce great things in short times.
Without adequate planning, deadlines and QA, the most brilliant, high-paid teams with no deadlines will produce crap, if they produce anything at all. As Sun Tsu said: 'every battle is won before it's fought'.