Fog Creek Software
Discussion Board




Developers retesting thier own software

Hi,

I normally do a variety of tasks including software development.

On my latest project, however, I'm managing the project and another developer.

This developer has a habit of not testing bugs when he fixes them. I.e., I test, find a bug, and post it to him.  He reports back a somewhat vague "bug fixed, here's the new version".

I test and verify bug still present. This goes round and round.

What I'm considering:
1. Make sure that I've given him a simple test.
(Do a, b,c and you should get result Z).

2.  Asking him if it's reasonable that, once I id a bug, that he test before declaring the bug fixed. 


Any other suggestions?

Mr.Analogy
Tuesday, August 03, 2004

yell on him


Tuesday, August 03, 2004

Usually this kind of ring-a-round-the-roses is down to a confusion about what the actual bug is.  The reporter thinks of it as X and the developer is convinced its Y, they fix Y (which may never have been broken), and carry on their merry way.

This is why I prefer reporters of bugs to Close them rather than those that fix them.  I use a status of Completed to signify that I think its fixed, Closed is when everyone agrees, or some length of time has taken place as to make it irrelevant.

Simon Lucy
Tuesday, August 03, 2004

How about asking him to provide you with test data/conditions that were used to verify the fix ?

Nemesis
Tuesday, August 03, 2004

This is why in FogBugz, when the developer resolves that a bug is Fixed, it gets assigned back to the OPENER for them to verify and close.  If it isn't fixed, they just reactivate the bug.

Like Simon said, this is usually a result of opener finding bug X and developer reading that as problem Y and fixing Y.

The simplest thing to do is just make your bug description like so:

1. Steps to Repro
- install app
- start app
- click file
- type "xxxx"

2. Observe
- program crashes

3. Expected
- file to be opened

Michael H. Pryor
Fog Creek Software
Tuesday, August 03, 2004

+++What I'm considering:
1. Make sure that I've given him a simple test.
(Do a, b,c and you should get result Z).+++

this sounds like exactly the thing to do.

muppet
Tuesday, August 03, 2004

How about asking him to first re-create the bug in the current version and only then fix it. This will ensure that he sees the same bug and knows how to test it after the fix.
if he can not reproduce the bug he will come to you to get more details of waht you meant.

OKK
Tuesday, August 03, 2004


I expect my developers to investigate the root cause of the bug and record that in the issue tracking system before they fix it.  I then have then record the fix they applied, and the steps they took to test it.

I began this process with my own work, because I found that the problem report often did not give enough detail to really narrow down to the root cause.  I often had to correct the original bug report with more appropriate steps to reproduce, or an analysis of the broader implications of a problem before we could begin work on fixing it.

This information doesn't have to be very verbose; it just has to demonstrate that the problem was properly understood and that the fix was correct.

Craig
Tuesday, August 03, 2004

>>Asking him if it's reasonable that, once I id a bug, that he test before declaring the bug fixed.

Well of course that's reasonable. Although I mean what matters is more whether the bug /is/ fixed or not when he reports it as fixed. If he's some flawless genius that can genuinely patch bugs first time without a recompile / test then good luck to him, but it seems he can't, so shouldn't be allowed to get away with acting as though he can...

Matt
Tuesday, August 03, 2004

in our company some of the guys mark text change type bugs as fixed, and when I check those fix it turns out they didn't do anything. what should i do in this situation? it's a simple text change,


Tuesday, August 03, 2004

I remember one situation where there was a ring around the rosie going on. Turned out there were about 6 different things going wrong, all with the same symptoms. I would fix 1, and the "customer" kept saying it was still broken.

Situation: using a web front end, sometimes, when you tried to view a document, you got a logon box pop up asking for username, password, and domain. Nothing you typed in the box would let you view the item.

Symptoms: you got a logon box pop up asking for username, password, and domain.

Cause: If IIS can't open the ACL for that document, or does not have read permission for that document, you get this message.

One problem: several thousand files (out of about 80,000 files) were "owned" by NT accounts that had been deleted from the domain.

Another problem: several hundred files used unicode in the file name, and the combo of unicode and ascii caused IIS to have fits, thinking the files were "unowned". Dang european branch using funny letters.

Another problem: several thousand files had filenames which were more than 254 characters long. If the file is D:\.....\filename.doc and the whole len( ) is > 254, then many NT security objects can't handle it, nor can they access the ACL for the file. OMG! its unowned again! Couldn't you fix it the first time, you worthless programmer from another planet, you?

Another problem: the screaming customer put read/access restrictions on several hundred files. They were  shown how to do it correctly: accessing the file through the file system and through the web front end used different permission sets.

Moral of the longwinded story:
Many problems/bugs have symptoms virtually identical to others. It would be most helpful if you were able to show a test case to the programmer. They might be incompetant, or they might be fixing a different problem. It is hard to tell the difference from a tiny sample size.

Peter
Tuesday, August 03, 2004

The test is a big part of it. If there is no way to produce a result from the test, i.e. an email fires off, it may be hard to tell if something is working.  Be sure to have a test where the test easily demonstrates that the component either works or doesn't (no ambiguity regarding the bug documented).

sir_flexalot
Tuesday, August 03, 2004

Is his name muppet?

\
Tuesday, August 03, 2004

couldn't be, I'm closing work orders left and right here and they are never seen nor heard from again.  I'm just too cool for school.

muppet
Tuesday, August 03, 2004

"How about asking him to first re-create the bug in the current version and only then fix it"

Excellent suggestion. Basically, I'll ask HIM to create a test if I haven't done so already.

Test Driven Design principle. Write test. Fail Test. Write code. Pass test.

Mr.Analogy
Tuesday, August 03, 2004

"and when I check those fix it turns out they didn't do anything. what should i do in this situation"

Remember that violence isn't the first option to consider, it's just the most satisfying option available.

There's only so much you can do to educate the wilfully evil and vindictive.

(Oh, and check that when they say the problem is fixed that the fix wasn't actually "it's fine the way it is - quit bothering me with things that aren't bugs." If they're still lying about doing things that they didn't do, then remember to choose the most satisfying option available.)


Tuesday, August 03, 2004

*  Recent Topics

*  Fog Creek Home