posted 07-26-2001 12:34 AM CT (US)     

If I hate testing, am I in the wrong profession? What options are out there?

Thank you,
Dan

posted 08-05-2001 10:34 PM CT (US)         

Well Dan, if you stay in the profession, then you will hopefully see *all* aspects of software development. Testing is just one of them. I assume from your statement that you have been dropped into a project that has reached integration stage or possibly customer acceptance i.e. all of the coding is basically done, unit testing has been performed and everyone is now at the point of actually "get it going" :-). You find it boring, well, it is a good way of finding out how the current application works at a functional level i.e. hopefully there is some form of requirements specification against which the testing is being performed. It is a pretty standard inroduction for newbies fresh out of college too. Since everything you write in the future will involve testing, what is wrong with learning how to do it? :-) They might even plan on having you "support" the product once it goes "live" - another standard apprenticeship approach. You surely didn't expect to be asked to write the next generation accounting package or something, did you? :-)

Testing itself can be viewed as an art i.e. you have to understand the requirements prior to formulating the test conditions. Deriving good test conditions can be rewarding and fulfilling especially if you "catch" out the programmer i.e. you think of some case which he/she didn't consider when coding :-). Something that happens quite a lot really since many programmers have the belief that their program will be executed along all of the "true" paths and so they never consider what may happened when a particular statement might fail i.e. witness the number of C programs you have seen where the return value of a function was completely ignored - the original coder returned a value for a reason - he/she didn't just return something for the heck of it and yet many C programs blithely ignore any return value. If you have been taught defensive programming then you will know that a majority of code is there for those unexpected circumstances - which cause the biggest headaches in any design i.e. "what if this fails....." :-)

Software development is full of testing - unit testing, integration testing, customer acceptance. If you don't feel you can cope with this then please be honest and get out now before you help screw up some project somewhere! :-). I have been in "the game" for over 20 years now, between 25%-50% of every group of programmers I have ever worked with should have listened to their mothers and been "butchers, bakers or candlestick makers" - *not* programmers. If you feel you fall into that category then do the rest of us a favour and get out now - life is too short to have to clean up after clowns who just want to hack out code (which they probably do very poorly :-)).

Just remember, if it is worth doing, do it well. Get in there and break something! - show the boss what you are made of :-). Most people start at the bottom and work their way up, that is where you are know. Be glad you have a job and view everything as an "opportunity" rather than a "problem". You'll go a lot further and faster that way.

Goodluck,
Peter

P.S. Finding and fixing faults that other people have generated can be fun too - it is surprising how poorly many people are at finding problems in their own code, let alone someone elses! Fixing faults is a definite skill that some college degree can't teach you - you have to develop it the hard way i.e. from the bottom.

posted 08-05-2001 10:40 PM CT (US)         

Sounds to me like you need an attitude adjustment, and not the alcoholic kind. But then I'm biased, having spent 10 years in the business testing, and soon to be 10 years programming. I'm a better programmer for having spent time testing. And I was a better tester for having spent time programming prior to getting into the testing business. Both are equally challenging intellectually and both are valuable to the individual and the
customers (though some managers just don't get it).

As someone mentioned, there's a lot of cowboys out there that want to solve technical problems, but don't want to do the
rest of the job: documenting what they did, testing what they did, helping others on their teams, etc. Solving the technical
problems and grinding out the code is anywhere from a quarter to one half the job: all the rest still has to be done as well. If you think the above description fits you well, then get out now: fewer and fewer companies are willing to put up with the foibles and stupidity that such prima donnas foist on the rest of the workers. Few coworkers of such cowboys really like the cowboy because the coworkers often end up having to carry the cowboys weight. Any manager with sense will pick up on this whole dynamic and force the cowboy out the door as fast as they can.

Rather than looking at only the technical content of the job you're doing now, is there anything else about the environment you find yourself in: management, coworkers, general attitude about new hires, attitudes about testers, etc.; that might be influencing your resentment?

Failing a non-job-content cause, you may want to use this position as a stepping stone to consulting. A lot of cowboys end up as consultants; but the good ones also understand business, and must do effective marketing as well.

Good luck in your journey!

--
Jonathan Allan

Neither Mayo Clinic nor I speak for each other unless we explicitly say so. You should assume I am speaking only for myself. Please remove the antispam ".6809" to reply direct to me. Thanks!