The Old Joel on Software Forum: Part 4 (of 5)

Experiences working in QA?

I've recently been speaking with a fairly large, well-known software company about joining up. I'm about 6 months away from graduation, and haven't worked in software before.

I was initially interviewing for a position as a SW developer, but they understandably found my experience rather lacking. Now there is talk of offering me a job in QA at the same salary. I'm interested, but would really prefer to move on to software development at some point in my career.

Am I heading down the wrong path by getting into QA? What sort of experiences have people had doing this sort of work? As good as the money for this job is, I don't really want to get trapped in a "ghetto" - will this wind up limiting my options later on?

Your feedback would be appreciated. =)

Jimmy Jo-jo
Friday, April 2, 2004

If you have any weapons, sell them now. It will save a lot of people later...

Actually, many CS grads start out in that department, and work their way into coding. I think you should read an article of Joel's about being a worthless peon.

Gee, that sentence came out wrong. But it's a good article.

Capn' Kirk
Friday, April 2, 2004

Avoid QA. You're not going to get SW dev experience, so they're not going to move you over. And subsequent jobs at other companies will be based on your previous jobs, so you'd basically be stuck in QA forever...

Ron
Friday, April 2, 2004

I found QA to be mind-numbingly boring. I worked for a couple of months as a summer intern at a company doing QA. The company and people were great, just doing QA sucked. Basically: every new release you have to run a series of regression tests to make sure things that were working in the previous version all of a sudden didn’t work. If your program is sufficiently complex, this will take a long, long time (although they have automated methods that you can use to help speed this up).

When I wasn’t doing regression testing I was authoring QA test procedures – basically list every step you needed to perform in order to accomplish XYZ in the product. Again, some of these were very complex and some ran into 20-30 pages.

When you weren’t writing test procedures you were running them. Somewhere in there, you had to write up bugs that you found and how to duplicate them. The frustrating part was that we’d have forms which would have no data validation and then crash the program if you entered in something wrong. Now, some were trivial (enter 99 digits in a price field and it crashed) but most were met with “No customer would ever do this and we have 50 ‘show stopper’ bugs blocking release” and that seemed like a cop-out to me. If *I* accidentally typed in something I shouldn’t and it crashed I wouldn’t appreciate it – although it would be hard to ‘accidentally’ enter 99 digits.

But if you’re a programmer at heart you’ll hate not being able to code – those little tiny niggling bugs which were never going to get fixed could easily be tackled by an entry-level VB programmer – I wanted so much to be able to go in there and fix little things like that. I got some satisfaction by authoring a QA intranet which we’d use to track test procedure status, assign procedures to staff, etc.

MR
Friday, April 2, 2004

The QA guy in our software group is often found asleep at the keyboard. He hardly ever catches any bugs, but the project manager keeps him at it, so he can say we test before release.

Dormammu
Friday, April 2, 2004

>> I'm interested, but would really prefer to move on to software development at some point in my career.

That's what most QA people want, ie. move on to development since QA is so tedious, and development is more highly considered and rewarded.

Except they're paying you to do QA, not development, and management will not pay you to develop. Moral of the story: If you want to be a developer, don't ever get into QA.

Fred
Friday, April 2, 2004

Thanks everyone for the speedy feedback! Still interested in hearing from others, of course.

"Actually, many CS grads start out in that department, and work their way into coding. I think you should read an article of Joel's about being a worthless peon."

Capn - I've heard that a lot, but the guy doing the hiring actually admitted that most people they hire into QA stay there. I honestly had a hard time seeing how running 1,000 automated tests will help me along as a developer.

Everyone else, you've pretty much summed up my misgivings about going into QA. Perhaps I'll just move on.

Jimmy Jo-jo
Friday, April 2, 2004

No, QA and test people do not go into development, especially in the large software houses. It's a separate role and career path.

As others have said, if you really want to be a developer, and you're good, hold out for a development job.

Next time you go for a job, you will be up against guys with development backgrounds. If you've been working in QA for two years, you won't even be considered.

Dan
Friday, April 2, 2004

Check out the blog from a Microsoft Software Test Engineer at
http://blogs.msdn.com/chappell/

Anon
Friday, April 2, 2004

Interesting STE blog.

Thanks for the link Anon

lumberjack
Saturday, April 3, 2004

FWIW, I started out as a QA enginner and moved into development when my company needed coders. Worked out fine with me.

YMMV. Good luck.

Floridian
Saturday, April 3, 2004

First of all, QA's are NOT junior programmers! When done the way its supposed to be QA is its own discipline that requires better people skills, and a higher breadth (not depth) of technical knowledge. The management possibilites are also better (IMHO)

My first job was a developer and I have since moved to QA,
What qa means varies widely. In some place it means going through screens of web applications and verifying buttons work. In other places it means more challenging coding work than that of the developers themselves.

So first peice of advice make sure you are the right kind of QA. You want to hear words like White Box, Test Tools design, Configuration management and automation, Database, API testing, Automated testing NOT test plan verification, manual, black box (even though this term is meaningless now), GUI testing etc, also make sure the words you listen to are coming from your boss not a recruiter

For instance I've written application's that test other web apps (not via ui but on the http level). Applications that test the response times of data engines. Applications that generate that generate and chache huge amounts of data etc ... So it is not all mind numbing click button check status bar results

Second peice of advice, Expect breadth not depth. As a high end QA you will work without the same safety nets programmers do. You will be expected to complete projects quicker, with no one to test your code in a wider variety of languages, environments than programmers. Typically there is one technical QA and one "clicker type QA for every 2-10 programmers) which invariably means you will be doing code based testing of some sort for the work of more than one programmer and in addition if you have one or more "really junior clicker" QA working with you, you may have to set up environments, and run scripts for them.
So if a developer is a purist and perfectionist, you are a meatball surgeon, cobbling together code may only be run twice a year. What you write will never be pretty, but it must be effective.

Third piece of advice, Avoid performance testing like the plague. Since what you do is much more time sensitive than programming (managers wan't to ship the minute something is code complete). It will be a 24hr a day job, as you boss will expect you to restart 24+ hour tests in the middle of the night so as not to waste time. 2) NO ONE WILL EVER BELIEVE YOUR RESULTS! Whether you use a commercial tool or a hand rolled one, the validity of your tests will never ever be taken seriously!!! On the other hand, the minute performance sucks, you will be blamed, it is a hard thankless job!

the artist formerly known as prince
Saturday, April 3, 2004

Christopher Wells
Saturday, April 3, 2004

The artist,

just out of curiousity, when was the test code more complicated than the code you tested?

Floridian
Saturday, April 3, 2004

I can't find where I put that please quote.

But just to give one example, a Visual Test or Silk (with proper recovery,automated reports, external script based verfication, and run from a test harness) can be more complicated than the DB Form it is trying to test (in terms of points of potential failure, and vraity of code if not actual length).

Also, look at HTTP Unit, it is essentially an implementation of a http protocol from the inside out!

A Hand rolled performance testing app can be 10,000 LOC easy, before any tests are actually implemented, and excluding any libraries it uses.