InfoQ – Guidelines for better unit testing
InfoQ has a treasure trove of good advice. Go read it.
InfoQ has a treasure trove of good advice. Go read it.
This is something that I used to hear from the developers. I bet I used it as a developer and then I got a change to use this phrase today. I have a small task scheduled to run on a server to collect bug information. It ran every day at 3am, until a month ago.
In the beginning it was dark, and procedural. So for instance, if you wanted feedback on a feature, you would either communicate it verbally, send screen shots, or wait for the release. Then the managers rebelled. We saw the obvious problem here – our customers needed to actually use the software to give feedback, sooner
This number surprised me. In all 3 projects (every project has a different size, complexity and team) there’s a 75% rate of open non-reproducible bugs. What does this mean? I know we’re not doing enough to reproduce bugs. I take that as a given. I also think that since it’s more easy to fix reproducible
During the management review, we discussed the fact that although there’s extensive testing, critical bugs slip through. One of the PMs, who is a big proponent of exploratory testing, said we’re concentrating too much on writing test procedures, and less on testing. I did actually produce the numbers, thanks to the newly implemented MS Project