QA != Testing 342
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.'"
To sum it up (Score:5, Informative)
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.
Good QA (Score:3, Informative)
It continues constantly until the Project Post Mortem gets reviewed.
QA should be involved in every activity regarding the projet in between. (including reviewing the requirements ellicitation process)
Happily, when I worked in QA (for a telecoms test equipment manufacturer) that was how we did things. We, in QA, were responsible to the QA Director, and the Managing Director, and nobody else - that gets engineering in touch with you early and ofen...
testing? (Score:4, Informative)
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.
Re:Quality? (Score:3, Informative)
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.
Re:Requirements? (Score:4, Informative)
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).
Re:Requirements? (Score:5, Informative)
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 [crypt.co.za].
Re:Requirements? (Score:3, Informative)
Neither necessary nor sufficient (Score:4, Informative)
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'.
Re:Quality != Good (Score:3, Informative)
A specific example; the standard requires that you have a process in place to ensure that the copies of company documentation in use are up to date and valid.
The fact that someone at your company wrote in their company standard for that requirement that they would do this by only having one copy (and weren't intelligent enough to make that an ELECTRONIC shared copy) is very far from being a problem of the standard.
The company could just as easily have pointed to a secretary and stated "Documents are to be taken from XYZ, where the up to date version will be available". Combine this with a procedure for document release that includes "archive old copy, replace in XYZ with new version" and you are done. Make XYZ a network drive which is backed up properly, and you've also filled the document protection and retention requirement.
ISO9001 is only as hard as you make it for yourself. In some cases, you can fulfill the requirement by stating that you have looked at, and are not addressing, that requirement.
Re:Quality != Good (Score:3, Informative)
I think there is a requirement that you review your processes regularly; but having a meeting where the PHB says "we have good processes? Right?" and every drone nods dutifully is fine for that requirement.
ISO9001 is designed to assure outside entities (customers, investors) that you have taken steps to do things in a way that mitigates against cockups, corruption (rogue projects that do not add value but leech resources) and terminally bad output.
It is NOT the purpose of the standard to give the company efficient processes (it is assumed that you will begin from something that does what you need, and add quality to it, not bork your processes totally because thats the "quality" way to do it)
Unfortunately, being an exernally visible marker, ISO9001 is largely treated as a marketting tool by the PHBs of the world.
Re:Requirements? (Score:3, Informative)
Re:Proof it's a good thing for a company (Score:3, Informative)
And when they started out after WWII their industries were noted for exactly the opposite: mostly cheap stamped metal toys - the first. "Made in Japan" was a synonym for shoddy. (Not their fault particularly - it was the first profitable thing they could do with what was left of their infrastructure after the war.)
They embarked on a long-term process of upgrading, with great attention to the things where they were behind. Quality was their first lack, achieving it became one of their very first targets, and the means to achieve and maintain it became core to their industries.
In the car example they eve[n] build the cars on US soil with these methods, so, it is something we can do and doesn't break ou[r] backs.
They did it with union workers, too. A friend of mine who was a labor union officer put it this way: "The workers give you what you ask for. If you ask for quantity you get quantity. If you ask for quality you get quality. And if you ask for trouble you get trouble." (Implication being that the Japanese had asked for quality while the US companies had been asking for quantity and trouble. B-) )
Key to the rise of Japanese industry were two US figures: Demming and McCarthy.
Demming wrote a book that laid out management techniques for achieving quality, quantity, and labor peace. Most of it worked by having management empower the front-line workers and pay attention to their input: These workers have the direct experience with the company's processes and problems, customers and suppliers, so they're your nerve endings. They are NOT dumb, and there are far more of them than management, so they're more potential sources of good ideas. Management's job is not to come up with all the ideas and push them top-down on the workers, but to enable the workers to get the work done, aid them in implementing those good ideas they generate, and reward and encourage behavior that promotes the company's goals.
This book was introducted to Japan during the reconstruction, and its message was easily grasped. The people in Japanese industry, from management through line workers, became almost cult followers of Demming. His book circulated widely. They implemented his ideas as their core business practices, with excelent results.
But the US was in the height of the Red Scare (also known as the McCarthy era.) The black-listers and witch-hunters could destroy vitrually anyone they turned their eye to. And listening to workers sounded too much like the ideology of the communists, socialists, and "sieze the means of production" radical labor unionists.
Though many of the particular claims McCarthy himself made turned out to be true (though it took the opening of the KGB archives after the fall of the Soviet Union to show it), his hearings and the activities of his followers and wanna-bes created a terrorist-style pressure on executives. Anything that even hinted at Communism or Socialism became taboo. Both Demming's work and any communication from labor toward management (outside formal collective barganing sessions) fell into disfavor among US industry. Quality suffered as a result.
The turnaround for US industry began when Japan's auto industry achieved, first a price, then also a quality advantage over that of the US, displacing its products in the US market.
This served as a wakeup call to management, which began an expensive, painful, and lengthly process of examining and repairing its own house. (It was triply painful because it occurred simultaneously with an energy crisis resulting from a mideast oil embargo and civil unrest as the boomers were drafted into the Vietnam engagement.)