Q49: Why test? What do we test for?


Q49: Why test? What do we test for?
Do you test? The best companies test their products thoroughly. Other, below average, companies do little or no testing, and learn the hard way, as to what happens when there is inadequate testing.

How do you test? At the best companies, test development begins immediately after the initial product design meeting. At the best companies, test development is treated like product development. This improves on-time delivery, minimizes budget overruns, and improves product quality through enhanced visibility, and negotiation between design and test engineering.

Other, below average, companies postpone test development until after the design process is complete. This practically guarantees that product delivery will slip, the project budget will be overrun, corners will be cut, quality will suffer, and there will be many defective, malfunctioning and unreliable products in the field.

Why test?
  • Because there is a need for breaking things (constructively and carefully, of course).
  • Because I am smart enough to catch other people's mistakes.
  • Because I am quick to notice them before everyone else does.
  • Because I am detail oriented.
  • Because I thoroughly enjoy breaking things (constructively and carefully, of course).
  • Because, whether I'm writing test cases, test scripts, test procedures, or bug reports, software testing is thoroughly enjoyable to me.
There is a need to break things (constructively and carefully, of course). And because sometimes breaking things is constructive. Some people, like me, even get paid to do it. I break things because device manufacturers want to know how and why their products fail, so that they can determine what corrective actions they should take.

For example, XYZ Corporation manufactures and markets medical devices that are controlled by highly sophisticated, embedded, real-time software. I test their devices thoroughly, and look for software defects. Usually there are hundreds of defects! Whenever I identify a defect, I write a report. Then the client has two options. One, they can ignore the defect, and wait till there are lots of defective, malfunctioning, unreliable products in the field. Or, two, fix the software before the devices go out to the field. Obviously, the latter option is far more efficient and cost-effective. However, it requires a solid understanding of why the device failed during the testing.


For Rob's resume, click here or here.

Contact Rob

For contact info, click here.