The programmer and the tester should be friends?
May 8, 2011 8:26 PM Subscribe
Is the relationship between QA and programmers naturally antagonistic? If not, what can you do to get the QA or QC engineers and software engineers to work together rather than try to tear each other apart?
I recently took a position at a medium-sized software firm after spending most of my years working for small shops or on my own. One of the first things I noticed is how much animus is mutually held by the QA department and the software engineering department.
The relationship is remarkably dysfunctional -- QA will refuse to accept code, engineers will try to sneak things past QA, both sides yell a lot. In fact, I'd argue that despite both sides saying continually they have the "customers' best interest" at heart, they really care more about this weird power struggle.
Is this normal? Do QA engineers and software engineers normally fight like Mommy and Daddy? Or is the normal relationship less dysfunctional? And if so, how can you make this relationship better?
Admittedly, this could be less the relationship between QA and engineering and more a startup that's trying to transition into being a profitable business. But regardless, this doesn't seem right to me.
(Anonymous to protect me from angry QA engineers at firm who might read AskMe.)
I recently took a position at a medium-sized software firm after spending most of my years working for small shops or on my own. One of the first things I noticed is how much animus is mutually held by the QA department and the software engineering department.
The relationship is remarkably dysfunctional -- QA will refuse to accept code, engineers will try to sneak things past QA, both sides yell a lot. In fact, I'd argue that despite both sides saying continually they have the "customers' best interest" at heart, they really care more about this weird power struggle.
Is this normal? Do QA engineers and software engineers normally fight like Mommy and Daddy? Or is the normal relationship less dysfunctional? And if so, how can you make this relationship better?
Admittedly, this could be less the relationship between QA and engineering and more a startup that's trying to transition into being a profitable business. But regardless, this doesn't seem right to me.
(Anonymous to protect me from angry QA engineers at firm who might read AskMe.)
I'm a developer on a very small team, with a very small QA team vetting our work, but within very large organization. I won't say there aren't hard feelings at times - when we dump a lot of work to be tested on QA without a lot of notice; when we goof up and end up taking up a lot of QA time testing buggy stuff that they (Rightly or otherwise) feel shouldn't have gotten as far as them; when they reject a change due to misunderstandings about what the code should do. But we're certainly not antagonistic; my QA lead calls me up regularly to chat and get my help understanding changes we've made. Nobody yells or shouts; we have our differences, we recognize that - because of our roles - those differences are often unresolvable on our own; we regularly jointly take them "upstairs" and happily abide by our project manager's decisions.
What I'm saying is, no, we don't fight, and even when we have a spat, it's definitely not to the point I'd call dysfunctional. I can't remember a single time QA rejected our code without a perfectly good reason for doing so, and the idea of sneaking by a change is kind of horrifying to me.
posted by Tomorrowful at 8:40 PM on May 8, 2011
What I'm saying is, no, we don't fight, and even when we have a spat, it's definitely not to the point I'd call dysfunctional. I can't remember a single time QA rejected our code without a perfectly good reason for doing so, and the idea of sneaking by a change is kind of horrifying to me.
posted by Tomorrowful at 8:40 PM on May 8, 2011
I'm QA and my experience is much like Tomorrowful's.
posted by danb at 8:42 PM on May 8, 2011 [1 favorite]
posted by danb at 8:42 PM on May 8, 2011 [1 favorite]
That's crazy. How the hell is QA refusing to accept code? And how are engineers trying to sneak stuff past QA? In every shop I've ever worked, developers and QA worked VERY closely together. While there were always individual team members who've butted heads, having the entire teams be at odds is a total management failure.
Isn't there a product manager or an engineering director who can step in and knock some heads together?
posted by deadmessenger at 8:43 PM on May 8, 2011
Isn't there a product manager or an engineering director who can step in and knock some heads together?
posted by deadmessenger at 8:43 PM on May 8, 2011
Sometimes it is, sometimes QA plays gotcha games, like they are there to prevent developers from intentionally shipping crap code. I've had QA try to no-go on hot fixes at 2am because they found a spelling error. And of course I have seen developers try to put one over on QA. This is not the way it is supposed to work. You are a team, QA is supposed to help developers ship a product that does what the customer expects, they are not there to monitor developers and act like they are trying to catch you goofing up and developers should not view QA as some sort of adversary to be circumvented.
posted by Ad hominem at 8:44 PM on May 8, 2011
posted by Ad hominem at 8:44 PM on May 8, 2011
Who is defining the requirements? In the small sample set of my experience on both sides of this there is a pretty tight relationship between clear requirements and a good QA-developer team.
In any team that is functioning as you describe I'd expect the team lead/project manager/whoever to be calling closed-door meetings to sort that mess out.
posted by N-stoff at 9:14 PM on May 8, 2011
In any team that is functioning as you describe I'd expect the team lead/project manager/whoever to be calling closed-door meetings to sort that mess out.
posted by N-stoff at 9:14 PM on May 8, 2011
Much like Mommy and Daddy, Dev and QA are supposed to get along and in most cases they do. The relationship between Dev and QA is seriously messed up at your company. I bet if you hang around long enough the reason will become apparent, like a couple of senior people with personality problems or a performance review process that grades developers on the number of bugs found in their code or something like that. Then fixing the problem will likely come down to fixing the root cause. (Anyway, what I really like for a good relationship is integrated product teams rather than separate departments. Or at least get the two groups socializing or something; mix them up and, I don't know, have them eat lunch or play Pictionary or whatever.)
posted by phoenixy at 9:22 PM on May 8, 2011
posted by phoenixy at 9:22 PM on May 8, 2011
I agree with other comments here in that management (whether it is ProdMgmt, or ProjMgmt, or QA, or engineering) seems to be non-existent.
At the end of the day, a product that sells is the direct result (among other things) of a good coding practice, and a good an thorough testing practice. Both teams need a big lecture on these kind of things, as it seems both teams are missing the end goal.
As others have said, this is definitely not the norm. QA and dev should be a team.
A good practice is to assign a QA lead to a dev lead for functional areas or features,
and have them sitting together, discuss stuff together, brainstorm together.
Dev needs to understand how testing is done. QA needs to understand how dev is done.
posted by theKik at 9:28 PM on May 8, 2011
At the end of the day, a product that sells is the direct result (among other things) of a good coding practice, and a good an thorough testing practice. Both teams need a big lecture on these kind of things, as it seems both teams are missing the end goal.
As others have said, this is definitely not the norm. QA and dev should be a team.
A good practice is to assign a QA lead to a dev lead for functional areas or features,
and have them sitting together, discuss stuff together, brainstorm together.
Dev needs to understand how testing is done. QA needs to understand how dev is done.
posted by theKik at 9:28 PM on May 8, 2011
When I worked in QA, my feature's dev and I were like a cop team on a 1970's cop show. eyes rolling, snarky comments, smack talk? Sure. But we were a _team_ and we were both all about making the feature good.
When you say QA is refusing to accept code, do you mean that they won't even test it, or that they won't pass it? If they won't even test it, what's their reasoning? As for dev trying to sneak stuff in pass QA. . . how is that even possible? At some point, the checked-in code will be compiled, and the build will be given to QA.
I'm hardly an expert but I'd say there's a lot of process management that desperately needs to happen at your company even outside of the toxic personnel situation.
posted by KathrynT at 9:57 PM on May 8, 2011
When you say QA is refusing to accept code, do you mean that they won't even test it, or that they won't pass it? If they won't even test it, what's their reasoning? As for dev trying to sneak stuff in pass QA. . . how is that even possible? At some point, the checked-in code will be compiled, and the build will be given to QA.
I'm hardly an expert but I'd say there's a lot of process management that desperately needs to happen at your company even outside of the toxic personnel situation.
posted by KathrynT at 9:57 PM on May 8, 2011
I've worked in QA and engineering, and I've seen the kind of antagonism you are describing. Management needs to change the culture ASAP. In my case it was one dev who treated everybody poorly, and I took perverse pride in taking him down a peg. Eventually he was given a sideways promotion out of dev, and I moved to fill his old role. Those two changes led to great career leaps for both of us, and a period of great profits and expansion for our department.
posted by infinitewindow at 10:04 PM on May 8, 2011
posted by infinitewindow at 10:04 PM on May 8, 2011
So I think everyone knows that no, it doesn't have to be like that. But yes, the relationship can be very bad at times. Sometimes the whole department is a reflection of a much smaller power struggle between QA and eng leads or somesuch.
In some companies there are no QA people you know. Engineers are expected to test their own code and if it doesn't work fingers are pointed. Depending on the product this isn't always possible.
But if you're caught in the middle of it I wouldn't fight it. Try to be a nice guy and start send out your resume again.
posted by GuyZero at 10:04 PM on May 8, 2011
In some companies there are no QA people you know. Engineers are expected to test their own code and if it doesn't work fingers are pointed. Depending on the product this isn't always possible.
But if you're caught in the middle of it I wouldn't fight it. Try to be a nice guy and start send out your resume again.
posted by GuyZero at 10:04 PM on May 8, 2011
Is this normal?
It's common enough to be a cliché, but it's not a necessary piece of brokenness. (One thing I like about my current place of employment is that engineering and QA work together well.)
I think this dysfunction is often a symptom of poor morale and poor management. If you're taking pride in putting out the best possible product, even under time pressure, QA and development are naturally on the same side. If your main motivation is to hit a deadline or fill out bullet points, QA and development are naturally enemies.
posted by hattifattener at 10:15 PM on May 8, 2011
It's common enough to be a cliché, but it's not a necessary piece of brokenness. (One thing I like about my current place of employment is that engineering and QA work together well.)
I think this dysfunction is often a symptom of poor morale and poor management. If you're taking pride in putting out the best possible product, even under time pressure, QA and development are naturally on the same side. If your main motivation is to hit a deadline or fill out bullet points, QA and development are naturally enemies.
posted by hattifattener at 10:15 PM on May 8, 2011
Successful integration of QA and development hinges on early involvement. Projects I have worked on that did well with this had QA involved at the specification stage, working out what the appropriate metrics should be, and devising testing plans.
Then the next thing, which is really vital is that project managers need to realise that you can't put finalise code -> QA testing -> release on a project plan WITHOUT ALLOWING FOR REVISION CYCLES!!! God it used to shit me to tears. It assumes that code is faultless or that testers are incompetent or something, but project plans need to account for the fact that testing turns things up, and that developers need time to fix them.
Sorry. Had to get that off my chest.
posted by tim_in_oz at 10:29 PM on May 8, 2011 [2 favorites]
Then the next thing, which is really vital is that project managers need to realise that you can't put finalise code -> QA testing -> release on a project plan WITHOUT ALLOWING FOR REVISION CYCLES!!! God it used to shit me to tears. It assumes that code is faultless or that testers are incompetent or something, but project plans need to account for the fact that testing turns things up, and that developers need time to fix them.
Sorry. Had to get that off my chest.
posted by tim_in_oz at 10:29 PM on May 8, 2011 [2 favorites]
Giving those involved the benefit of the doubt that they are trying to do their best but are stymied by the circumstances, I'd agree with the theme above that there is something in the management or process of the development and test cycle that needs to be fixed. Is the schedule too tight and causing stress and bad morale? Is QA involved with reviewing the programmers' designs? Do the programmers do unit testing so they're not handing idiotic bugs off to QA? Did QA write test plans that programmers reviewed? Is this a situation where the QA team is not made up of programmer types but "button clickers" who programmers have difficulty respecting (I'm not saying that kind of QA is bad)? You need to find the root causes for the animosity (and it may just be one or two badly behaved people setting bad examples) in order to start fixing it. Does management at least admit there's a problem here and are they willing to figure out how to fix it? Sometimes sitting the two sides together in a room with a neutral moderator to air out grievances (disallowing any personal attacks) and realize a common goal is a start.
posted by girlhacker at 11:14 PM on May 8, 2011
posted by girlhacker at 11:14 PM on May 8, 2011
As far as improving this, I agree with Tim. QA should be an integral part of the early design, especially functional spec and detailed design meetings. Then coming up with a reasonable test plan that is informed by the development work, and a lot of (what we call) ad-hoc QA testing on pre-release builds. As you get closer to release, keeping track of metrics and even offering some kind of reward for each individual such as bugs found and verified (qa) and bugs fixed (dev) can incentivize people to give it that extra push in the home stretch.
It sounds to me like you have even bigger problems though, and that is the priorities of the developers and QA teams seem to be on a crash course with each other. As others have said, even though there might be occasional rivalry between the teams, it is crucial for everyone to take pride in putting out the best release they can, and the QA process is a vital part of that. What specifically is causing the stress? Is there not enough time to test the build? Not enough time to fix the bugs that get found? Are the bugs verified by QA after they are fixed? Are the builds not being delivered on-time, or in a way that is difficult for QA to work with? Do you have a bug tracking software, and a clear process for the use of it?
One thing we do in our very last qualification before release is to pull in people from the dev team for manual testing and bug verification. This gives people on the dev team a better understanding of the work QA does, fosters communication and personal relationships, and provides more in-depth knowledge of the code and product that can even be useful in finding and identifying new issues.
posted by sophist at 11:14 PM on May 8, 2011
It sounds to me like you have even bigger problems though, and that is the priorities of the developers and QA teams seem to be on a crash course with each other. As others have said, even though there might be occasional rivalry between the teams, it is crucial for everyone to take pride in putting out the best release they can, and the QA process is a vital part of that. What specifically is causing the stress? Is there not enough time to test the build? Not enough time to fix the bugs that get found? Are the bugs verified by QA after they are fixed? Are the builds not being delivered on-time, or in a way that is difficult for QA to work with? Do you have a bug tracking software, and a clear process for the use of it?
One thing we do in our very last qualification before release is to pull in people from the dev team for manual testing and bug verification. This gives people on the dev team a better understanding of the work QA does, fosters communication and personal relationships, and provides more in-depth knowledge of the code and product that can even be useful in finding and identifying new issues.
posted by sophist at 11:14 PM on May 8, 2011
It is an odd relationship. Programmers build up a certain ownership of the application - they know how it works and then they have to pass it over to people who didn't "give birth" to the application - and yes, your shop sounds broken. Get into test drive development and make QA a part of the application, not a process that is run at the end,
posted by the noob at 11:19 PM on May 8, 2011
posted by the noob at 11:19 PM on May 8, 2011
Your shop sounds like it lacks leadership. Both sides (devs and testers) have their stereotypical quirks, but getting them to work together is a project management and leadership problem.
posted by PsuDab93 at 7:33 AM on May 9, 2011
posted by PsuDab93 at 7:33 AM on May 9, 2011
I've been in shops like this -- the worst was one where the Dev managers had been promoted from developer positions, and they were still programming. Schedule was always the problem, and when more time was needed the developers got it, never QA. Hence, antagonism.
posted by Rash at 8:17 AM on May 9, 2011
posted by Rash at 8:17 AM on May 9, 2011
I'm a PM and that is not normal for what I've seen.
Some things I'd recommend:
-Encourage the QA team and programmers to chat and communicate and fix bugs directly with each other instead of going through the PM. Everything should be recorded in some sort of bug tracking software or even just a shared Google doc so the PM can check and be aware of issues as they arise but no one needs to be a tattletale and blame the other party because no one has to go through the PM to work things out.
-When you have your update meetings, address QA and programmers as a team instead of separately like "QA Dave and Programmer Bill, will $Feature be ready by $Date or do we need more time? How far behind are we?" Because if you say it to just one and then the other it sounds like there is blame being assigned for problems.
-Next time you plan a project, build in at least as much QA time as development time. My guess is that your team members are feeling stressed because they are not delivering on time or up to quality standards and they are worried that they will be blamed so they are throwing each other under the bus before that can happen. When you create realistic schedules with a long QA period, that should not happen anymore and everyone will be happier because they will be on schedule and there won't be any blame to pass.
-If things are just beyond repair for this specific project, encourage the PM to cut features. (I am unclear about whether you are a programmer or a PM or what).
-If you start a new project with this company and you see that the specs are unclear or the expectations of velocity are too high, say something and clarify, cut features, or expand the schedule. If they don't listen or refuse to operate at a normal schedule or the fighting is just too entrenched, get out. It's not healthy to work like that and it implies something about how the upper management treats its workers and what it expects from them. (of course, if you are the new upper management, change that instead of leaving.)
posted by rmless at 10:12 AM on May 9, 2011 [1 favorite]
Some things I'd recommend:
-Encourage the QA team and programmers to chat and communicate and fix bugs directly with each other instead of going through the PM. Everything should be recorded in some sort of bug tracking software or even just a shared Google doc so the PM can check and be aware of issues as they arise but no one needs to be a tattletale and blame the other party because no one has to go through the PM to work things out.
-When you have your update meetings, address QA and programmers as a team instead of separately like "QA Dave and Programmer Bill, will $Feature be ready by $Date or do we need more time? How far behind are we?" Because if you say it to just one and then the other it sounds like there is blame being assigned for problems.
-Next time you plan a project, build in at least as much QA time as development time. My guess is that your team members are feeling stressed because they are not delivering on time or up to quality standards and they are worried that they will be blamed so they are throwing each other under the bus before that can happen. When you create realistic schedules with a long QA period, that should not happen anymore and everyone will be happier because they will be on schedule and there won't be any blame to pass.
-If things are just beyond repair for this specific project, encourage the PM to cut features. (I am unclear about whether you are a programmer or a PM or what).
-If you start a new project with this company and you see that the specs are unclear or the expectations of velocity are too high, say something and clarify, cut features, or expand the schedule. If they don't listen or refuse to operate at a normal schedule or the fighting is just too entrenched, get out. It's not healthy to work like that and it implies something about how the upper management treats its workers and what it expects from them. (of course, if you are the new upper management, change that instead of leaving.)
posted by rmless at 10:12 AM on May 9, 2011 [1 favorite]
I'm not sure from your description what YOUR job is, but... that's certainly not a "normal" situation, where "normal" means, "is like this in a lot of other places." On the other hand, it does, of course, happen. Have I worked in one in 15 years in the business? No. Have I heard of it happening? Yes, several times.
And every one of those times, the root cause was a lack of competent, adult supervision. Programmers and QA analysts, left to their own devices, are territorial and fiercely proud of their own work. Success, however, depends upon them having a mutually reinforcing process. It sounds to me like your programming team, or your QA group - or both - are headed up by people who aren't up to the task of keeping tempers down and focus on the combined end goal (somebody above mentioned developers and analysts being promoted into managing these groups; that's pretty a sure-fire way to cause the situation you're describing).
I feel bad not being able to offer you some options, but it's hard without knowing your own position to give you any advice regarding what to DO in this situation.
posted by OneMonkeysUncle at 10:24 AM on May 9, 2011
And every one of those times, the root cause was a lack of competent, adult supervision. Programmers and QA analysts, left to their own devices, are territorial and fiercely proud of their own work. Success, however, depends upon them having a mutually reinforcing process. It sounds to me like your programming team, or your QA group - or both - are headed up by people who aren't up to the task of keeping tempers down and focus on the combined end goal (somebody above mentioned developers and analysts being promoted into managing these groups; that's pretty a sure-fire way to cause the situation you're describing).
I feel bad not being able to offer you some options, but it's hard without knowing your own position to give you any advice regarding what to DO in this situation.
posted by OneMonkeysUncle at 10:24 AM on May 9, 2011
Yeah, I've been there. In my opinion, there were two contributing factors: 1) No design documentation. Both sides were equally valid in their argument about how it "should" work. 2) QA's performance was determined by number of bugs filed, which was crazy. This effectively encouraged QA to file bugs that really weren't, and then argue for them. If it got sent back as "not a bug," it counted against them.
The thing to do is find out who is responsible for a given feature, and make them make a decision. It's not Engineering's or QA's job to negotiate behavior or features. (Unless it is, in which case that's really bad.)
posted by Sibrax at 2:24 PM on May 9, 2011
The thing to do is find out who is responsible for a given feature, and make them make a decision. It's not Engineering's or QA's job to negotiate behavior or features. (Unless it is, in which case that's really bad.)
posted by Sibrax at 2:24 PM on May 9, 2011
This thread is closed to new comments.
Every second dedicated to the nonsense you described is time and energy not spent making the product better and getting it out the door.
posted by NoRelationToLea at 8:33 PM on May 8, 2011 [3 favorites]