How to make QA test my web service instead of forcing me to test their web service client?

Question

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.

Answer 1

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

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

Answer 2

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.

Answer 3

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?

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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.