My Job: Testing

by Taylor
Several people want to know what it is that I do for my job. So I suppose that this would be an acceptable way to note it for all of you inquiring minds. I actually work for a company called Software Builders, Inc. (SBI), but Investortools is who we work with or work for, and you can find them online at http://www.invtools.com.

My job is in testing software. It is not typically considered a "high-profile" position, but as I recall my work as an Optical Engineer at Lockheed Martin, I was mostly doing testing of optical components. I suppose that someone has to do it, and that someone seems to be me! (There is actually a large and very important company that is dedicated to testing. If you look on the back/bottom of many electronic or mechanical objects you will see a little "UL" sticker. It stands for Underwriters' Laboratories, Inc.; they test all sorts of products so that they are relatively safe for us to use.) Well, let's get back to where I was going:

A lot of software can be tested automatically (via more software). This is great for crunching lots of numbers, but if you really want to get down to the gritty details, then you have to do it manually...that is where I (and others) come in to play. Perhaps it would be easier to give a short overview of my testing day.

I will be given a particular assignment. The developer will note how he changed the code and what he expects the change will do. I initially try to follow his instructions for any basic flaws that may have crept up (this rarely happens though, but it does give me a feel for what the system is doing). After I understand what is going on, I try to think of any "backdoor" methods of getting to the changed code. If I have to enter data, I try to enter bad data or I try excessively large values...basically, I give the system something that it does not expect. It helps to have an idea of what the system is doing and what it is expecting; then I can try to pull it apart. Generally though, our developers are very good at what they do and errors do not come directly from the stated job at hand. Most of the time, I will find errors that do not relate to the job at hand at all, but rather they lead to a new issue that has arisen.

This keeps me busy due to the fact that our product gets a fresh update on a monthly basis. So every month there are about 200+ testing jobs split among 4 testers. Since the test cycle is so short, it can get quite busy testing a complicated system as this. It is certainly not life-threatening (i.e. missile control), but it can be very costly (i.e. financial securities).