4 reasons it sucks to be in QA
Well that's my take on it folks - of all the roles in the Software Development Life Cycle probably QA has it worst. Managers, Architects, Developers, Business analysts - no-one takes as much BS or has such a thankless role as the valiant folks in your average QA team.
Now I hope most of you reading this will disagree but I'm betting there's a lot of nodding heads out there (probably mostly from folks in QA).
What are the main reasons for this you say? There are four as I see it:
1) Respect
QA tends not to get respect from people in other roles - but most especially and most oddly the least respect (most disrespect) comes from software developers. Personally I find this strange that developers have such disrespect (sometimes even open and outright disdain) for those tasked with ensuring the quality of the product being delivered.
I think a lot of developer frustration comes from the questions and problems that arise out of the QA team/group. Yes, often QA folks don't understand the ins and outs of an application. If that's because someone in QA doesn't want to learn then that's a worthwhile beef but more often than not the QA team are STARVING for information.
Often they're brought in at the last minute, given a vague, incomplete and out-of-date spec and told "Hey go test this!". Yes the developers had the same spec and were told "Hey go code this!" but they're finished building out the app so they've (hopefully) fleshed it all out at least in their heads and in the software they've built.
Developers deride the QA role - "What do those guys know? They're just testers!".
That's just the wrong attitude. These guys and gals are the ones who, at the least are helping to make the product (not code folks - product!) better, and at best saving your ass from being fired for shoddy work. You and they are on the same team though you may not realize it. Try to remember that.
Another reason that I feel developers beat on QA is that the developers get beat on themselves (think Dilbert) and like some bullied kids they look to take it out on the only one's they can - someone weaker - not managers, not architects, not the business analysts, not other developers - who's left? QA!
I've seen it many-a-day - the self-righteous attitude developers take in correcting QA or better yet informing them that their "bug" won't be fixed because it "works as designed" or they spent 5 seconds trying to reproduce the bug and could not.
I'm not saying "works as designed" or "unable to reproduce" are a bad reason to kill a bug - just the attitude that goes with it. Call the tester - explain why it works that way - should the docs be updated to make that clear? Possibly! If you can't reproduce a bug maybe there's some context or other missing information - maybe it's particular to the tester's environment. Just blowing things like that off might make a developer feel good but it diminishes the overall product and the team too. Take the time to do it right - a phone-call or walk-by will take 5 minutes at most.
2) Responsibility vs. Power
The QA team have a very important responsibility - they are the gatekeepers of product quality. At least in theory anyway! Also quality is a hard thing to identify or quantify. Is it the overall user experience, the number of bugs, the number of critical bugs, how do you define "critical"? Just too many subjective things. Oh and usually they're understaffed and/or under-tooled.
However for all this responsibility they have the least power. In the hierarchy of management structures QA comes pretty much last.
Everyone else thinks they can do the QA job - how hard can it be? But the reality is very few people can do QA right. And especially not developers! We are our own worst enemies in this case - we use the application like we coded it not like it was meant to be used.
3) Last to be hired and First to be fired
In the boom and bust cycle of software QA folks seem to be the last to be hired - usually towards the end of the boom when all your new customers start to complain about the bugs from all the newbies you hired at the start of the boom. But then when the bust inevitably comes QA folks are first on the chopping block followed by middle managers. No wonder there aren't many experienced QA folks about - again it's a widespread lack of understanding of the importance of QA and testing in the software process.
4) Paradox of excellence
The "Paradox of excellence" is something we're all familiar with but may not know it. Since the art of software (it ain't engineering or science yet) is not well understood, few outside of software can understand how hard it is to do software "right" - with few bugs. It takes a long time. Therefore when software is done right people don't perceive the absence of bugs - they just see that the process seemed to take forever to complete.
Basically the "paradox of excellence" states that you don't get credit for problems that never happened. Typically in the normal software shop when bugs happen and they are fixed fast by developers the developer gets kudos. Who gets kudos for the lack of bugs in a release? No-one.
So if QA does their job right - no-one notices. The same is true for developers to an extent but they can usually redeem themselves if and when bugs do show up. QA have no such opportunity - if they *do* spot issues they becomes "spoilers" for the party giving the bad news no-one wants to hear.
With those four issues facing you as a person in QA - lack of respect, little power, no praise, fear of being laid off, how much motivation would you have every day?
In my opinion a rock solid QA person is one of the most critical roles on a project. In fact in my experience the best QA people know the application better than the developers, the managers, the analysts and even the users. They know the ins and outs - breadth and depth and know where most of the bugs pop-up! I wish most developers were so aware.
Solutions?
How do we resolve this problem for folks in QA? There are two steps - the first easy and the second not so much:
1) Co-locate QA and Developers
Have developers and QA sit side-by-side and work together closely throughout the entirety of the software lifecycle. Make them truly part of the team! Have lunch together!
Physical separation of QA from the dev team is a bad idea. Having separate reporting structures for Dev and QA might be good since having same reporting structure creates a little "conflict of interest" - management understandably want good news, QA are rarely bearers of good news - but it's news that needs to be heard!
2) Developers and management need to snap out of it!
Frankly this treatment of folks in QA is one of those little "secrets" in software that we should be ashamed of if we consider ourselves to be "professionals" in the true sense of the word.
Developers and management need to respect the critical role of QA, the complexity of their job and most of all to drop by their cubes and say thank you for all their hard work they do without much praise - day-in, day-out. Your product is better for it, the industry is better for it (and could do with much more of it) and thus the rest of us managers, architects and developers are better for it.
Labels: programming, Software, software development process, standards, testing
posted by Frank Kelly at 8:46 PM
View blog reactions
11 Comments:
I hear you about how tough it can be to be in QA. On the other hand, I (as an architect) consider the QA team to be on my side -- do you want to stand up in front of a Java One keynote sized audience, and have your demo blow up because of something that should have been caught? :-)
More seriously, I make a point of attending the weekly QA team meetings, to both communicate what the development team is doing, but also assist in understanding how to test what we are building. I consider this to be mission critical to creating high quality software.
One subtle (perhaps insidious) idea that we're including on a current project is to colocate the QA developed tests into the source tree of the components being developed. That way, if a developer breaks a QA provided test, they get immediate feedback -- and, among other things, they get motivated to communicate regularly with their QA folks to proactively deal with the inevitable changes that occur during the development process.
It's too early to tell if this will be as beneficial as I hope, but I'm pretty optimistic.
Craig McClanahan
8/07/2007 1:13 AM
Here is my experience. Management thinks QA is easy, so they hire less-skilled people at much lower salaries to fill QA positions. They also "demote" incompetent programmers to QA positions.
I believe QA is actually one of the hardest jobs, but I've never worked at an organization where management thinks this or is willing to commit resources.
So if developers have disrespect for QA, maybe its because the QA people at their organization just aren't all that qualified to do it right.
8/07/2007 10:28 AM
QA are just the testers nothing else.
8/09/2007 10:19 AM
I totally hear you. Thanks for bringing up the issue. Occasionally, I would run into a one liner jira issue:
- Test spring JMX
- All class adapters need to be test.
When sale engineers on the field, they bring with them the confidence of the product of which only a good QA team can provide. If you think QA are just testers like the previous poster, you might as well close your shop and sell bottled waters.
8/10/2007 2:03 AM
I've been in QA at a giant software corporation for about 5 years. I'd agree that communication with developers is the key to getting good testing out of QA.
In my company, QA consists of 2 types of people: QA Analysts, who typically have liberal arts educations, and QA Engineers, who are typically developers who are unable to get jobs in that field.
Normally, developers prefer coding to explaining their code, and QA's are often don't have the technical background to easily understand engineers. It sometimes takes a lot of effort on both sides just to communicate.
Physically locating QA's and Developers together, encouraging social interaction between the groups, communication training for developers, technical training for QA. All of those are good, but it's always going to be difficult, at least in a large organization.
8/10/2007 2:02 PM
It's great to see someone actually write about this. In my experience (4 years as a developer, then 7 years as a QA), QAs are usually allocated to a project at the last minute, having missed the weeks of thought and discussion that the developers have had (all of which couldn't in fairness be documented). This is why the QA has to ask so many questions - in order to fully understand the design and therefore design tests properly. This questioning and learning process has often in my experience led to the prevention or early detection of bugs - QAs often ask the questions that developers haven't thought of (as QAs aren't concerned with coding concepts etc).
It's in everyone's best interest for QAs and developers to work closely together - both sides learn more about the products concerned and save themselves a lot of time, aggravation and hassle having to investigate, reprtoduce and fix bugs after release. QAs should be treated as full members of the teamm and as such should be assigned to their work in sufficient time to become full participants in a project
8/21/2007 5:16 PM
Totally agree with you.
I have been a developer for five years now and I see the same in both the companies I have worked with.
My earlier company did not have QA (since they did not find it necessary I guess!) and had some senior developers playing the roles (badly of course).
My current workplace does have QA, but I think they are there just for headcount. The company does not respect them for their thoughts/ideas. They are seen as pests who come in and cause delays.
Although at a personal level it does not affect friendship/relations among developers and QA, it does matter when the company itself does not care about QA. The whole dev-is-superios-to-qa has set in around her.
Hope things change in future.
Thanks again for a nice article
9/25/2007 1:50 AM
I know people advocate mixed teams of programmers and QA engineers, but honestly in the past, the best circumstances I've seen occurred when the two groups were completely separated. In its widest possibly definition, bugs are any behavior that are not correct and many of the 'bugs' that irritate the users the most start their lives right in the design documents. Having programmers write test cases and people mindlessly execute them insures that the bugs will not be found.
Putting a 'wall' between the developers and QA engineers helps with morale on both sides, but it also provides two distinct views of the system. QA should report any and all differences from their expectations. If you can keep testing as a 'fixed' length process that produces a complete report on all of the system's defects, you can keep the project from getting caught in a death spiral while fixing bugs. The costs become known by everybody so they can be avoided or accepted.
The decision to fix correctly, fix barely or ignore the problem is a product management one, which involves money, time and the user's expectations. Just because there is a problem, doesn't mean it will be fixed in the next release. Sometimes it just is not worth the work.
If most of the known problems are fixed, then precisely understanding the impact of the changes can be used to focus any further rounds of testing; avoiding wasteful and costly complete retesting.
The way most companies QA their software is costly and ineffective. It is consistently the weakest part of our software development industry.
Paul.
http://theprogrammersparadox.blogspot.com
12/31/2007 12:55 PM
Good article. But i feel its the same everywhere. Even in my company testing team members are called as bugs:(. The best thing we can do is, just report the issues in a bug reporting tool and leave.
I had raised this issue in a meeting saying that testing people should be involved while discussing the project to the developers so that we could gain some knowledge and also present their ideas, i got a response from my management saying a clear "NO. You dont need to be concerned about it so you will not be involved in these kinds of meetings". Thats it.
2/29/2008 5:57 AM
I'm a QA Manager and I think your article hit the nail on the head. Recently I had the privilege of being verbally assulted by one of my IT peers with the "QA is an obstacle, not an asset" spiel. I can't blame him too much because I too would be frustrated if after months and months of designing and developing a product, you get a team of QA testers telling you the thing don't work. Bottom line is that its the function of QA to create unplanned work (bugs) at the last minute. If the IT dept feels QA is obstacle then I always ask them if they would rather see bugs get reported by QA or by their customers?
QA is like a dentist. Brush and floss your teeth and doesn't have to be painful.
3/02/2008 8:25 PM
Friend:
On your solutions, putting a QA person side by side with a developer for the lifecycle of the developer's work is a "bad idea".
Why? In my experience, developers and QA folks think in two totally different directions. Developers *have* to think linearly, from the input, to the processing, to the output, and factor in the values, functions, logic, and other parts that make each of the portions of the process fit together in a manner that is most efficient and reusable.
QA folks, again speaking generally, work / think in terms of the specific process they are testing. In order to manage their process, they look at all of the things that come into a specific portion of the application, compare to expected outputs, then ensure those specific outputs (or document the failure to do so).
As an example, say you did this in the auto industry with two folks, one person making a car, and one person making sure it fit performance specifications. Would you start with the drivetrain? And when the drivetrain was complete, would you be able to fit seats around it, or a body?
I would in no means want to deride the importance or intelligence of those who are capable, qualified QA ppl (and I've met few, but in a nod to your earlier argument, most of those I've met have no formal training because management felt that you could promote from the general population to QA due to their lack of understanding the importance / difficulty), I merely posit that there is a real difference in the way these folks think.
I would modify your solution, instead, to "Put the developers with the QA team while they are testing, after the application has reached whatever stage you are shooting for (alpha, beta, gold, gold master, gold hamster, whatever) to help both teams understand the issues, processes, and functions of the 'product' (to use your term).
6/09/2009 4:54 PM
Post a Comment
Links to this post:
Create a Link
<< Home