I’ve read this quote a bizillion times. I think it’s pooh. You CAN test quality into a system and many of you do it every day.
Say you get a system with bad specs. Or no specs. You’re probably going to start your testing experience with a significant amount of inoperable features, loose ends, or defects. During the testing process, you’ll be driving these out. Do testing personnel actually PUT the quality into the system? No. Generally we don’t code and we don’t make fixes. We do not create the product. But we DO ensure the product meets a given company’s standards for a quality application.
Is “fit for use” the same as “quality”? It depends on your perception of quality. You can have a quality product that is rejected by the user community.
If we think about this for a few minutes, a testing organization is not really responsible for the original idea and applicability or usefulness of a given app in the field. Our responsibility is to ensure whatever is produced meets
I realize some will argue vehemently that if the end user doesn’t want it or it doesn’t suit their needs, it’s isn’t “quality”. I can understand that attitude, but I don’t really agree with it. Someone in your company is responsible for market studies, concept, design, etc. and hopefully your company has some sort of group that reviews proposals for new products and makes decisions as to whether those are good ideas. It’s not up to me to “judge” whether a given product is a “good idea”, will make/save the company money, or will be a success in the field. That is someone else’s job. It’s my job to test the product. If that product does what we were told (through some medium) it should do and it doesn’t do anything we feel it shouldn’t do, then it is a quality product.
It may, in fact, be a useless quality product, but who is responsible for that? The testing team? I don’t think so. Executive management, marketing, and possibly the PM are often responsible for ensuring the company works on appropriate projects. Have you ever worked (hard!) on a project that was a flop in the field – users didn’t buy it or rejected it? I have. Everyone I know who has been in field for more than 5 years has probably experienced something similar. That failure is the “fault” of those that decided to authorize the project. I’m a practical person – my thought is that I have enough to worry about without accepting responsibility or worrying about what is someone else’s job.
So how is quality “tested into” a product? By driving out impediments to operating the system effectively, ensuring what was desired is what was produced, and that error conditions are handled gracefully. A given test team may get products to test that won’t even boot up. Is that quality? Even if the original concept and design of the product was great and the users are clamoring for it, that definitely would not fit most definitions of quality. It is common to get new systems to test with error rates over 40% and major features inoperable. During the testing/fix/retest process, those problems get fixed. The end result should be an application(s) at whatever level of quality your organization supports as “acceptable”. Even if you spit on the concept of “metrics”, if you’ve found 532 problems and at the end of the test/fix/retest cycle, you have 22, none of which are serious, you can recognize there’s been a significant improvement in the quality of a given application.
So yes, Virginia, you CAN test the quality into systems. If you’re a testing professional, it’s probably one of the main reasons you’re employed…
Posts
