Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

QA != Testing

timothy posted more than 9 years ago | from the spelled-differently dept.

Bug 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.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


QA (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#11822189)

The major failing of Linux, the dearth of professional QA.

Re:QA (0)

Anonymous Coward | more than 9 years ago | (#11822201)

The real problem for linux re; QA is that its now TOO LATE to get decent QA (you need it before coding begins)

Riiiiiigggghhhhhhttttt (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#11822210)

Let me guess. You see Windows as being top noth.

Re:Riiiiiigggghhhhhhttttt (1, Insightful)

Anonymous Coward | more than 9 years ago | (#11822244)

No, I'm saying that if Linux were to have a QA strategy before the next great project begins, then the product has the potential to be even better.

Why on this damn website will any criticism, no matter how true/justified be taken as the most vile bile ever spewed?

And why is any response to criticism met by words to the effect of "And, of course, YOU think that WINBLOW$ is better? Well let me tell you something, you . . . "?

Where to add QA to linux (1, Interesting)

millahtime (710421) | more than 9 years ago | (#11822319)

There are 2 places to add QA to linux.

1) The first is really just a patch, but to QA the current code base and the new incoming code.

2) To add QA to the process of generating the code so that it is controlled enough the output is garunteded.

This would take quite a long time to get in place but in the end it would produce a much better and cleaner code base. This also would give ti respect from more professional organizations.

Re:QA (0)

Anonymous Coward | more than 9 years ago | (#11822339)

You sir are abso-fucking-lutley correct.

Linux QA comes after the software is released.

It has much better QA then even the professionals but it makes the software look bad when your userbase is doing QA qithout their express knowledge.

This is the downfall of Linux. After software is released it is supposed to be polished, with linux the detailing doesn't start until after release.

Re:QA (1)

marcello_dl (667940) | more than 9 years ago | (#11822440)

QA is made indeed by the users, the policy of "release early" is all about that indeed, but I wouldn't generalize your statement on the entire OSS movement.

Counterexamples: Debian has a community-driven QA system [slashdot.org] and takes care that its (long awaited) releases are bug-free. The same can't be said about OSs from Microsoft (what are Service packs made of?) or even Apple (users of OSX prior to 10.2 should remember about that :) ).

Linux has just got the other half (1)

dallaylaen (756739) | more than 9 years ago | (#11822459)

Linux has the other half -- while it lacks a pre-defined QA team, the programmers are not angry with testers.

The core GNU/Linux programs are usually (re)?implementing some well-designed arch/protocol/format/whatever.

Also the docs are much better (although often require googling) -- no "competitors" to learn your secret tricks and hidden APIs.

And BTW an encountered bug is usually sQuAshed, not workarounded -- 'cause geeks and major distros will just recompile everything broken by the remedy.

Some more OSS QA starts when a freshmeater abandons his poorly designed project and joins a better one.

And yes, best open-source progs have been heavily sponsored to become as consistent as they are. But I don't see it as a "major failing"...

QA (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11822191)

Twenty minutes later, each of the men awoke in a cell. An antidote to the truth drug had been given to each of them before David had left and locked their cell. Mac's powerful body jerked as his consciousness returned suddenly. The world spun crazily around his for a second, the cold over head lights making his head hurt. He choked and gagged almost vomiting for a moment. As the world slowed and the light became barable. He noticed the clear bell shaped plastic tube that now held his huge swollen cock captive. It surged and sucked pumping and teasing his very aroused organ.

Long thin dribbles of clear pre cum ran from his cock into the clear hose, it was already wet. And Mac realized that he must had orgasmed once already! The machine was used to collect sperm samples from the animorph specimens. He knew he'd seen it begin used by Norcott, his hands were bound tightly behind his back. Mac twisted and strained, his huge powerful arms bulging against his bonds. His wrist's ached an blood dripped down his hands. But the plastic restraints slowly began to stretch! A second load of hot thick man milk had sprayed down the hose, an a third was building. Before he at last was able to pull his hands out of the restraints. With his hands free he instantly began scratching..as he itched all over! Unstrapping the milker from his groin, he pulled the vacum tube off his throbbing member. His big low swinging testicles tingled, as his third load shot from his freed cock.

"What the shit?" Mac grunted as his cock began dribbling pre cum again almost at once. Powerful lusts flooded through his body and desire for release overcame him. Mac felt a warmth spreading from his guts, as he jacked his long hard cock quickly. Memories flooded back to him then as his third orgasm slattered cum on the cell wall. Rothman dildoing his ass, pumping the badger mans cum into him! "Rothman!" He snarled savagely. Glancing around quickly he idenified where he was. Holding cell block J5... of course Rothman couldn't move them far by himself! These holding cell's had a weakness...and the big security chief knew it...very well!

Mac Blocker didn't have time for what was happening to him, but he couldn't stop it either. He needed to escape, but his orgasm was beginning to build again. He was security chief of this damned place, did Rothman really think he could stop him by locking him up.

He looked down, something was happening to his cock, it was changing shape. His balls had already become huge and hung low and had a fuzzy grey covering of fur. Fur was growing all over his body, he watched, half fascinated and half horrified as his red human hair began to disappear beneath the tan and grey fur on his chest and belly. He rubbed and scratched his abdomen. He was growing carpet of badger fur on his chest and felt it growing on his back. He felt his face and realized that it was happening there too. If he could have seen himself in a mirror, he would see the beginnings of the distinctive black and white stripes on his face and his nose and lips beginning to darken. The backs of his arms were growing dark with fur.

He was brought out of his musings about his growing furriness by his aching cock. He watched it finish changing into the proper shape for a badger, not that he had ever noticed an animal's cock before, but he guessed this was the right shape, given what was happening. His cock was growing huge and it demanded attention. His mind became simpler in thought as he began to stroke himself with a clawed hand that rivaled that of the ursine animorphs. Lustfully, he began to lick and suck on his own cock. Inside of his mind 'Mac the Man', the extremely heterosexual human male, was disgusted by what was happening, but 'Blocker the Badger' was in complete bliss. He was reliving his swollen balls of he last vestiges of Mac's human genetics. Blocker the Badger kneaded and fondled his balls with one growing clawed hand and pumped the elongated shaft with the other. If Mac had, had a cell mate, male or female, he would be releasing his load into whichever hole was first presented. It's what made the milking machines so easy to use; the animorph would bliss out and provide as much semen as the beast could pump out before it was sated. The beast didn't care as long as its sexual needs were fulfilled. Mac the Man went into a sort of hypnotic state as the Blocker the Badger gained complete control. The badger licked up and sucked down the last drops of human seed and was coaxing out the first badger-man sperm.

By the time Mac Blocker the badger-man had regained the balance in his mind between beast and man and could think clearly again, he was completely transformed.

Mac didn't like being changed against his will, but he had to admit, he had the best of both worlds now. Mack had been a stocky man since he was in high school and was on the wrestling team. His time in the army had just increased his muscular, stocky physique. Now, he noted that he was much more powerful than he had been before. That bastard Rothman had only done him a favor. He heard Billy and George in the other rooms. Though the rooms were generally sound proof to the human ear, his new ears were picking up their grunts and moans and garbled words that sounded like, "Oh, fuck, yeah!" and "God that's good!". He guessed the milking machines were providing them with the same kind of distraction his auto-fellatio had provided for him and he knew that the machine would still be attached and he'd still be blissfully shooting out loads if he hadn't acted so quickly.

In retrospect, sucking one's own cock wasn't that bad and he had rather enjoyed it. He had bragged to his buddies that if he could do such a thing, he'd never leave the house. Well, he found now that, that wasn't quite true. He wanted out of this cell more than he wanted to suck his cock again, though at the thought of doing it, his huge badger cock gave a jerk and his balls tingled in anticipation.

He'd fix Rothman, but first he had to get out of here and free his partners. George's new bulk and raw power would be of great use and Billy's new agility and wiry strength could help them all get out of here. The problem now was this: Mac the Man knew that his codes had been locked out by now, but he had a secret code he hadn't bothered telling anyone about that could free him he just needed to get to the keypad. Upon examining Blocker the Badger's hands, he realized it would be awhile before he was dexterous enough with the clawed hands to use them without hitting the wrong keys. He knew that if he were to break the reinforced glass, which he could easily do, he might reach the keypad by the door. But if he hit the wrong sequence, it would activate alarms and flood his cell with a neurotoxin that would kill him in seconds. The antechamber just before the holding cell would activate the air-tight seals against the gas and the solid steel doors would be locked tight as a bank vault.

There wasn't any immunity to that and it didn't matter how strong you were. He'd seen the same toxin used on test subjects to insure it's effectiveness on mammalian, reptilian and avian life. He'd also seen it used on animorphs and it was quite effective. Basic biology didn't change, just because you were a hybrid of two mammals. The neurotransmitters still required certain chemicals to function. These cells weren't the local county jail; they were designed to contain biohazard level life-forms, so Mac Blocker had to be careful.

Everything would be just fine, if he could just see to punch the keypad and if he could reach the keypad. There were no reflective surfaces in the antechamber and none available in the cell that he could squeeze through the 8"x8" window after he'd broken out the reinforced glass. Even the milker had been automatically retracted to a place he couldn't get to it when he'd removed if from his groin.

Mac was sure he could do it; he just needed to figure out how. He sat and calmed himself, he had a plan. As he thought it through, he heard George and Billy in the throes of their final orgasm. He heard the milkers shut off and then he heard loud snoring. It was George was most certainly, the man had been his friend for years and he'd heard him snore many times when he'd fall asleep in Mac's recliner after dinner. He'd given Mac a job and stepped aside when this promotion came up so that Mac could take it. George said he was old, he had enough pay and he didn't need the headache. That was partly true, George had, had heart bypass surgery and he probably couldn't have taken the stress. George had been like a father to him and he was angered that Rothman had punished him, punished them, buy making them experiments for the army's use. It was Mac's fault that George and Billy too, were in this mess. He was just too ambitious. If it weren't for him talking them into selling out to Transgene, they'd both be home now, same as they had always been and not on their way to a breeding program.

Mac put aside all his anger and concern, mostly for George, and concentrated on the task ahead; he realized the incredible risk he was about to take.

Re:QA (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11822431)

What. The. Fuck.

Requirements? (3, Interesting)

bigtallmofo (695287) | more than 9 years ago | (#11822197)

From TFA:

QA is described as making sure a project is "measurably meeting expectations and conforming to requirements"

At my job, requirements are often one-sentence requests with no needed detail whatsoever. If it then doesn't go to a business analyst in the IT department, that's what the programmers work from. When the QA process starts, it makes it easy to say that you've complied with all details of the requirements.

Re:Requirements? (5, Insightful)

PepeGSay (847429) | more than 9 years ago | (#11822216)

This is a sign that there was no quality assurance during the requirement gathering. Which probably means you were not actually starting your "QA process" , but were actually starting "testing".

Re:Requirements? (1)

chimpo13 (471212) | more than 9 years ago | (#11822218)

QA at a few of my last jobs were: "If we don't get complaints, you're doing great". Which is probably why one has almost gone under for years. A few months of walking up and thinking, "Well, there's cars in the parking lot" and "alright, the doors not padlocked shut". Any day now, we'd say, but I'm glad they're still in business even if I don't work for them.

Re:Requirements? (3, Informative)

ColdGrits (204506) | more than 9 years ago | (#11822257)

"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).

Re:Requirements? (-1)

Anonymous Coward | more than 9 years ago | (#11822427)

lol "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)." only in a dream world :(

Re:Requirements? (4, Informative)

Twylite (234238) | more than 9 years ago | (#11822299)

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? (2, Insightful)

Unnngh! (731758) | more than 9 years ago | (#11822384)

I've found a number of ways to work around a lack of requirements. A good specification is one, but if you are so inclined a static prototype can often achieve as much if not more from the customer's perspective. A couple hours of use case gathering with management and the customer can also achieve amazing results, without the need for lengthy documentation or weeks and months of back-and-forth.

Then you just have to convince everyone to stick to what they've agreed to when they ask you to change everything halfway through coding!

Re:Requirements? (1)

Twylite (234238) | more than 9 years ago | (#11822516)

I've found prototypes are more useful in a JAD context. They're at least as effective as use cases at gathering requirements for applications that are mostly interactive.

Currently I use specifications because we're working with non-interactive software than integrates with a number of other systems, and needs its processing behaviour to be very precisely understood.

That's a fairly specialised environment, but for more general contexts I have found use cases to be particularly effective. Of course, I could a use case plus the documentation you need to understand it as part of a requirements specification ;)

Re:Requirements? (2, Informative)

drgonzo59 (747139) | more than 9 years ago | (#11822322)

I worked for a company that designed a major CAD product and the code was millions and millions of lines. Anyway, there was a scripting language built into it and a mode to run the application in batch mode. So all the user input could be scripted. Then we had a hefty team of QA/QC people who were in charge of mentaining a ton of testcases that consisted of input, the some script that operated on it and an ouput to compare the result with. All the testcases took days or even weeks to run, initially it worked fairly well. When new features were added to the program it was a pain in the arse to go and change all those testcases that now were supposed to look different. The problem was even worse because they had co-ops(interns) doing it, who had no experience and had no idea what was going on. After years, many testcases became un-usable after so many changes and features added and it the QA became a mess. The release cycles got longer and it was harder and harder to keep track of bugs. I don't know what happened then because I left just about then...

Re:Requirements? (5, Interesting)

Eric Giguere (42863) | more than 9 years ago | (#11822362)

For good reading on the design/requirements problem, I recommend Alan Cooper's The Inmates Are Running the Asylum. Talks a lot about how products can meet all their requirements and yet still fail because the requirements weren't right to begin with.

Re:Requirements? (1)

dpilot (134227) | more than 9 years ago | (#11822423)

On the other hand, I've seen cases where so much time and effort and especially politicking goes into the requirments document, that by the time it gets delivered to software design and coding, the whole request is obsolete.

Code is delivered that meets the requirements document, but does nothing whatsoever for the users.

Re:Requirements? (1, Funny)

Flyboy Connor (741764) | more than 9 years ago | (#11822447)

At my job, requirements are often one-sentence requests with no needed detail whatsoever.

Reminds me of my first programming job. For five years I worked for a boss, who only drew screenshots and then said: "Program this".

Quality? (5, Insightful)

ceeam (39911) | more than 9 years ago | (#11822198)

IME, Quality = Knowledgeable_Staff_On_Good_Salary + No_Deadlines. Unfortunately, this formula larglely is not compatible with business world. So, in the mean time, customers should be grateful if software has been _somehow_ tested and mostly works.

Re:Quality? (3, Insightful)

z80x86 (864095) | more than 9 years ago | (#11822231)

I do not know if I agree with that strict formula you proposed. I have always felt that approaching software with a clear plan for its future is the best way to ensure a quality final product. While systems may often appear to be growing organically, its evolution must be controlled so that it does not deviate far from what was originally expected of it.

Re:Quality? (5, Insightful)

patrixx (30389) | more than 9 years ago | (#11822236)

Funny, I would say Quality = Knowledgeable_Staff_On_Good_Salary + Deadlines

BOVE'S THEOREM: The remaining work to finish in order to reach your goal increases as the deadline approaches.

PARKINSON'S LAW: Work expands to fill the time available for its completion.

Re:Quality? (1)

mbrod (19122) | more than 9 years ago | (#11822237)

I agree but I would say Knowledgeable_Staff_On_Good_Salary at least has to have say and a good amount of pull/power in the deadline.


Quality = Knowledgeable_Staff_On_Good_Salary + Knowledgeable_Staff_On_Good_Salary_Influenced_Dead lines

No matter how hard some business weanie up the food chain wishes not to pay people good, the hard fact is in QA you have to pay people enough to care what they are doing. QA work can be extremely boring and tedious. To get this done right the people need to be compensated and paid enough to give a rat's a**.

Re:Quality? (2, Insightful)

the grace of R'hllor (530051) | more than 9 years ago | (#11822243)

Deadlines focus the development effort. Without the need to ever finish anything, you'll never finish anything because there's *always* something you can add or improve.

Milestones keep the development on track, and deadlines are used in projectplanning to determine an end state for the development project.

Besides all this, lots'o'time doesn't give you quality, necessarily. Look at knowledgable modern artists; all the time in the world, and all they produce is a pile [maximonline.com] of crap [sprynet.com].

Re:Quality? (3, Informative)

thecardinal (854932) | more than 9 years ago | (#11822247)

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.

Re:Quality? (1)

dallaylaen (756739) | more than 9 years ago | (#11822252)

IME, Quality = Knowledgeable_Staff_On_Good_Salary + No_Deadlines.

This would end up designing a spherical horse in vacuum. Or a six-legged elephant... or Emacs. And yes, the result would be bugless -- after infinite time.

The quality consists of even more factors, then QA -- and one of them is limiting features (yet the other is leaving a way for new features to come in -- like it has finally been done with Firefox).

Capability Maturity Model (3, Interesting)

Digital_Quartz (75366) | more than 9 years ago | (#11822275)

An excellent example of how anecdotal evidence can lead you to incorrect conclusions.

The SEI [cmu.edu] was approached by the military a couple decades ago. The military had a problem; when it contracted out software development work, it would sometimes get back what it was looking for, it would sometimes get it on time. Sometimes it was late, sometimes it didn't work, sometimes it did the wrong thing, and sometimes they got nothing at all.

The SEI went about polling a large number of contractors, trying to see what was common amongst the ones who delivered. They found there was actually a very strong correllation between a number of processes and practices and high-quality under-budget software. The result is the Capability Maturity Model [cmu.edu] or CMM for short, which divides companies up into 5 "levels".

The kind of organization you describe is quite definately a "level 1" company, the kind with the highest risk, and the lowest quality. Most companies, even small ones, should strive to follow the practices of at least level 3, as the benefits are quite tangible; no more late projects, and vastly fewer defects.

I mentioned it in another post, but my dad [thedreaming.org] has a good web site [thedreaming.org] that deals with quality issues (IE only, unfortunately). And, if you're looking to improve the quality of your software, his current contract is going to expire soon.

Re:Capability Maturity Model (5, Interesting)

mccalli (323026) | more than 9 years ago | (#11822310)

the SEI was approached by the military a couple decades ago. The military had a problem; when it contracted out software development work, it would sometimes get back what it was looking for, it would sometimes get it on time...The SEI went about polling a large number of contractors, trying to see what was common amongst the ones who delivered. They found there was actually a very strong correllation between a number of processes and practices and high-quality under-budget software. The result is the Capability Maturity Model or CMM for short, which divides companies up into 5 "levels".

Yeah, I use it and am in a certified team. It's vastly overrated, and no substitue at all for people who know what they're doing. It might complement people who know what they're doing, but then such people would have come up with their own valid processes anyway, hence your initial correlation.

And it's hardly helped the US military come in on time and under-budget, now has it?

...but my dad has a good web site that deals with quality issues (IE only, unfortunately).



Re:Capability Maturity Model (2, Insightful)

StormReaver (59959) | more than 9 years ago | (#11822404)

"I mentioned it in another post, but my dad has a good web site that deals with quality issues (IE only, unfortunately)."

I'm sure the irony of that statement is not lost on anyone. A site, giving advice on good quality, is itself a quality disaster. You'll understand if I don't take his credentials to heart.

Re:Capability Maturity Model (5, Insightful)

glew (412946) | more than 9 years ago | (#11822464)

That sounds very good. In theory.

Having worked in a CMM 3 company for a couple years, my opinions of the thing are quite different: CMM, and processes in general, are a tool that managers use to offload their work on the engineers.

We used to spend vast amounts of time peer reviewing all sorts of useless documents, making estimates for project planning, and so on, additionally to the architecture and coding work.

This didn't do anything at all for quality. Deadlines slipped like always (often more, because of the time lost to irrelevant stuff). Spec documents were just as Ground-Control-To-Major-Tom-like as usual.

It did, however, give the managers the warm fuzzy feeling that overcomes control freaks everywhere when they're sure they can track, number, file and index everything that goes on around them. Without having to do any actual work. Without even knowing the first thing about the product we were making (without CMM, a prerequisite for anyone attempting to write any sort of project plan).

One of our line managers admitted all of this quite openly, one of his favourite sayings was "Since we have processes, I can go home at four every day". We didn't. We got to stay till 8.

In my experience, CMM should be avoided like the plague. It's complete and utter waste of time, and encourages empty hierarchies.

Re:Capability Maturity Model (1)

slashdork.org (862424) | more than 9 years ago | (#11822513)

First, for those that like small tidbits of info, useless for anything but Jeopardy, CMM is old and has been replaced with CMMI [Capability Maturity Model Integration]. This was done mostly to incorporate projects involving things other than systems and their hardware, things like software. CMMI also addressed "legacy" systems, old systems that the old people were used to. CMM didn't account for legacy systems.
Second, for those who care for my opinion, though I've only worked shortly with CMMI, much of the processes seem inhibitive. This is just an opinion of course. However, to me it seems that this just slaps on another layer of bureaucracy to certain government companies. Sure, this model ensures shit companies do their job, but to a solid company, enforcing this standard only slows things down. Oh yeah, and it's boring as hell to learn all about it.
So if you're bored and you want to sleep, here ya go. CMMI Intro [awprofessional.com]

Re:Quality? (1)

Chris Kamel (813292) | more than 9 years ago | (#11822304)

It should be Quality = Knowledgeable_Staff_On_Good_Salary + Reasonable_Deadlines No deadlines is total chaos, reasonable deadline are another thing.
Software project estimation is already well established, and you should be able to provide a pretty accurate estimate given some time for investigation.
The only projects that should have no deadlines are research projects, when you're pushing the computer science limitations. Which is rarely the case.

Neither necessary nor sufficient (3, Informative)

Presence1 (524732) | more than 9 years ago | (#11822364)

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'.

QA != Testing (0)

Anonymous Coward | more than 9 years ago | (#11822204)

QA != Testing

Doh! I had this in high school software development course.

To sum it up (5, Informative)

PepeGSay (847429) | more than 9 years ago | (#11822205)

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.

Good Quality Cuts down or out Testing (3, Insightful)

millahtime (710421) | more than 9 years ago | (#11822263)

If you have good quality you can cut down or completely out testing. Think of it like a math equation. Y = f(x). Y is the output and f(x) is the input. If you control the inputs with no variation then the output will always be the same so no need to test it. Honda has done this with engines. They save money because they don't test every engine. Yet, all their engines always work.

Re:Good Quality Cuts down or out Testing (1)

dunerunner (864101) | more than 9 years ago | (#11822373)

You're comparing apples to oranges (or engines to software). With an engine there is eventually an assembly-line that repeats the process of building an engine...a static item. I'm sure that all the bugs have been worked out before flipping the final assembly switch. So, there's little need to really test.

Software is a continually changing product. Sure, if we were all perfect, we wouldn't need to re-run all of the tests to verify the change that was made down in one of the 1000+ files, in a class that is inherited by hundreds of other classes. But in reality, we're human, we make occasional mistakes that may never be detected unless there are unit tests (among others) designed to catch those low-level problems.

You can never replace testing by just good quality, because you need 'perfect' quality to be sure.

Testing - The Anti Quality Process (-1, Redundant)

Digital_Quartz (75366) | more than 9 years ago | (#11822212)

My father gave a talk at a Quality Assurance Institute conference last year entitled "Testing - The Anti Quality Process". You can pick it up here [thedreaming.org].

He also has a fairly imposing web page [thedreaming.org] which unfortunately only works properly in IE.

Re:Testing - The Anti Quality Process (1)

Ulric (531205) | more than 9 years ago | (#11822306)

The jellybean example is absurd. I know an algorithm which will, by looking at only 100% of the beans, find 100% of the defective ones.

Re:Testing - The Anti Quality Process (1)

Garg (35772) | more than 9 years ago | (#11822315)

ummm... so he's an expert on quality, but can't be bothered to make his Web page conform to standards?

Good thing he's not a cobbler, or you'd be barefoot.


Re:Testing - The Anti Quality Process (1)

Rostin (691447) | more than 9 years ago | (#11822336)

Wow, I might enshrine this one in a text file as a great, real-life example of a red herring.

Re:Testing - The Anti Quality Process (2, Interesting)

Digital_Quartz (75366) | more than 9 years ago | (#11822504)

He's an expert on process and software quality, not HTML.

But, you're right, his site is pretty deplorable. :P He said he wrote it in some Microsoft tool and keeps claiming he's planning on rewriting it. Sadly, my father is very much in the clutches of Microsoft.

Re:Testing - The Anti Quality Process (1)

liquidpele (663430) | more than 9 years ago | (#11822437)

WOW. that is one Un-Quality site, since it's unsable in firefox.
Your dad's really that much against testing huh?

Re:Testing - The Anti Quality Process (-1)

Anonymous Coward | more than 9 years ago | (#11822451)

What the fuck is a ".ppt" file and what editor will open it? And is this mystery editor available on apt-get, or will I have to do make and install?

Re:Testing - The Anti Quality Process (1)

Digital_Quartz (75366) | more than 9 years ago | (#11822483)

One would assume you can get Open Office by way of apt. It came with my distribution, so I'm not sure. The specific application you're looking for in the suite is called "Impress".

Let's say what Linus says about QA (5, Funny)

cerberusss (660701) | more than 9 years ago | (#11822214)

Let me be the first to quote Linus Torvalds: "Testing? What's that? If it compiles, it is good, if it boots up it is perfect."

Re:Let's say what Linus says about QA (3, Funny)

confused one (671304) | more than 9 years ago | (#11822226)

Hell, from his perspective, if it boots, it's time to pass it off to the willing horde of beta testers...

"Buisness" as usual (1)

Laurentiu (830504) | more than 9 years ago | (#11822220)

From TFA: "The quality assurance process is a process for providing adequate assurance that the software products and processes in the product life cycle conform to their specific requirements and adhere to their established plans."

I think the QA process in the OSS community is more than adequatly covered by the numerous alpha, beta, PR, RC and all the other release mechanisms. The larger your user base, the more chances of a high quality final release (which in turn creates an even larger user base, which is a goldmine for the next release etc etc). That is, imho, one of the biggest advantages that OSS has over proprietary software. No QA department in the world would beat a large enough group of college IT students with too much time on their hands.

Re:"Buisness" as usual (3, Insightful)

rdc_uk (792215) | more than 9 years ago | (#11822249)


What you have described is a large bug-hunting exercise.

QA is a process by which errors are supposed to be PREVENTED, not FOUND OUT.

That's why QA != Testing

Better QA == fewer bugs to find (it assures you are building quality)

Better Testing == more bugs found (it is, in fact, closer quality verification)

Re:"Buisness" as usual (0)

Anonymous Coward | more than 9 years ago | (#11822370)


QA is just what it says. Quality Assurance.

It is a few basic things like, is the program usable, is the program riddled with bugs, does the program do what it is supposed to do. The biggest QU question though is.....

Is this what our customer ordered and will they be happy with it?

Bug hunting is a part of that as is error prevention but QA goes far beyond the coding aspect of any contract.

Re:"Buisness" as usual (0)

Anonymous Coward | more than 9 years ago | (#11822311)

What you are a talking about is ad-hoc testing, which is fine. But there are many times when it pays to have a formal test suite, and in general OSS is terrible any sort of formal methodology.

The OSS world also seems to have significantly lower quality standards than the commercial software world. Stuff gets put on RedHat CDs that would embarass the average VB Shareware programmer.

I guess the feeling is that "everyone should participate in QA" and "there will be another release next week" -- but the fact is eventually you have to freeze the stuff and make it as bug-free as possible for the non-apologist end user.

Re:"Buisness" as usual (1)

Smallpond (221300) | more than 9 years ago | (#11822381)

Imagine a complex program containing many code paths that deal with rare error conditions (a typical device driver). Now imagine you have two methods of verifying the code.

  • Release it to the field and let the users find the bugs.
  • QA spends a day to code a test suite which exercises every code path and checks for the correct response.

Re:"Buisness" as usual (3, Insightful)

rdc_uk (792215) | more than 9 years ago | (#11822416)

" Imagine a complex program containing many code paths"


"QA spends a day to code a test suite which exercises every code path"

erm... "QA spends a day"

Yeah, right.

You do realise that a FULL code path test suite will, perforce, be LARGER than the source code it tests?

When doing QA, I used to start writing the test cases for software when the REQUIREMENTS document arrived, so that they were ready for use during the tail end of coding and for the unit testing. Its a BIG job.

And you design tests from the reqs, not from the code - how will you trap a completely missing boundary case, if you build tests from the source? Or the design?

Requirements drive source and test design, separately so that the assumptions in the former cannot pollute the latter.

Good QA (2, Informative)

rdc_uk (792215) | more than 9 years ago | (#11822224)

Good QA begins when the Business Case proposing a new project gets reviewed.

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...

Quality (1)

Alvandaar (35055) | more than 9 years ago | (#11822233)

I assure you that quality is the thing we lost,
while chasing after the deadline and trying to
meet our budget!

Hmm wait a sec. - I assured something, I
mentioned quality, I own a red(5%)-yellow(80%)-
green(15%) tie - I qualify for CQM
(Corp. Quality Management).


Any chance.. (5, Funny)

opusman (33143) | more than 9 years ago | (#11822235)

..Slashdot editors could apply QA to the spelling in posted stories?

It's "business", not "buisiness".

QA != Testing (5, Insightful)

coolcold (805170) | more than 9 years ago | (#11822240)

and clever != good marks in exams
testing doesn't make the software any better but testing do find bugs which developers missed. Quality assurance is to make sure that the software is of good enough quality before release and testing does confirm the case.

testing? (4, Informative)

fizze (610734) | more than 9 years ago | (#11822241)

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.

Show me your regression proofs then :) (1)

steve_l (109732) | more than 9 years ago | (#11822363)

I know testing only shows the presence of trouble, but if fully automated, you can first replicate a problem, and secondly show it has gone away,

Whereas proofs of correctness need to be redone every time you change code.

Test-centric dev (XP, the Agile methodologies) is standard in Java Dev these days, and there are good Python test tools too. Its a shame that C++ has lagged a bit, though CppUnit works well.

We have used CppUnit to test code, with CruiseControl (on sourceforge) to check out, rebuild and retest the app *every* time something changes in CVS. This is the future: you know all your tests work, all the time.

Re:testing? (1)

johannesg (664142) | more than 9 years ago | (#11822382)

because they are radically in their consistency.

Last year we had a quality bozo over from HQ. He explained all the new quality processes to us, and then presented us with an explanatory document that we could keep for reference.

One of his main points had been that all documents must have tracking numbers.

The reference document did not have a tracking number.

I do not think this is very consistent. Evidentally quality is something they bestow upon others, without actually taking part in its processes by themselves... Why is that, one wonders?

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.

Ha, in your dreams! I don't mean to belittle those who have made a carreer of QA, but in the end it comes down to checking that procedures are being followed and nothing more. That's not highly sophisticated or even clever, it is just a constant grind. It is more about persistence than about consistency.

Re:testing? (1)

fizze (610734) | more than 9 years ago | (#11822489)

I don't mean to belittle those who have made a carreer of QA

It is not my intention to do so, either.
Maybe consistency was indeed the wrong expression, of course persistency is important too.

Evidentally quality is something they bestow upon others, without actually taking part in its processes by themselves... Why is that, one wonders?

Well, if you are reffering to one of them "quality bozos" then, well.... this word speaks for itself, dont you think ?

Documentation and tracking numbers is a key part in ISO9000:2000, eg (wow how I hate the name), so I dont think you got the whole idea right. Maybe he didnt explain it thoroughly, who knows.

The point I am trying to make is that, in the end, it does not just come down to check wether procedures are being followed. This is known as Taylorism http://en.wikipedia.org/wiki/Taylorism [wikipedia.org] and was abandoned long ago.
Get real.

Six Sigma (3, Interesting)

millahtime (710421) | more than 9 years ago | (#11822253)

Six Sigma is one of the many quality processes out there that can apply to everything from design to manufacturing. The idea is to remove variation so that everything you do is always the same. Quite boring but effective.

This can apply to the way code is written and does in some companies.

What is QA Always a Separate Organization? (3, Insightful)

Black-Man (198831) | more than 9 years ago | (#11822255)

Every software company I've worked for, the QA department was always separate from Development. Then the classic mistake was always repeated... bring in QA at the tail end of a project and expect them to certify it and find all the bugs.


Re:What is QA Always a Separate Organization? (0)

Anonymous Coward | more than 9 years ago | (#11822285)


I worked in Software Quality Assurance, mandated by Capability Maturity Model, and I was a developer.

In fact this combination of positions meant I was able to hunt down a lot more issues in the organisation (not just the technology or the people) than anyone had expected. Including me.

Oh yes, and my SQA-activities ran continuously throughout projects from the very start to the very end. So yes, it does happen in places. And it does work.

Wikipedia writes a bit about CMM but the SQA part is less focussed. My experience is that proper SQA-work requiers more than tech, also human touch (you have to tell people they are doing something wrong without creating tension) and you have to understad organisational theory (after all much of the issues relate to dysfunctional structures than lazy programmers).

Re:What is QA Always a Separate Organization? (5, Insightful)

rdc_uk (792215) | more than 9 years ago | (#11822314)

I used to work as a QA person.

In our company QA was a separate organisation, for 3 simple reasons;

1 - you are auditing and commenting on other people's work, not in a peer review "did you think about doing it like this" way, but in a "That is not acceptable; redo" way. Close colleagues in a department are NOT suitable for that role; you cannot be expected to say that about the person in the next cubicle's work, whereas a department with that as their job will be accepted when they do it.

2 - Keeping up to date on the quality requirements, combined with performing your live QA duties for the engineering department was a full time job. Or at least, it certainly was if the company wanted to keep its ISO9001 certification.

3 - Its a case of the buck stopping here. In our company project proposals, requirements and plans HAD to be signed off by QA before the funding got released for the project. At the same time, due to our doing telecoms stuff, we had a legal responsibility to sign off that the EMC conformity, physical safety and electrical safety tests had been conducted properly and passed. (and that meant constantly checking updates of the various national standards to ensure the company standards used the strictest requirements in each case). Random engineer is not good enough. (you have to have passed the right courses to audit each various section, need to be a qualified ISO9001 auditor to do the internal audits for that etc)

Professional QA is a full and seperate job. (but I did get to play with the 20KV discharge equipment!)

If it works it still may not (3, Insightful)

bblazer (757395) | more than 9 years ago | (#11822259)

I think that the real issue here is the difference between code that works, and code that meets the business rules and need. Anyone can make good code, and have it compile and execute. The problem comes when that great code still doesn't fit the need that it was supposed to fill in the first place. This issue has two hurdles if it is to be overcome. First, are coders that have no business knowledge. Second, business pros that have no software development experience. The coders complain that they weren't given the proper details of the project, and the business guys complain that the coders know nothing about business. I think that all biz people need to take a basic programming course, and all coders need to take a business class. The gulf of poor communication between the two camps is quite large without it.

Re:If it works it still may not (1)

Kjella (173770) | more than 9 years ago | (#11822317)

Anyone can make good code, and have it compile and execute. (...) Second, business pros that have no software development experience.

Ah, but since making good code is so easy anyone can do it, experience doesn't matter. Just have your business pros write the software. Oh and tell me your company's name, so that I might invest in stock *cough*shorts*cough* and *cough*sell*cough* options.


Re:If it works it still may not (1)

rdc_uk (792215) | more than 9 years ago | (#11822357)

There is a job in the process of turning business rules into software systems.

It is called "Requirements Ellicitation".

Someone who is a professional at that bridges the gap, if you can't be bothered to bridge the gap, be prepared to fall into it.

What you propose would simply result in PHBs telling SW Devs how to code, and SW Devs telling PHBs their business rules are wrong.

Been there, done that;

PHB handing looking at his flow chart he had produced as requirements for a stored procedure, asking me "Why have you used so many variables; there aren't any variables on my chart..."


He did eat humble pie when I recoded the procedure without caching ANY select results... "why is it so slow now?"

Re:If it works it still may not (1)

marcosdumay (620877) | more than 9 years ago | (#11822429)

A software company businessman who know nothing about programming knows nothing about business also. Generaly, those companyes fail with all requirements (and generaly, bankrupt).

Re:If it works it still may not (3, Interesting)

StormReaver (59959) | more than 9 years ago | (#11822485)

"I think that all biz people need to take a basic programming course, and all coders need to take a business class."

That's simple, logical, and of no practical use. As part of my CIS degree, I was well over half way (close to three quarters) to a Business Management degree. It is absolutely useless for all of the business software I have to write.

My current project is to rewrite the entire county tax collection system. There is no business class that would have prepared me for that because each county collector does things differently.

I knew nothing about tax collection when I started this project, and the county collector knows nothing about software design (his belief that Fox Pro has exposed him to software development, and his need to micromanage notwithstanding).

He and I frequently meet to discuss the business rules his office currently uses, and the business rules he would like to be able to use. He tells me each feature he wants, and I create all the ends (front, middle, and back) to do it. Then we review the front ends and results from the backend.

This iterative process continues, on a feature by feature basis, until we are both satisfied that each feature works as it should and the user interface is streamlined for efficiency.

The bottom line is that detailed business understanding by the developers is both unnecessary and mostly useless. Software design knowledge by business people is also mostly useless (and in fact will likely be very detrimental) and unnecessary.

The common threads between business people and software developers to ensure success are good communication skill and patience. Without both of those, you may as well not even try.

Revolutionary notion! (3, Interesting)

BenTels0 (667908) | more than 9 years ago | (#11822262)

What a revolutionary point of view/complaint this article gives! In the sense that "revolutionary" means that history goes through a loop and comes back to where it was before...

It is interesting to see though, how every so many years the same ideas pop up in new guises. Edger Dijkstra for instance said more or less the same thing about Software Engineering and its mantra of process phases and planned testing. And the same argument can (and has) been brought against Kent Beck's Extreme Programming methodology.

Oh well, just goes to show you: the only lesson ever learned from history is that nobody ever learns from history.

Timing (1)

ein2many (850712) | more than 9 years ago | (#11822272)

If you take the time to do a good QA, you get complaints that it's taking too long to release the product. If you don't QA the product, you get complaints about problems in your product. It's a no win scenario. You just have to balance both.

Money Rules it All (2, Insightful)

millahtime (710421) | more than 9 years ago | (#11822273)

A way to look at it is, there is a lump sum for a project. The amount of money (time is money) to produce a product. This amount is made up of base price for product plus rework (which is cost of poor quality). If you can minimize the cost of the rework you can either/or increase profits, cut costs (including time to get product out), improve the design as it is higher quality.

Not sure I agree with all of the article (4, Insightful)

lottameez (816335) | more than 9 years ago | (#11822281)

The writer talks about separating QA from the Development group. In our organization, this was a large part of the problem. First, there was a tendency for the development group to "throw it over the fence" and expect QA to find problems that the engineers couldn't be bothered to look for.

The QA staff, on the other hand, rarely had engineers of a sufficient caliber that had the insights to search for and find the most insidious problems. Not only that, they (QA) occupied the no-man's land between business users and development, understanding neither area with any clarity.

Re:Not sure I agree with all of the article (1)

disc0tech (737811) | more than 9 years ago | (#11822367)

You're still talking about QA as a testing function. This is not the case. They key difference is:

Testing = finding bugs = evaluating the quality, not improving it

QA = finding process problems, not evaluating the product

As for teams being seperate - Independence from development is one of the key things that breeds great testing. Not knowing why/how technical decisions were made generates a questioning attitude and picks up the bad ones.

Re:Not sure I agree with all of the article (1)

lottameez (816335) | more than 9 years ago | (#11822454)

Okay fine, you say tomato, I say tomahto. There are three "QA" functions as far as I'm concerned:
1. Testing/finding implementation bugs.
2. Ensuring the development and other software management processes work. This is where tools like statistical process control can provide a great deal of insight. Whether or not this is a function of Development or a specialized QA department makes little or no difference.
3. Ensuring that the result does what was intended (to your point, not necessarily what was designed). This, above all else, is the most critical in my view and should be managed by the product manager.

This hurts (2, Insightful)

steve_l (109732) | more than 9 years ago | (#11822383)

I can see the problems this creates. Dev teams blame QA for being fussy; QA hate the dev team for releasing such junk.

We have to embrace test-centric development more. JUnit, CppUnit, PyUnit, they make it easy to write tests. But to convince the developers to write good tests, that is another matter. I often find it is harder to write a decent test for something complex than it is to implement the complex thing, but without that test, how do you know it works?

Re:Not sure I agree with all of the article (1)

cswiii (11061) | more than 9 years ago | (#11822457)

That's at least partially a dev problem then; sounds to me like the stuff was not even unit tested before it was "thrown over the fence" to QA.

But you're right in one respect - QA engineers are -- or at least should be -- more than test monkeys.

Can't tell you how many times I worked with people, people on a "Senior" level, who knew very little about systems as a whole, or even the QA process - they just had been there long enough to know how to circumnavigate the idiosyncracies of the systems that were tested... that, and they had learned how to just STFU and take whatever answer dev gave them.

Re:Not sure I agree with all of the article (1)

Alomex (148003) | more than 9 years ago | (#11822474)

In a previous job we had two QA groups. The internal group which wrote tests for component testing and indeed was composed of engineers who were part of the developer group. We also had the end user QA group, which new nothing about the product, and obtained a CD with the product. They had to test everything from installation to the user manual to see if the software could be used by the customers as shipped. In this case the least the QA knows the better as customers (in our case) were not expected to be experts (Linux software developers: there's an idea for you :-)

Proof it's a good thing for a company (1)

millahtime (710421) | more than 9 years ago | (#11822288)

The Japanese have been all about quality for many years. Their cars are less expensive yet more reliable. They do things in general at a lower cost, that are more reliable and faster.

Not a bad biz model. In the car example they eve build the cars on US soil with these methods, so, it is something we can do and doesn't break out backs.

Even more, QuAlity != QA (4, Insightful)

dallaylaen (756739) | more than 9 years ago | (#11822349)

If design is flawed, what should QA do?

If docs are porly written, and incomplete, how does one decide what's bug an what's feature?

If the docs depict the program's behavior, not define it, what can QA do? ...And more, see F. Brooks' "Mythical Man-Month" for example, or Alen Holub's "Rope Long Enough to Shoot Your Leg".

And yes, if everythign is done right from the beginning, the QA people would have enough time to do something except testing.

Of course, only third of the two ways to write bugless programs works...

Re:Even more, QuAlity != QA (1)

Digital_Quartz (75366) | more than 9 years ago | (#11822394)

All that testing does is prove your program doesn't work.

Testing DOES find bugs which the developers missed, but it only finds a very small fraction of them (unless you spend an extremely long time testing. I worked this out a couple years ago, but I forget the exact numbers. Something like to remove 90% of the remaining defects in our software, based on historical defect discovery, it would take around 20-30 person years of test effort.

Testing is the most expensive tool you have to remove defects. When you find a defect in test, you have no idea where that defect is. Someone has to root-cause and fix the problem. When you find the defect in a code-inspection, you have your finger on it; you can fix the defect with a minimum of effort. Also, it is much easier to find defects in a code inspection than by testing (around 2-3 per hour versus about one per 2-3 hours, on our product).

Even better is in design inspection, since a fault in the design typically leads to multiple faults in the implementation. Even better yet is in requirements inspection.

So, if your QA plan doesn't cover these phases of your development, your QA plan probably needs some work.

The whole point of testing is to see how well the rest of your process worked. If you know how much effort you spent testing, and you know the rate of defect discovery, you can estimate the number of defects remaining in your product. If that defect count is too high, though, it is probably faster and cheaper to start over with a new process than it is to "test" the product until it is free of defects.

quali-what? (-1, Offtopic)

GatesGhost (850912) | more than 9 years ago | (#11822374)

come on, most of us are using microsoft. we dont know nuthin bout no qa. what a foreign idea.

Oh god yes (5, Insightful)

Michalson (638911) | more than 9 years ago | (#11822400)

Can someone please forward this to the good old folks at Mozilla. The written QA requirements (on Mozilla) are so cursory that whole features have dropped off the map simply because nobody bothered to check to see if they still worked (i.e. in 1.4 multiobject drag and drop stopped working). Might also help the parsing engine, which continues to have kruft from the Netscape days (like how <b<i> is interpretted as <b><i> instead of as a single broken tag to be ignored [and you can use any tags you want, the second one can even contain parameters, allowing you to really annoy people by adding extra HTML that only works in Firefox/Mozilla, not IE/Opera]). Though really as Slashdot [slashdot.org] has reported before, Mozilla could really use a more robust and systematically tested parser just to avoid potential buffer overrun exploits.

Bottom line: OSS could get way ahead of commercial software simply by doing proper QA and unit testing (not just the UNIX "it seems to work" test, the "are out of range inputs properly detected or does the program just choke and die") on par with what the best commercial developers have been doing. Just because you have to do all this paperwork and repetive checking when working for "The Man", doesn't mean it's an evil thing that should be thrown out. Sometimes the man actually has some good ideas, even if he spends most of his time shouting about how you didn't dot your i s on that last flowchart.

'buisiness goals'? (0)

Anonymous Coward | more than 9 years ago | (#11822403)

I must admit to never having any 'buisiness goals'

It's just what I asked for but not what I want. (0)

Anonymous Coward | more than 9 years ago | (#11822441)

QA vs. Business vs. PHB

Been there done that.

Quality != Good (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11822455)

The first thing they drilled into us when our organization switched to a different QA process was that 'quality' did not mean 'good'. Quality just meant that the product or service conformed to certain requirements.

Where I am now, 'quality' means ISO-900x. It is a bureaucratic process for keeping things from happening. I used to be able to find rules and procedures. We had documents that were clear and easy to find. Now we have a rule that the documents that we need can only exist as one copy so that we don't have different versions circulating. I realize that ISO has all kinds of wonderful ideals but the practice around here is something other than wonderful.

I realize that people will say that my organization is using the ISO process wrong and I agree but we still pass all the audits. ie. The QA on the QA system itself does not ensure goodness.

In my company... (1)

nbharatvarma (784546) | more than 9 years ago | (#11822466)

Three of us are working on completely different modules on an existing product. So, every week we give a integrated build to QA. We tell them the functionality they should test for. They report bugs in these areas. This way, we don't wait till the end to start working on all the bugs at the same time. We hope that at the end, there are no bugs.

When they are testing one build, we are already working on the next one. Considering that I am a fresher with relatively lot less experience, this helps me to sort out the problems early on so that I don't build up my whole work on some faulty code.

what is interesting (4, Interesting)

roman_mir (125474) | more than 9 years ago | (#11822476)

in some (many, most?) cases QA becomes the definitive answer to what the requirements actually are. In some cases the requirements are not very precise, so it is up to the developer to translate them into the code and it is up to the QA to decide whether the developers' interpretation is good enough for the purposes of the system. In reality if you have a QA department, the QA defined test-cases become the guide to how the program behaves under various conditions. These test-cases define the system better than the requirements in some (many, most?) cases.

Semantics != Rhetoric (1)

hnile_jablko (862946) | more than 9 years ago | (#11822487)

Quality Assurance is merely an assurance. It is not a guarantee. It is some corporate hack who knows that some clients (especially govt) will succumb to the wiles of rhetoric. And will even exploit the vagueries of it in the contract when the client starts pushing back for the results they expected. Quality Assurance; broadening the gap between client satisfaction and liability.

Software devel. could learn from Blizzard. (2, Interesting)

MadcatX (860684) | more than 9 years ago | (#11822505)

I find that software Q&A for applications/OS's/etc. for use by the general public is not necessarily the priority it should be due in part to the fact that they can always "patch" something if a bug arrises. But, on some occasions, patches are created after the damage is done. Although I will say that even if QA is a priority, there will always be a few bugs that will slip by the testing, due to the sheer amount of various situations that the software experiences (A plethora of different hardware setups, configurations, etc.)

However, one company that has stood out in this field is the video game developpers Blizzard Entertainment. Sure, they have a reputation of not being able to adhere to shipping dates, but for good reason: They want to make sure that the product they ship is near perfect. I'm sure we're all willing to wait a bit more if that time is being used to test products.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account