views:

293

answers:

7

I work on a number of web services and virtually every time I produce a major build, QA starts throwing up bugs that I frequently find have nothing to do with the server side code, but rather with their crap client library. I've tried to at least make it policy that they don't file bugs without the XML that they're pushing to the server, but they frequently ignore this requirement.

+3  A: 

This question could probably be filed under the more broad generalization of

"How can I get my coworkers to do their job properly?"

TheTXI
+5  A: 

This probably has more to do with your work policies and procedures than with programming.

But in the simplest form, the burden of proof is on QA, and you are innocent until proven guilty. If QA throw a bug at you, they should do so with the maximum available data, proving that there indeed is a bug and not just some false negative on their side. Anything less than this is lack of professionalism on their side.

You should establish policies, and abide them, to ensure the minimal wasted time possible. You debugging their tests is NOT acceptable, nor is it your job.

Yuval A
+1  A: 

Maybe they can only access your Web Service through the client. What if you showed them tools, like soapUI, and have them use these tools to test your service directly?

Rohit Agarwal
I've spent a not insignificant amount of time suggesting things like demonstrating the use of wireshark to grab the XML, or very simple java code to take a string containing XML and posting it to get a result.
Jherico
A: 

The standard way to deal with such a problem is escalation. Report the problem up in the hierarchy to someone that is their superior. Make certain that you have well written case description and arguments, why they need to change their approach.

Since the people on the escalation level will most probably be managers with little/no experience in programming, write your arguments in 'business language': Value added, revenue loss, potential savings (my favourite!) etc.

Treb
+5  A: 

Record, document, prepare your case. You keep a record of the numbers of time they were wrong, the time it took you to diagnose the problem and the time it took them to fix it. Then you escalate the problem to management: over the past 5 work days I had to allocate 15 hours total to diagnose issues X, Y, and Z which were opened w/o consideration by QA. They had to do check in A, B and C in their tests to mitigate the issues. Here is the XML they send before, here is the XML after. As with any corporate jungle, document your complaint: is a person's daily income at stake and he'll be fighting you back. QA person has more to loose than you, so he'll fight harder. You have to be able to demonstrate your claims. Either QA fixes their attitude, or you get extra time to fix their mess, or nothing changes and you at least know where you stand and ... where to look next.

Remus Rusanu
Ah, sounds as if we were working in the same company... but most likely, we're just living in the same universe ;-)
Treb
Yeap, Dilbert is no fiction ;)
Remus Rusanu
A: 

Mark it as "will not fix--not a bug" and toss it back at QA.

Adam Jaskiewicz
Unfortunately that generates a lot of ill will. If I do it simply because they didn't include XML they get pissy. If I do it after I've determined the problem is in their client then I haven't saved any time.
Jherico
>> Mark it as "will not fix--not a bug" and toss it back at QA.Bouncing it as Not A Bug means that you know it’s not a bug, and you don’t know whether it’s a bug. Bounce it as Cannot Reproduce instead.> If I do it simply because they didn't include XML they get pissy.Tough. I’ve been on the other side a lot, with lots of my bugs bounced by engineering, so I’m normally unsympathetic. But if you’ve documented the requirements for reproducing a bug, and QA fails to meet them, you can almost have a shell script set the resolution.
Flash Sheridan
A: 

Hey.
Two separate things.
Firs QA should include XML in bug report. ANY relevant information they know of should be in bug report. If needed escalate this, as others suggested.

Second thing, if it is problem with their client, check if user will be using same library. If not ask QA to change the client/library/way they check the service. if asking doesn't help escalate showing how much time and money it costs. If yes, you need to figure out how to make your service work with that library.

This or another escalation may be needed.

yoosiba