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.'"
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.
I'm a big tall mofo.
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.
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.
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."
8 of 13 people found this answer helpful. Did you?
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...
..Slashdot editors could apply QA to the spelling in posted stories?
It's "business", not "buisiness".
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.
I am harvesting funny/good quotes. Please help by putting them in your sigs
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.
No.
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)
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.
Evolution or ID?
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.
Madness!!
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.
My
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.
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.
Evolution or ID?
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.
Evolution or ID?
An excellent example of how anecdotal evidence can lead you to incorrect conclusions.
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. 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 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 has a good web site 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.
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.
Yeah? Well I think you're overrated too.
If design is flawed, what should QA do?
...And more, see F. Brooks' "Mythical Man-Month" for example, or Alen Holub's "Rope Long Enough to Shoot Your Leg".
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 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...
WYSIWIG, but what you see might not be what you need
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'.
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?
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 is interpretted as 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 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.
" Imagine a complex program containing many code paths"
Mmmkay.
"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.
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.
You can't handle the truth.
He's an expert on process and software quality, not HTML.
: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.
But, you're right, his site is pretty deplorable.
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.
- "I reject your reality and substitute it with my own", Adam Savage
Cost, Time and Quality and you can only have 2 out of the 3.
For instance, you can have a project done fast and cheap but the quality will be lacking. Or you can have a project done correctly and quickly but it will cost you a fortune!
QA is part of that "having it done correctly" piece that most companies tend to cut out. Most companies can only grasp the Time and Cost factor and fail at the whole "Quality" component when doing pre-project analysis. I do not have enough fingers to count the projects I've witnessed that have been running behind schedule (which is usually a BS timeframe to begin with) that decide to cut time from the QA process to make the deadline.
The reasons for "falling behind schedule" and all those other fun things that go into bad project management have been discussed before so I won't even mention it.
Do you (personally) understand the actual ISO9001 system?
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.
External ISO9001 audits ONLY check that you are following your own processes, and that you have addressed the requirements (which may or may not be in a sensible way).
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.
The quality of the product is not in focus. If you try talk about things like Lint and Purify with persons representing Quality you will get an answer that that isn't about quality at all...
So the whole Quality business is something that is invented to support itself and not the end customer of the product. In the long run the customer is actually more interested in the quality of the product than any provided documentation that states that this product was created with our Superior Methods and Ultimate Skill. That documentation doesn't help at all if the product crashes twice a day...
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
"From what I've seen of QA, it is testing, just not in the "Testing" phase. It is having well-defined objects, interfaces, input ranges, output ranges, unit tests and so on to make sure that when you assemble everything together, it has few bugs left. Basicly, weeding them out at an earlier point in the process."
No offense, but you missed out:
Ensuring that the requirements the SW is built to match are complete / correct in the first place.
Ensuring that the SW is built in a way that is suitably efficient for the project.
Ensuring that the SW has at least been thought about in terms of being built for re-use.
Ensuring that there was at least some thought about "is there something already here that we could re-use or modify?"
Ensuring that the SW is built in a method that lends itself to maintenance and modification without tearing out of hair.
Ensuring that some form of profiling or metrication has been performed, in case the project as a whole needs optimisation (being able to look at the metrics for each unit speeds that first "where to optimise" pass SOOOO much)
Ensuring that throughout all those processes the correct feedback was fedback to the people who actually DID all those things you just ensured...
ALL of that is part of the QA for software development, very little of it actually involves testing the software does its job right...
In that case you have a specification! In the form of your static prototype.
A prototype and a specification do not contain the same information. A prototype consists of a single concrete instance of the thing a specification describes. It contains more information than the specification in some respects (the concrete design choices the implementor has made to fill in the gaps the specification is silent on) but more importantly it is also missing information that is absolutely required in a specification.
For example: What are the tolerances on particular processes? What are the scaling and responsiveness requirements? And so on.
Nothing that does not capture this kind of information is a specification, and so far as I know only a document can capture this kind of information.
Don't get me wrong: prototypes are useful. But they are not specifications, because they do not contain the all of the information that a specification must contain.
--Tom
Blasphemy is a human right. Blasphemophobia kills.
Cost, Time and Quality and you can only have 2 out of the 3.
Every time I hear this I cringe, because it is complete crap. On a small level or to someone who has no quality assurance practices in place, it appears to be true, but for large projects/products quality assurance is inversely proportional to cost and time precisely because it cuts down on the amount of time required to develop and test a product to its specifications. Quality assurance procedures will help ensure that errors are caught early on in the project lifecycle and develop standard procedures for project development which may have an initial hit on timelines, but in the end save time. The really nice thing about good quality assurance procedures is that they generally get easier as people get familiar with them and time goes on.
For instance, you can have a project done fast and cheap but the quality will be lacking. Or you can have a project done correctly and quickly but it will cost you a fortune!
I'm assuming that when you say quickly here you are thinking of thowing more manpower at the solution because, as the time to complete a project increases the cost increases and vice versa. Quality does not mean features and flawless software. It means that your client gets what they ask for on budget and it works like specified.
Cost is directly proportional to time, quality assurace might add some time to the project, but it has been my experience that the time it adds is usually offset during testing and not having to add features that a client expects during / after internal testing.
10: PRINT "Everything old is new again."
20: GOTO 10
When I worked in a mainframe group at a major airline writing code for internal use in flight ops, we had a small team of a dozen or so experienced programmer/analysts (perhaps 15 years of experience on average) who each knew their business/application area rather well in addition to being quite competent technically.
We also tended to work directly with a dedicated set of business analysts who were also quite experienced, being dedicated "end users" from various operational areas, and it was a collaborative effort to design and implement projects large and small.
After years of working with the same experienced people, the system worked *very* well. We had processes in place to help ensure that proper testing and documentation was done and that no unauthorized production loads were made -- otherwise, we basically trusted people to use their best judgement.
Since the folks who were writing the code were also supporting the application 24x7 on a rotating basis, they had a vested interest in keeping the system stable.
I think that demonstrated (at least to me) that sometimes a full-blown separate QA process isn't required. By doing things in a somewhat abbreviated way, however, the group was a lot more agile, and quality fixes could literally be coded and loaded in a matter of hours (in some cases).
When I worked for Unisys on application development for paying customers, however, we had a much more formalized process. We had dedicated business analysts writing the func specs, programmer/analysts to write code to those specs, and dedicated QA people who designed and helped implement formal test scripts (both manual and automated) before the product was rolled out.
The size of the group and the nature of the product made that level of QA more important, I think, but it was also implemented knowing that the software development cycle in place was a slow and deliberate process.
Moral of the story: Maintaining a local system for internal corporate use is sometimes a VERY different process from developing commercial software for external customer use, and the two situations can sometimes differ greatly in approach while still maintaining a very high level of quality.
I also think it depends quite a bit on the quality of the people you have in place, and also on the level of experience those people have with the product, the technology, and in working with each other. Experienced people can work wonders if you let them.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
In reality, Windows rose to dominance because it was an inferior product brought to market at the right time.
businesses chose to use windows because they wouldn't have to rewrite all their legacy/mainframe/in-house apps, because underneath it all, you still had DOS. and if your app didn't play nice with windows task-switching of DOS apps, you could exit wondows entirely, and have essentially a clean slate for the custom app to use.
My contention is that the requirements and design process is more broken than the rest of the software development process. I believe that this is the actual cause of the rise of "Test driven" or Test First" development process currently being peddled as the silver bullet, here what I believe is a more forthright characterization of the methodology:
Due to the fact that the requirements creation process for software is irreparably broken, we have devised a way to sidestep it.
By having programmers/developers/software engineers write tests first, we actually are having them create software encoded and automatically testable requirements documents - it has less to do with testing and more to do with recording design, requirements and assumptions.
Without a functioning requirements process, the development process is hindered, but Testing (commonly known as QA) process is really screwed.
the reason that "testing must take up the slack" could be because of lack of reasonable deadlines/gates in the earlier development stages?
Try 15. (In software and in manufacturing)
The most severe downfalls I've seen are when the marketing teams and development teams do not adequately communicate with the QA team.
I have to disagree, the most severe downfalls I've seen are when the ship to customer date isn't allowed to slip but the date for development submitting to test is. Test end up having to do a month's work in a week and there is no time to fix bugs. So it shouldn't be a surprise when the product ships with known, unfixed crtitcal bugs and the customer ends up cancelling the entire contract.
In my experience what you need to produce some sort of "quality" product is a sales team that doesn't over promise, senior management that are aware that you can't just tack on some testing at the end and it'll be alright, clear specs, and enough time to actually do the job.
Oh, and a test team that are commited to the role, not a bunch of wannabe programmers who see it as something to do for 3 months just to get a foot in the door.
Good communication helps, as does a good working relationship between teams but neither is entirely essential.
Having said the above, it's also my belief that the strongest impediment to producing high quality software is the end user license. As long as software producers can disclaim any and all responsibilities, fitness for purpose etc there is no incentive for them to do it right.
Right?
One of my main Day Jobs up to a few years ago was working in QA for Major Computer and Software Manufacturers.
The idea of:
Testing = finding bugs
QA = determining which features are required, and whether or not they work as intended for the end-user.
Is fine in theory, but rarely happens in practice. It usually ends up that QA is ignored and conflated into bug testing. And even then, it often doesn't matter.
Example: I was working on a team that developed an Important Piece of Software That Is Very Popular These Days. We Had No Specification.
None. After some terrifying meetings with the CEO, we somehow brought it to a 1.0 release. I didn't want to have to go through that little nightmare again, so at the 1.0 post mortem meeting, I asked "So, we built 1.0 without a spec - what exactly are we going to do next? What is the Specification for 2.0?"
The lead programmer looked right at me and said "The Spec for 2.0 is 1.0."
We had shipped 1.0 with over 850 bugs, with half a dozen known (if somewhat obscure) crashing bugs, and with several features "turned off" because we couldn't get them to work.
At that point I knew I had to get the fuck out of there. I wasn't going to spend over 2 hours a day driving just to help this rolling train wreck. I left as we shipped 2.0.
From there I went to a company That Was Also Extremely Famous (but now defunct) where QA was more of an expensive after thought. they hired a great team, but the engineers were so disjointed that the product kept changing every other month.
The stress level was so high at that company, of the 120 employees, half a dozen attempted suicide in the 9 months I worked there. At one point, there was such a row in basic engineering philosophy, two of the main programmers got into a fist fight. When the money dried up, we all got laid off.
We can go on and on about how important QA is, but the fact is, we're in a business that makes products, and when the business is more than a dozen people jammed in a garage or airless office space, the products tend to be driven by marketing droids. Left to their own devices, Engineers will produce complex objects that don't necessarily work or fulfil a worthwhile function, or do it in a way that is elegant and useful. Left to QA, the product never gets out the door, because Software Engineering *ISN'T*. SE is more like knitting or quilt making than an Engineered Science. Bridge Builders use Engineers - they have books full of equations that have been proven over the years and they use these solid tested things in a creative way to solve a problem : how to get from here to there.
When a bridge fails, or a building collapses, they just look at the evidence and compare it to the known working materials sciences, engineering principles, etc. and figure out how it failed.
With Software everything is written in a series of codes - at the machine level, we know what they do. But once you get into the meat and potatoes of software development, it all gets very wiggly very quickly. That's why TESTING is needed. And QA should be brought in even before the coding begins - when the UI is being developed, when the notion of the application's purpose and methods are being developed.
But, as noted above: if QA runs the show: it never ships, as there are always improvements to be made. Always.
So, you have the maketing droids who have the ear of the business managers who then set arbitrary and insane deadlines. The result? QA can't touch everything, or they conspire with Engineering that some sections are "good enough" and they let it go, so they can focus resources on testing problem areas, in order to meet the absurd deadline.
The end result is always the same: The public gets buggy software.
The only question is : How Buggy Is It?
They flip the crank, they do the late nights, they get the product out. QA and Eng do their littl
The tools you are looking for exist, but they're not cheap and they need someone to create test cases for them and run them. I assume it's a web app you're talking about? Really, you need to hire a professional and give them professional tools. There's no good way to test your app cheaply. What you really need is a copy of Mercury Interactive's Astra or Segue Silk and someone to run it for you.
If you have to do it cheaply and by yourself, good luck and have fun writing those tests. Do a web search and have fun evaluating tools and writing tests. Here is the first hit I got on google. I've never used it but maybe you could look into ieUnit.
Oh, and my advice is to find a job closer to home. That commute will literally kill you. No, really, I mean it, you'll die.
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.
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.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Basically, anywhere within a java program where an exception could legally be thrown, the tool would cause your program to throw one of the allowed exceptions.
Sure, java has checked exceptions, and you have to either catch and handle them, or propagate them, but requiring this doesn't guarantee you do it correctly. Also there are some exceptions, like running out of memory, that aren't checked or declared in a throws clause, that could happen just about any time.
Java being an interpreted language makes it possible to do this to a binary, which I don't think would be possible for a C++ executable, but I think some kind of source code preprocessor would allow such testing for C++ programs. Maybe a good open source project for someone with more time on their hands than I.
Request your free CD of my piano music.
if QA runs the show: it never ships, as there are always improvements to be made. Always.
Then you're doing QA wrong.
One of the big parts of having a spec and a QA process is to know WHEN TO STOP.
When you get the function of a part right, and the tests have been run and show it's right, you MOVE ON. You only come back to it if the debugging of a later part reveals a hidden bug that the earlier tests missed (or couldn't test without the availability of the later part).
When you've moved on from the last part you're DONE.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way