Do you test?
The best companies test their products thoroughly.
Other 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 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.
- Because there is a need for breaking things (constructively and carefully, of course).
- Because I'm smart enough to catch other people's mistakes.
- Because I'm quick to notice them before everyone else.
- Because I'm 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, it 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 manufacturers want to know how and why their products fail,
so that they can determine what corrective actions they should take.
XYZ Corporation manufactures and markets medical devices, controlled by highly
sophisticated, embedded, real-time software.
I test their devices thoroughly, and look for software defects.
Usually there are hundreds of them!
Whenever I identify a defect, I write a report.
Then the client has two options.
Ignore the defect and wait till there are many-many defective, malfunctioning,
unreliable products in the field. Or, alternatively, fix the software before the devices
go out to the field. The latter is far more efficient and cost-effective,
but requires a solid understanding of why the device failed during testing.