Wednesday, 12 June 2013

Developers vs Testers

Last week I had the usual argument between developers and testers. (Note, I did not actually write the code that was the source of the issue, but I am getting ahead of myself.)

Tester: Why did you close the ticket as working to spec?
Me: Occam's razor. 
Tester looks baffled at me
Me: Wikipedia
Tester looks even more baffled
Me: Look it up in Wikipedia
Tester left admitting defeat.

That's how it should've played out but alas it wasn't.

The issue raised was that the invoices related to an account did not have the correct number, for various reasons too involved to explain here, we have separate auto numbering counters for different invoice types, thus it's perfectly valid to have 30 invoices and the 31st be numbered 1 if it's the first invoice of this type, e.g. 30 for consultancy services and 1 for accountancy services.

Unfortunately, the auditing system in MS dynamics CRM 2011 is not perfect so deleting invoices, which is actually a custom entity, leaves a record that they were deleted, by whom and at what time, but crucially it does not say which invoice was deleted.

I responded to the tester, after checking the audit view, that he must've deleted the invoices and that explained the incorrect number and closed the ticket.

The tester was not happy, they thought it was a real issue that needed looking at and this is where things normally take a turn for the worse, because we, as developers, assume that the tester did something wrong. 

We don't just assume that the tester did something wrong, of course, we check our code (✔), we run a unit test (✔), we might actually prove to the tester that the functionality that the tester raised a defect about working properly (✔), so why is this insignificant little tester wasting my time rather than accepting that they did something wrong?

It's pretty simple really, they need an explanation that satisfies them

Nobody likes admitting that they are wrong and in cases like this, where the issue, at least to the tester, is intermittent, they would like the developer to prevent it from happening again.

At this points my options were:

  1. Get into a ticket passing ping pong match (which almost certainly would've escalated to ..)
  2. Escalate to PM and/or TM
  3. Reproduce the bug.
So I did, and it turned out that my explanation was only half right. Yes, they had deleted some invoices but there were genuine holes in my explanation.

Is there anything that can be learned from this episode?

  1. Don't be lazy.
  2. Don't assume that the tester made an error
  3. If you are sure that the tester made an error, then see #1 and do replicate the error that they made, who knows they might help you uncover some bugs in the system.

No comments:

Post a Comment