The short answer is...
In general,
I'm a registered and licensed professional engineer.
I do like and are able to do pretty much all engineering work.
However, whenever I do have a choice -- and I usually do -- I specialize in software test,
system test, quality assurance, verification, validation and documentation.
It's easy to find contracts for me:
Just do a keyword search for any of the following job titles:
- QA Engineer...
- Software QA Engineer...
- Software Test Engineer...
- Sofware Verification Engineer...
- System Test Engineer...
- Test Engineer...
- V&V Engineer...
- Verification and Validation Engineer, and
- Verification Engineer.
The long answer is...
My focus
has been software testing, system testing, verification, validation, and documentation.
This is where I've had ten (10) years of paid / industry / commercial
experience.
Why testing?
- 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 creating test cases, writing test
procedures, or writing bug reports, it is thoroughly enjoyable to me.
There is a need to break things (constructively and carefully, of course), 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.
And 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.