The job of a QA Engineer

"Four years ago I couldn't spell engineer, now I are one." Used to be a funny saying a long time ago. Now I really are an engineer and have been for a lot longer than four years.

I won't go into how I got there, but my path brought me through 'Application Developer'.


There are some definitions out there, but to me an Application Developer is someone who develops applications using libraries that a real developer has created to make developing applications easy. I don't know about easy, but it was fun. And it still is. I never quite got over that feeling of amazement when some piece of code I write actually performs as I expected.

When I came to America (read my book to find out how I got here), the most important thing to me was to find a job, any job. I was quite prepared to wait tables if necessary. In fact, in the first year, I ended up with three jobs, yes, at the same time.  I taught horseback riding (yes, I am qualified to do that) on Saturday. At night I did the books for a window treatment company, and during the day I was a Software Quality Assurance Engineer. Never heard of that job before I got it.  But like I said, any job!



I went to a job fair and handed my resume out to everyone. Long story short I got an interview and was offered the choice of Customer Service Engineer or Quality Assurance Engineer. The second sound really interesting so I chose that. What a fortunate choice.

The first few weeks I had to scramble to figure out the jargon. Hell, I was just learning to speak American, speaking QA on top of that was not easy. But I got it. I figured out what a Test Plan was, established that, while very boring, it was also very necessary. And best of all, I got to program.

Writing tests is a whole lot easier, and more fun, than what I call 'real programming'. You, the QA Engineer, decide what you want to write and how you want to write it, rather than have a designer tell you what to do. You get to know and understand, and experience, the entire application. A developer only works on one small part, and frequently is totally ignorant as to how their contribution is incorporated into the whole.

The down side is that you are the last line of defense, after you is the USER. And no matter how many defects you find and are responsible for preventing the USER from encountering, you are held responsible for those few that escape into USER land.

Believe me, there is no one, not even the USER, who feels worse about the escapees. We live to catch those bugs. The ones that get away (and we know there will be many of them) are the ones we live in terror of. They are the bugs that define who we are to the rest of our colleagues.

The only person who knows about the bugs you catch and prevent from getting out are the developers  whose bug you managed to catch - and the good developers know and appreciate your work - after all, you prevented them from looking bad. Everyone knows about the bugs that get away.

So, I hear you ask, why do we do it?  I know why I do it. I love programming but I know that I am not good enough at it to be a programmer, and truth be told, I like being involved in the entire production. I like all of the side shows associated with QA but still get to write code, and it doesn't have to be highly efficient, just has to catch those bugs and exercise as much of the real code as possible. But I am also a little bit OCD, OK, may a lot OCD - and I am a Virgo.

Most of all I don't want to use applications that keep crashing, returning errors or just flat 'don't work' and I get a huge amount of satisfaction from making sure that my customers (yes, I think of them as mine) are protected from the same unpleasant experiences.

You are more than welcome! It is my great pleasure.