Do you test?
The best companies do the right thing, and test their products thoroughly.
Other companies do little or no testing, and learn the hard way what happens when there is no adequate test.
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.
Why test?
- Because there is a need for breaking things (constructively, 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.
For example,
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.
What is the ideal call?
Some recruiters are wonderful. The ideal call I have in mind, and receive from time to time,
goes something like this:
Telephone rings and it's a recruiter. He/she says a well-known, large client - e.g. Lockheed
or Honeywell - has a major project underway. There is lots of work, and the client
needs many software test engineers. "This is a contract. The job description is a short ______.
What do you think? Duration is eleven months, but there is work for up to five years.
The rate is generous, and we can shoot for $65, $75, or even $85 per hour. Are you
interested, and would you like to get submitted?"
Why not?
I believe the most important thing is to 'work'. If it's on my resume and the rate is right,
I will do it. I'm a firm believer in taking the bird in the hand. If I'm offered a start date,
I usually take it, no matter what it is. It's not forever. My main concern is a paycheck on
Fridays.