Does QA suck, or, could AskMefi ever get sick of giving me career advice?
May 4, 2007 1:16 PM Subscribe
Everybody hates QA?
So, a job that I applied for aaages ago finally turned into an offer. Only last time I mentioned to you folks that I might be interested in doing QA, you seemed to be against it.
Is it really that bad? When I try to Google for more information I get lots of horror stories about high school grads earning minimum wage working 80-hour weeks for EA or similar companies, but this isn't that kind of a job. The QA department has little turnover and everyone in it I've met has made a career of testing (nobody aspires to be a developer; everybody's been doing this for years). So clearly not everyone hates QA, or at least not everyone hates all QA jobs. The company does ERM software that integrates with a bunch of other products, so I figure in the worst case I wouldn't be testing the same application every day. My boyfriend (who also works at this company) thinks the ERM aspect makes this job different from other QA positions, but I'm not convinced.
What are the plusses and minuses of QA? Is there such thing as a good manual QA gig? And (most importantly!) how do you know when you're looking at it? Over the weekend, I can ask the guys at this company any question I need to, so what do I need to find out?
Thanks!
So, a job that I applied for aaages ago finally turned into an offer. Only last time I mentioned to you folks that I might be interested in doing QA, you seemed to be against it.
Is it really that bad? When I try to Google for more information I get lots of horror stories about high school grads earning minimum wage working 80-hour weeks for EA or similar companies, but this isn't that kind of a job. The QA department has little turnover and everyone in it I've met has made a career of testing (nobody aspires to be a developer; everybody's been doing this for years). So clearly not everyone hates QA, or at least not everyone hates all QA jobs. The company does ERM software that integrates with a bunch of other products, so I figure in the worst case I wouldn't be testing the same application every day. My boyfriend (who also works at this company) thinks the ERM aspect makes this job different from other QA positions, but I'm not convinced.
What are the plusses and minuses of QA? Is there such thing as a good manual QA gig? And (most importantly!) how do you know when you're looking at it? Over the weekend, I can ask the guys at this company any question I need to, so what do I need to find out?
Thanks!
Developers hate QA because they point out bugs in the software.
Marketing hates QA because they take up time and hold up releases.
The Execs hate QA because the Developers shouldn't be creating buggy software to begin with.
Basically, everyone resents QA to a greater or lesser extent. At smaller companies, QA tends to be an entry-level job that people expect to move out of. If you've gotten a slot at a mature company with an entrenched QA presence, that will make it much better.
posted by mkultra at 1:34 PM on May 4, 2007
Marketing hates QA because they take up time and hold up releases.
The Execs hate QA because the Developers shouldn't be creating buggy software to begin with.
Basically, everyone resents QA to a greater or lesser extent. At smaller companies, QA tends to be an entry-level job that people expect to move out of. If you've gotten a slot at a mature company with an entrenched QA presence, that will make it much better.
posted by mkultra at 1:34 PM on May 4, 2007
Operations hates QA because they don't find the bugs and then our production environment is all crapped up.
posted by mckenney at 1:39 PM on May 4, 2007
posted by mckenney at 1:39 PM on May 4, 2007
It has been my experience that good QA people end up as developers while the morons/power trippers remain.
posted by zeoslap at 1:42 PM on May 4, 2007
posted by zeoslap at 1:42 PM on May 4, 2007
I work in QA at a great company which employs about 300 people. I mention that number to dissuade people from thinking that maybe QA can be great at small companies but not at large ones. The QA group is pretty well respected, though of course management often tries to compress our schedule to make up for time lost elsewhere in the development process. We are able to push back on that when we need to, though, without much hassle. All of my co-workers are great people that I enjoy working with, who like their jobs and work hard without any bullshit. Yes, some of us aspire to become developers eventually, I'm sure, but I don't see anything wrong with that. The developers here do not resent QA, and we have a really good working relationship with them both in and out of the office.
That said, this is basically the best-run and best-hired-for company I've ever worked at, so YMMV.
What you've described sounds like a totally reasonable work environment, if it's really true. The key question I would ask them about, in detail, is what their relationship with the development staff is like. Long-winded answers about that, not single-sentence ones, will give you the right idea.
posted by autojack at 1:48 PM on May 4, 2007 [1 favorite]
That said, this is basically the best-run and best-hired-for company I've ever worked at, so YMMV.
What you've described sounds like a totally reasonable work environment, if it's really true. The key question I would ask them about, in detail, is what their relationship with the development staff is like. Long-winded answers about that, not single-sentence ones, will give you the right idea.
posted by autojack at 1:48 PM on May 4, 2007 [1 favorite]
The Execs hate QA because the Developers shouldn't be creating buggy software to begin with.
No, the Execs love good QA teams because they help keep the Developers honest. Also, its much much less of a headache to have QA tell you about a problem than your customer.
I agree that at large companies (e.g. Enterprise Software) QA is valued. The problem is that a lot of good QA people become a bit annoyed as not getting percieved as "creators" in the same way that Developers are. But the workload itself can be interesting since you have to be on top of all the product features. This skillset of course is why many QA folks use this as a stepping stone...
posted by vacapinta at 1:48 PM on May 4, 2007
No, the Execs love good QA teams because they help keep the Developers honest. Also, its much much less of a headache to have QA tell you about a problem than your customer.
I agree that at large companies (e.g. Enterprise Software) QA is valued. The problem is that a lot of good QA people become a bit annoyed as not getting percieved as "creators" in the same way that Developers are. But the workload itself can be interesting since you have to be on top of all the product features. This skillset of course is why many QA folks use this as a stepping stone...
posted by vacapinta at 1:48 PM on May 4, 2007
What do you do now?
I've run a small QA dept before for a software startup. The folks who were the happiest (and the best at their jobs) really wanted to be QA, and weren't using it as a stepping stone to to being a developer.
They liked the planning aspect, the puzzle aspect.
The ones who were best were the ones who were able to put together great test harnesses and knew how to break an application in such as a way that it was clear to the dev org why there was a problem.
I wouldn't use QA as a stepping stone to dev unless you have some other thing to work on (language, schooling to finish, etc..) since the dev market seems to be hot enough right now you don't need to do that.
What would you be doing? Whitebox testing? Blackbox testing, writing test cases/test plans?
clicky clicky GUI testing all day?
reading your previous post sounds like it might be worth giving it a try.
posted by bottlebrushtree at 1:52 PM on May 4, 2007
I've run a small QA dept before for a software startup. The folks who were the happiest (and the best at their jobs) really wanted to be QA, and weren't using it as a stepping stone to to being a developer.
They liked the planning aspect, the puzzle aspect.
The ones who were best were the ones who were able to put together great test harnesses and knew how to break an application in such as a way that it was clear to the dev org why there was a problem.
I wouldn't use QA as a stepping stone to dev unless you have some other thing to work on (language, schooling to finish, etc..) since the dev market seems to be hot enough right now you don't need to do that.
What would you be doing? Whitebox testing? Blackbox testing, writing test cases/test plans?
clicky clicky GUI testing all day?
reading your previous post sounds like it might be worth giving it a try.
posted by bottlebrushtree at 1:52 PM on May 4, 2007
Response by poster: A lot of people mention interdepartmental relationships, so it would probably be relevant for me to say that the development team has about 10-12 members and the QA team has about 8. My boyfriend is one of the developers, and his boss, who I'm on friendly terms with, pushed heavily for the company to hire me.
posted by phoenixy at 1:53 PM on May 4, 2007
posted by phoenixy at 1:53 PM on May 4, 2007
In order to be any good at QA, you have to understand both the technical and the business aspects of the system.
If you understand the technical and business aspects of the system, you can earn significantly more money, have a better authority/responsibility ratio, and be on the 'critical path' promotion/escalation ladder by being a developer, manager or business analyst.
So the cream of QA is naturally and organically constantly getting skimmed off to put their skills to better use elsewhere.
This leaves the people who don't understand the technical or business aspects of the system. These people generally produce bad QA output, don't catch problems in dev, concentrate on the wrong thing, and force developers and managers to spend weeks explaining concepts that they feel are both simple and obvious.
As a result, QA is generally high stress, unrewarding, and looked down on by everyone else in the company.
posted by felix at 1:53 PM on May 4, 2007 [2 favorites]
If you understand the technical and business aspects of the system, you can earn significantly more money, have a better authority/responsibility ratio, and be on the 'critical path' promotion/escalation ladder by being a developer, manager or business analyst.
So the cream of QA is naturally and organically constantly getting skimmed off to put their skills to better use elsewhere.
This leaves the people who don't understand the technical or business aspects of the system. These people generally produce bad QA output, don't catch problems in dev, concentrate on the wrong thing, and force developers and managers to spend weeks explaining concepts that they feel are both simple and obvious.
As a result, QA is generally high stress, unrewarding, and looked down on by everyone else in the company.
posted by felix at 1:53 PM on May 4, 2007 [2 favorites]
I'm a developer, and I've managed projects. If it makes you feel better, I will tell you that a good QA person is worth two good developers to me. I've also found that finding good developers is hard, but finding good QA people is pretty much impossible.
As for a good QA gig, I think the most important thing is that the QA dept. has to have some level of power. Some questions you may want to get answered:
Does QA have the power to hold up releases despite external pressures (such as those mkultra mentioned)? If you are continually railroaded, there's no point to your job, and you will hate it. Is QA given the staff and tools necessary to do their job effectively? Are there sophisticated defect tracking tools? Are there enough testers to thoroughly test the product? Are there regular deployments of the application to testers?
Here's a huge one: can testers interact directly with developers? Your life will be a living hell if you can't take your issues directly to a developer. A common management theme is to pit testers and developers against each other. PHBs encourage the developers to do their best to "get it through QA" and then turn around and encourage QA to "put those sloppy developers in their place". All communication is then supposed to be through a bug database, and the number of defects found are scored against defects resolved. All it does is encourage developers to try to hide their bugs rather than really try to make a quality product. It also encourages QA to nitpick rather than concentrate on what matters.
OK, now I'm ranting.
But anyway, QA can be a thankless job, but if you take it seriously and really make an effort to deliver a quality project, you can do well. Especially if you really familiarize yourself with automated testing tools, you can easily become an independent consultant pulling in $80-$120/hour.
What do you want the job to be? Are you looking to start a career or pay the bills?
posted by AaRdVarK at 1:54 PM on May 4, 2007 [1 favorite]
As for a good QA gig, I think the most important thing is that the QA dept. has to have some level of power. Some questions you may want to get answered:
Does QA have the power to hold up releases despite external pressures (such as those mkultra mentioned)? If you are continually railroaded, there's no point to your job, and you will hate it. Is QA given the staff and tools necessary to do their job effectively? Are there sophisticated defect tracking tools? Are there enough testers to thoroughly test the product? Are there regular deployments of the application to testers?
Here's a huge one: can testers interact directly with developers? Your life will be a living hell if you can't take your issues directly to a developer. A common management theme is to pit testers and developers against each other. PHBs encourage the developers to do their best to "get it through QA" and then turn around and encourage QA to "put those sloppy developers in their place". All communication is then supposed to be through a bug database, and the number of defects found are scored against defects resolved. All it does is encourage developers to try to hide their bugs rather than really try to make a quality product. It also encourages QA to nitpick rather than concentrate on what matters.
OK, now I'm ranting.
But anyway, QA can be a thankless job, but if you take it seriously and really make an effort to deliver a quality project, you can do well. Especially if you really familiarize yourself with automated testing tools, you can easily become an independent consultant pulling in $80-$120/hour.
What do you want the job to be? Are you looking to start a career or pay the bills?
posted by AaRdVarK at 1:54 PM on May 4, 2007 [1 favorite]
Not everybody hates QA. As a video game producer, I see QA as my best friend and number one ass-saving resource. Sure, some times they find things I'd prefer not to have heard about, but I figure it's better to know than not to know. Some teams develop antagonism toward QA for reasons mentioned, others because QA people tend to be younger and less job savvy, so they will say or do things in a less than professional manner. However, on the whole, my feeling is that if people are hating on QA for doing their job, then they've completely missed the point.
Now for the pros and cons:
pros:
good way to get into an industry
good way to see all aspects of the product, probably to a degree nobody else does
good way to see the process from beginning to end
always plenty of over time
relatively low stress: you do your job, but you're not asked to make tough calls about what happens because of your findings
cons:
low pay
low status
can be an unprofessional environment (also a plus for some)
can be difficult to break out of the "QA ghetto" though it can be done
sometimes means low chance for advancement
repetitive work (the reason I couldn't do QA)
Probably more to be said on this, but that's just off the top of my head.
(on preview, what felix and AaRdVarK said)
posted by ga$money at 1:57 PM on May 4, 2007
Now for the pros and cons:
pros:
good way to get into an industry
good way to see all aspects of the product, probably to a degree nobody else does
good way to see the process from beginning to end
always plenty of over time
relatively low stress: you do your job, but you're not asked to make tough calls about what happens because of your findings
cons:
low pay
low status
can be an unprofessional environment (also a plus for some)
can be difficult to break out of the "QA ghetto" though it can be done
sometimes means low chance for advancement
repetitive work (the reason I couldn't do QA)
Probably more to be said on this, but that's just off the top of my head.
(on preview, what felix and AaRdVarK said)
posted by ga$money at 1:57 PM on May 4, 2007
I've worked at a 500-person company where the QA department had relatively low turnover and seemed to be pretty well respected. There are inevitable tensions (QA: "hey, I found a bug!" Developer: "that's impossible, are you sure you did the install/setup correctly," followed by half an hour of patronizing, etc), but these can be either the exception or the rule depending on the environment. It's not bad everywhere, but it's definitely not good everywhere.
I imagine you've done this, but if not: just ask your boyfriend to give you the lowdown, not only on how the QAs perceive their job, but also how they're perceived by everyone else in the organization. That should give you an idea of how the working conditions will be, from multiple perspectives.
Oh yeah, I'm assuming that inter-departmental static would be the main drawback for you; I personally don't think I would enjoy doing QA, but if you're familiar with the substance of the work and want to try it, there's no good reason to hold back as long as the interpersonal environment won't be toxic.
posted by rkent at 1:58 PM on May 4, 2007
I imagine you've done this, but if not: just ask your boyfriend to give you the lowdown, not only on how the QAs perceive their job, but also how they're perceived by everyone else in the organization. That should give you an idea of how the working conditions will be, from multiple perspectives.
Oh yeah, I'm assuming that inter-departmental static would be the main drawback for you; I personally don't think I would enjoy doing QA, but if you're familiar with the substance of the work and want to try it, there's no good reason to hold back as long as the interpersonal environment won't be toxic.
posted by rkent at 1:58 PM on May 4, 2007
Response by poster: Bottlebrushtree:
What do you do now?
I do "consulting," but it would be more accurate to say I do very easy, somewhat tedious, mostly mindless, important in the context of my office but not at all in that of the larger universe, work with websites and Excel and have little interaction with other people. One of my worries is that QA would be basically a reiteration of my current job.
Whitebox testing? Blackbox testing, writing test cases/test plans?
clicky clicky GUI testing all day?
Writing test cases and plans, blackbox testing, and clicky clicky. And, I get the impression, a lot of setting up test environments.
posted by phoenixy at 2:01 PM on May 4, 2007
What do you do now?
I do "consulting," but it would be more accurate to say I do very easy, somewhat tedious, mostly mindless, important in the context of my office but not at all in that of the larger universe, work with websites and Excel and have little interaction with other people. One of my worries is that QA would be basically a reiteration of my current job.
Whitebox testing? Blackbox testing, writing test cases/test plans?
clicky clicky GUI testing all day?
Writing test cases and plans, blackbox testing, and clicky clicky. And, I get the impression, a lot of setting up test environments.
posted by phoenixy at 2:01 PM on May 4, 2007
People shit on QA for a variety of reasons, mostly because there's an automatic assumption amongst arrogant software engineers that they're in it because they're stupid or a lousy programmer. I mean, who wouldn't want the 60 hour deadline driven work weeks that a lot of us deal with? Unfortunately, that attitude tends to drive away the good QA people, the ones who (unlike most users) actually know how to file a good bug report and find the unlikely, but important, corner cases.
I think you might enjoy QA, although ERM testing sounds like it's one long slog through the mud. I'd suggest looking for a large company that sells a number of different software products, and ask where QA fits in the management structure. Is it a team that tests all of the software the company sells, do individuals get assigned to one product during the lifecycle of the product, etc. The last thing you would want is to be testing point releases and patches for the same miserable product all year.
You might also look into using QA as a stepping stone to software security auditing. It's kinda like QA, only you're treated like a rockstar.
posted by cmonkey at 2:12 PM on May 4, 2007
I think you might enjoy QA, although ERM testing sounds like it's one long slog through the mud. I'd suggest looking for a large company that sells a number of different software products, and ask where QA fits in the management structure. Is it a team that tests all of the software the company sells, do individuals get assigned to one product during the lifecycle of the product, etc. The last thing you would want is to be testing point releases and patches for the same miserable product all year.
You might also look into using QA as a stepping stone to software security auditing. It's kinda like QA, only you're treated like a rockstar.
posted by cmonkey at 2:12 PM on May 4, 2007
I worked as a tester for Agilent testing a large piece of java software. It was on of the better jobs I've had. We were close to the developers, and they listened to us when we found bugs. There was a little of everything in the job, going from writing test plans to automation testing, to white box testing, to black box testing. We were all over the place, and we got a lot done.
I'd say it very much depends on where you are and the culture of the established QA team to determine how life will be there. I've also worked for a smaller company as an intern that didn't do much in the way of testing. They had 2-3 interns at any given time and just worked us 15 hours a week. We simply didn't have enough time to make an impact on the bugs coming in.
To get on the high-paid and (in my opinion) fun path of testing, get good at perl. Or ruby. Or python. Well, you get the idea. Learn to code, and learn how to automate stuff. Even though it is rarely really needed, it's also a pretty easy sell to a boss, or in an interview.
posted by cschneid at 2:30 PM on May 4, 2007
I'd say it very much depends on where you are and the culture of the established QA team to determine how life will be there. I've also worked for a smaller company as an intern that didn't do much in the way of testing. They had 2-3 interns at any given time and just worked us 15 hours a week. We simply didn't have enough time to make an impact on the bugs coming in.
To get on the high-paid and (in my opinion) fun path of testing, get good at perl. Or ruby. Or python. Well, you get the idea. Learn to code, and learn how to automate stuff. Even though it is rarely really needed, it's also a pretty easy sell to a boss, or in an interview.
posted by cschneid at 2:30 PM on May 4, 2007
I worked in a large company that had a number of full-time QA engineers, and a number of temporary contractors who also did QA. The full-timers definitely seemed like a smart, competent bunch, very chill and much cooler than developers. The contractors generally weren't fully fluent in English and were constantly reporting bugs to me that were clearly works in progress (ie "The button says 'PUT LABEL HERE' instead of having a label" - er, yes, I know, and that realllly didn't need a bug report marked urgent). I wouldn't have wanted to work with those people, and I think a lot of the disrespect was because the company didn't value them enough to hire really competent people. Furthermore, the full-time QA people seemed to spend a lot of time managing the contractors and picking up after them, which seemed like herding cats.
posted by crinklebat at 2:31 PM on May 4, 2007
posted by crinklebat at 2:31 PM on May 4, 2007
Seconding what felix said.
I manage the tech support team at my company. I find myself constantly having to school the QA team because they don't know our system nor the business we support. The support team is constantly having to help them test projects, train and retrain on the same material, etc.
It does boil down to getting good people who learn quickly and able to understand what's going on. I strongly suggest trying to get more info about the dynamics of the team and management.
posted by mamaquita at 2:58 PM on May 4, 2007
I manage the tech support team at my company. I find myself constantly having to school the QA team because they don't know our system nor the business we support. The support team is constantly having to help them test projects, train and retrain on the same material, etc.
It does boil down to getting good people who learn quickly and able to understand what's going on. I strongly suggest trying to get more info about the dynamics of the team and management.
posted by mamaquita at 2:58 PM on May 4, 2007
No, the Execs love good QA teams because they help keep the Developers honest. Also, its much much less of a headache to have QA tell you about a problem than your customer.
Bad execs hate QA because the developers shouldn't be creating buggy software to begin with.
Good execs understand that bugs and QA cycles are inherent in software development, and love good QA teams.
posted by secret about box at 3:12 PM on May 4, 2007
Bad execs hate QA because the developers shouldn't be creating buggy software to begin with.
Good execs understand that bugs and QA cycles are inherent in software development, and love good QA teams.
posted by secret about box at 3:12 PM on May 4, 2007
I've done QA as an intern/co-op and I'll second what AaRdVarK had to say. In particular:
Does QA have the power to hold up releases despite external pressures (such as those mkultra mentioned)? If you are continually railroaded, there's no point to your job, and you will hate it.
&
can testers interact directly with developers? Your life will be a living hell if you can't take your issues directly to a developer.
posted by juv3nal at 3:31 PM on May 4, 2007
Does QA have the power to hold up releases despite external pressures (such as those mkultra mentioned)? If you are continually railroaded, there's no point to your job, and you will hate it.
&
can testers interact directly with developers? Your life will be a living hell if you can't take your issues directly to a developer.
posted by juv3nal at 3:31 PM on May 4, 2007
I worked in QA for 9 years at various companies before moving into product management. I still do a lot of QA work at our little startup, and I still love it most of the time. If you're detail-oriented and not afraid to ask questions of engineers, you can have a great time at a QA job.
I've always approached QA from an end-user advocacy perspective, with the associated responsibilities. Engineers will be the first to admit that they don't keep end-users in mind when coding. QA is there to help keep that focus, whether the end-user is a consumer or another coder who will be using the libraries the engineers are writing.
This means you have a responsibility to advocate for quality early in the design process, to write bugs that are clear and helpful to the engineers, and especially to pick your battles. QA can get really frustrating really fast if you think every bug is a big deal; and of course the rest of the team will start to resent you. If you log everything you find but are realistic about bug severities, you'll be appreciated by everyone on the team.
QA can get really tedious if you spend most of your time configuring test boxes, if you are stuck QA-ing the same product forever, and especially if you don't have a consistent and responsible schedule for development builds.
posted by danblaker at 3:56 PM on May 4, 2007
I've always approached QA from an end-user advocacy perspective, with the associated responsibilities. Engineers will be the first to admit that they don't keep end-users in mind when coding. QA is there to help keep that focus, whether the end-user is a consumer or another coder who will be using the libraries the engineers are writing.
This means you have a responsibility to advocate for quality early in the design process, to write bugs that are clear and helpful to the engineers, and especially to pick your battles. QA can get really frustrating really fast if you think every bug is a big deal; and of course the rest of the team will start to resent you. If you log everything you find but are realistic about bug severities, you'll be appreciated by everyone on the team.
QA can get really tedious if you spend most of your time configuring test boxes, if you are stuck QA-ing the same product forever, and especially if you don't have a consistent and responsible schedule for development builds.
posted by danblaker at 3:56 PM on May 4, 2007
A good QA person is like gold. Unfortunately, only about 10% of QA people are that good, because it's a really specialized and intense skill set and most companies don't budget enough for QA, either for salaries or training, so people who are really good move on to other jobs, and the people who are clicky clicky monkeys remain. This is sad because a good QA department can really save your ass.
posted by matildaben at 5:16 PM on May 4, 2007
posted by matildaben at 5:16 PM on May 4, 2007
I've worked in QA for almost ten years now and love my job. It's like solving a new puzzle everyday, each day is new and challenging. I work for a small startup (~150 people) so there's too much work but that's true for everyone in the company.
To comment on Gasmonkey's comments:
Low pay - Not true in my experience but 4/5 of our team has master's degrees. I've averaged 10% better pay each year over the last nine.
Low status - Maybe, but do you care?
Can be an unprofessional environment (also a plus for some) - Not sure where that's coming from, QA folks have to be much more professional than developers because process is so important. QA is useless if it can't make reproducible results so you have to be sticklers about your team processes and personal processes. If you report a bug to development, you have to be damn sure that you know how to recreate that bug and document that sequence meticulously.
Can be difficult to break out of the "QA ghetto" though it can be done - Somewhat true but it's only an issue if you don't like QA.
Sometimes means low chance for advancement - See above.
Repetitive work (the reason I couldn't do QA) - I disagree with this one totally. Developers usually only work on one module at a time and have to have a very "heads down" view of the product and often get very specialized. QA people have to jump all over the place. I specify tests, design tests, write tests, write tools, triage test failures, work with development, support, architects, marketing and system admins. In only two jobs, I've written code in C, C++, Java, Perl, Shell, TCL, Python, Expect, PHP, YACC/Lex and a couple of home grown languages.
The one thing that I don't do much of and neither does the rest of the QA team, is run tests. Thats all automated, we write the tests and file them into the test scheduler.
Lastly to comment on mkultra, it doesn't matter who hates QA in the company because the customers love QA. If I don't do my job and find bugs before the customers find them in the field, then I'm in trouble. But if the customer plugs in the system, fires it up and everything 'just works', that's because QA did its job. And then everyone is happy.
posted by octothorpe at 5:23 PM on May 4, 2007
To comment on Gasmonkey's comments:
Low pay - Not true in my experience but 4/5 of our team has master's degrees. I've averaged 10% better pay each year over the last nine.
Low status - Maybe, but do you care?
Can be an unprofessional environment (also a plus for some) - Not sure where that's coming from, QA folks have to be much more professional than developers because process is so important. QA is useless if it can't make reproducible results so you have to be sticklers about your team processes and personal processes. If you report a bug to development, you have to be damn sure that you know how to recreate that bug and document that sequence meticulously.
Can be difficult to break out of the "QA ghetto" though it can be done - Somewhat true but it's only an issue if you don't like QA.
Sometimes means low chance for advancement - See above.
Repetitive work (the reason I couldn't do QA) - I disagree with this one totally. Developers usually only work on one module at a time and have to have a very "heads down" view of the product and often get very specialized. QA people have to jump all over the place. I specify tests, design tests, write tests, write tools, triage test failures, work with development, support, architects, marketing and system admins. In only two jobs, I've written code in C, C++, Java, Perl, Shell, TCL, Python, Expect, PHP, YACC/Lex and a couple of home grown languages.
The one thing that I don't do much of and neither does the rest of the QA team, is run tests. Thats all automated, we write the tests and file them into the test scheduler.
Lastly to comment on mkultra, it doesn't matter who hates QA in the company because the customers love QA. If I don't do my job and find bugs before the customers find them in the field, then I'm in trouble. But if the customer plugs in the system, fires it up and everything 'just works', that's because QA did its job. And then everyone is happy.
posted by octothorpe at 5:23 PM on May 4, 2007
Response by poster: cmonkey:
although ERM testing sounds like it's one long slog through the mud
Very curious--why?
By the way, I should reiterate to everyone that this is a manual testing position, although a major goal of mine would be to learn to do as much automation as possible as soon as possible, and the group seems reasonably supportive of that.
posted by phoenixy at 6:35 PM on May 4, 2007
although ERM testing sounds like it's one long slog through the mud
Very curious--why?
By the way, I should reiterate to everyone that this is a manual testing position, although a major goal of mine would be to learn to do as much automation as possible as soon as possible, and the group seems reasonably supportive of that.
posted by phoenixy at 6:35 PM on May 4, 2007
It just sounds painful (without actually knowing the specific application) because a lot of enterprise software tends to have pretty bad interfaces, a rigid expectation of workflow, and a focus on point releases rather than major releases. But that's definitely not true for every enterprisy app, and it sounds like you'd enjoy it a lot more than your current job.
posted by cmonkey at 8:10 PM on May 4, 2007
posted by cmonkey at 8:10 PM on May 4, 2007
Some common BAD dev attitudes towards QA:
"It's easy to find the bugs. Fixing them is the hard part."
"I don't need to fix the problem until it's written up, so why make it easier to write up?"
"They're slacking off since I'm not seeing any bugs reported."
Would drive me nuts if I was QA.
posted by smackfu at 9:08 PM on May 4, 2007
"It's easy to find the bugs. Fixing them is the hard part."
"I don't need to fix the problem until it's written up, so why make it easier to write up?"
"They're slacking off since I'm not seeing any bugs reported."
Would drive me nuts if I was QA.
posted by smackfu at 9:08 PM on May 4, 2007
I think one big thing that determines whether QA is a hellish job is whether it's in an adversarial position to dev (and to the release-schedule people, whoever they are in that company).
Speaking as a developer, I love having good QA folk, by which I mean someone whom I feel is working with me to produce the best possible product. I try to test my stuff pretty thoroughly before it leaves my desk but it's good knowing that QA has my back, as it were: my job is not to produce code, it's to produce good code, and QA helps a lot. On the other hand, bad QA (reporting nonbugs, not testing anything beyond minimal functionality, etc.) can be just an annoying time-sink that generates resentment. I'm glad that I've never worked at a place where the development/QA relationship has gone really sour ("gotta cut those devs down to size", "the QA people are just wannabe devs", "the engineers don't think about the end user", "the QA just makes more work for the devs", etc).
As an aside, I'd recommend against planning to do QA as a stepping-stone to development unless everybody involved knows that's the idea from the start. It just feeds the "QA must be stupid or else they'd be in engineering" stereotype, and it makes companies wary of hiring actual smart people for QA because they're afraid they'll try to migrate into development.
posted by hattifattener at 1:32 AM on May 5, 2007
Speaking as a developer, I love having good QA folk, by which I mean someone whom I feel is working with me to produce the best possible product. I try to test my stuff pretty thoroughly before it leaves my desk but it's good knowing that QA has my back, as it were: my job is not to produce code, it's to produce good code, and QA helps a lot. On the other hand, bad QA (reporting nonbugs, not testing anything beyond minimal functionality, etc.) can be just an annoying time-sink that generates resentment. I'm glad that I've never worked at a place where the development/QA relationship has gone really sour ("gotta cut those devs down to size", "the QA people are just wannabe devs", "the engineers don't think about the end user", "the QA just makes more work for the devs", etc).
As an aside, I'd recommend against planning to do QA as a stepping-stone to development unless everybody involved knows that's the idea from the start. It just feeds the "QA must be stupid or else they'd be in engineering" stereotype, and it makes companies wary of hiring actual smart people for QA because they're afraid they'll try to migrate into development.
posted by hattifattener at 1:32 AM on May 5, 2007
I wish my company had a QA person or deparment. Would help avoid so many headaches....
posted by melt away at 7:00 AM on May 5, 2007
posted by melt away at 7:00 AM on May 5, 2007
I've worked in QA on big enterprise software in a structured (CMMI) development environment, and nobody "hated QA." We had a good relationship with the devs, everybody realized it was an important part of the process...it was fine. It was fairly easy work, it paid well, the only thing I didn't like about it was that there wasn't a lot of client interaction, and that's what I enjoy.
I could imagine that doing QA in an environment that wasn't heavily structured, and where QA wasn't deeply built-in to the whole lifecycle process and was instead just tacked on, could be miserable. I wouldn't ever want to QA any of these "agile" methodologies.
If your management or client constantly cuts corners, staffing, or resources, away from QA, then I would run, not walk, away from that project. (Even if I wasn't going to be doing QA on it -- it's a sign that the whole thing is just going to be a Death March.)
posted by Kadin2048 at 10:16 AM on May 5, 2007
I could imagine that doing QA in an environment that wasn't heavily structured, and where QA wasn't deeply built-in to the whole lifecycle process and was instead just tacked on, could be miserable. I wouldn't ever want to QA any of these "agile" methodologies.
If your management or client constantly cuts corners, staffing, or resources, away from QA, then I would run, not walk, away from that project. (Even if I wasn't going to be doing QA on it -- it's a sign that the whole thing is just going to be a Death March.)
posted by Kadin2048 at 10:16 AM on May 5, 2007
As a developer (enterprise banking applications), I love QA. Coders tend to get a motherly attitude towards their code: they instinctually know not to click lots of buttons at the same time, or they avoid entering in bad data, or they just get so wrapped up in a particular section that they lose all objective ability to test it properly.
That's where good QA is a godsend. I can't count the number of times I've been told of a *major* bug by QA, something that I completely, utterly missed, but that would have dire consequences if it hadn't been caught. QA saves asses.
A lot of it depends on the work environment, obviously. Where I work, we have a hands-off attitude to QA. They're allowed to do whatever they need to in order to help them test. Need a new box? You got it. Want to try writing some test scripts in a new language for fun? Go right on ahead. Whatever you need to do, do it. Just find the bugs. That's our attitude.
The most important aspect to finding bugs, IMHO, is reproducability. QA doesn't have to know the code, but it's vital that we (developers) have a set of operations that will recreate them. And if a tester wants to talk to me, I'm just down the hall, and my door is always open. Frankly, you need an open dialogue between devs and testers. If the company you're looking at doesn't have this kind of raport, I'd move on. Because in the end, sign-off from QA means their necks are on the line if something breaks. You don't want any barriers in your way.
posted by Civil_Disobedient at 12:47 PM on May 5, 2007
That's where good QA is a godsend. I can't count the number of times I've been told of a *major* bug by QA, something that I completely, utterly missed, but that would have dire consequences if it hadn't been caught. QA saves asses.
A lot of it depends on the work environment, obviously. Where I work, we have a hands-off attitude to QA. They're allowed to do whatever they need to in order to help them test. Need a new box? You got it. Want to try writing some test scripts in a new language for fun? Go right on ahead. Whatever you need to do, do it. Just find the bugs. That's our attitude.
The most important aspect to finding bugs, IMHO, is reproducability. QA doesn't have to know the code, but it's vital that we (developers) have a set of operations that will recreate them. And if a tester wants to talk to me, I'm just down the hall, and my door is always open. Frankly, you need an open dialogue between devs and testers. If the company you're looking at doesn't have this kind of raport, I'd move on. Because in the end, sign-off from QA means their necks are on the line if something breaks. You don't want any barriers in your way.
posted by Civil_Disobedient at 12:47 PM on May 5, 2007
Oh, I'd also concur with the inability to move from QA -> Developer. (At my company) it's not because of any superiority complex -- plenty of good QA might make good developers, but if they wanted to go that route we'd expect them to go through the regular applicant process like everyone else. Naturally, if you've already got a good relationship with the developers you'd be working with, that will certainly be an advantage over other applicants. And if you want to use a QA position to enhance your programming ability, that's great, but it's not a "natural" stepping-stone that will let you skip the whole hiring process (obviously, YMMV).
posted by Civil_Disobedient at 12:58 PM on May 5, 2007
posted by Civil_Disobedient at 12:58 PM on May 5, 2007
it doesn't matter who hates QA in the company because the customers love QA.
This is not always the case. In an organization where QA does not have the power to delay releases when it sees fit, QA may very well find bugs only to have them end up in shipped product anyways to meet a release schedule but customers are just going to pin it on QA for not finding them, not whoever else for shipping with known issues.
posted by juv3nal at 4:40 PM on May 5, 2007 [1 favorite]
This is not always the case. In an organization where QA does not have the power to delay releases when it sees fit, QA may very well find bugs only to have them end up in shipped product anyways to meet a release schedule but customers are just going to pin it on QA for not finding them, not whoever else for shipping with known issues.
posted by juv3nal at 4:40 PM on May 5, 2007 [1 favorite]
It sounds like you've got a great opportunity to get a great deal of information about the job before you jump into it--I can give you a hundred annoying questions to ask:
What are their release cycles are like? Is it common for development schedules to slip, and if they do, does the release date slip as well (or is QA expected to work 100 hour weeks to make up for the Dev slip)? Who plans and coordinates releases? Project managers? Product Managers? Development managers (I call this "fox-in-the-henhouse project management," but it can work...)? Does QA provide project estimates when releases are planned and are they respected or laughed off?
What are the hours like for QA staff? Are there times where Development passes the build to QA on Friday nights at 7pm and the QA testers are expected to work through the weekend? Patch releases and other types of fire-drills--how often do they happen and when they do, what's the process in those situations? You probably want to know if the job will eat through your life like corrosive acid. (Though, if your boyfriend isn't working insane hours, it's likely you'll be fine as well--especially if you're working for a mature company.)
Does your boyfriend speak highly of the testers he currently works with? Where are QA staff situated in relation to developers--in the same area, can you overhear 'em when they talk about a major change? How much interaction happens between QA and development? Is it the kind of environment where they stop by and shoot-the-sh1t with you or does communication only occur via email and bug-tracking?
Does the QA department do any automated testing? If so, what kind of software/coding language(s) do they use? Do the developers do any automated testing? Do the software engineers perform unit tests or otherwise qualify software before throwing it over the fence? What bug tracking software does the QA department use? Is it integrated with source control? What's the bug process, are there weekly or bi-weekly scrubs? What percentage of bugs are filed by QA vs. development staff? Who controls CM--QA or Dev or something else? Does QA have insight into check-ins? How tightly controlled is that?
Are you going to be working on the same product or do you get a chance to jump around and learn new things? Is training available? Do they train you on the product and any related technologies when you start up? What about new features that use emerging technologies? Does the company pay for training or do they expect you to figure it out on your own on off-hours?
What about test environments--does QA have a dedicated lab that they control? What kind of equipment is available? (In two cases, talking with folks lately, I've heard of companies where QA has no control over the testbed, which I completely don't understand.) How many systems will be under your purvey? Do you get to play with hardware?
How does QA plan their releases? Do they get early builds to write tests from or just requirements docs? Are the requirements good enough to write tests from or is it all sort of up in the air until you get the software in your hands? Do you get time to write test cases or are schedules compressed such that you write them as you run them?
Maybe too many questions, huh? ;) I don't think there are any "right" or "wrong" answers to the questions above--the negative answers ensure you won't be bored (but will work too much, maybe drink too much, and get gray hair--but that's free highlights, right? Right?!?); positive answers might make the place a little too boring--it all depends on what you're looking for.
posted by jenh at 9:08 PM on May 5, 2007 [2 favorites]
What are their release cycles are like? Is it common for development schedules to slip, and if they do, does the release date slip as well (or is QA expected to work 100 hour weeks to make up for the Dev slip)? Who plans and coordinates releases? Project managers? Product Managers? Development managers (I call this "fox-in-the-henhouse project management," but it can work...)? Does QA provide project estimates when releases are planned and are they respected or laughed off?
What are the hours like for QA staff? Are there times where Development passes the build to QA on Friday nights at 7pm and the QA testers are expected to work through the weekend? Patch releases and other types of fire-drills--how often do they happen and when they do, what's the process in those situations? You probably want to know if the job will eat through your life like corrosive acid. (Though, if your boyfriend isn't working insane hours, it's likely you'll be fine as well--especially if you're working for a mature company.)
Does your boyfriend speak highly of the testers he currently works with? Where are QA staff situated in relation to developers--in the same area, can you overhear 'em when they talk about a major change? How much interaction happens between QA and development? Is it the kind of environment where they stop by and shoot-the-sh1t with you or does communication only occur via email and bug-tracking?
Does the QA department do any automated testing? If so, what kind of software/coding language(s) do they use? Do the developers do any automated testing? Do the software engineers perform unit tests or otherwise qualify software before throwing it over the fence? What bug tracking software does the QA department use? Is it integrated with source control? What's the bug process, are there weekly or bi-weekly scrubs? What percentage of bugs are filed by QA vs. development staff? Who controls CM--QA or Dev or something else? Does QA have insight into check-ins? How tightly controlled is that?
Are you going to be working on the same product or do you get a chance to jump around and learn new things? Is training available? Do they train you on the product and any related technologies when you start up? What about new features that use emerging technologies? Does the company pay for training or do they expect you to figure it out on your own on off-hours?
What about test environments--does QA have a dedicated lab that they control? What kind of equipment is available? (In two cases, talking with folks lately, I've heard of companies where QA has no control over the testbed, which I completely don't understand.) How many systems will be under your purvey? Do you get to play with hardware?
How does QA plan their releases? Do they get early builds to write tests from or just requirements docs? Are the requirements good enough to write tests from or is it all sort of up in the air until you get the software in your hands? Do you get time to write test cases or are schedules compressed such that you write them as you run them?
Maybe too many questions, huh? ;) I don't think there are any "right" or "wrong" answers to the questions above--the negative answers ensure you won't be bored (but will work too much, maybe drink too much, and get gray hair--but that's free highlights, right? Right?!?); positive answers might make the place a little too boring--it all depends on what you're looking for.
posted by jenh at 9:08 PM on May 5, 2007 [2 favorites]
As an Automated Tester of Enterprise Banking applications, I can tell you that, after the relationship with development, the next most important thing is Requirements. If the requirements aren't clear then many bugs turn into fights about what is 'supposed' to happen.
Following that, I'd look at what the expectations of management are, If you hear anything about bug-count requirements, RUN.
Alos, owrkign in a shop that does automation following manual test can be a double0edged sword. You end up with people who are dependent on your tests being reproducible and very explicitly clear, which is good (you tend to write better tests over time), and bad (you have to spend a bunch of time fixing tests that are prefectly understandable to you).
posted by Four Flavors at 10:03 AM on May 7, 2007
Following that, I'd look at what the expectations of management are, If you hear anything about bug-count requirements, RUN.
Alos, owrkign in a shop that does automation following manual test can be a double0edged sword. You end up with people who are dependent on your tests being reproducible and very explicitly clear, which is good (you tend to write better tests over time), and bad (you have to spend a bunch of time fixing tests that are prefectly understandable to you).
posted by Four Flavors at 10:03 AM on May 7, 2007
Response by poster: Update: I took the job. I'm almost a month into it now, and so far, I love it. Thanks, MeFi!
posted by phoenixy at 8:17 PM on June 30, 2007
posted by phoenixy at 8:17 PM on June 30, 2007
This thread is closed to new comments.
posted by ikkyu2 at 1:28 PM on May 4, 2007 [3 favorites]