Thu, 27 Mar 2014
Bug reports
I've noticed that many testers, project/program/product managers, ... have no idea on how to properly report bugs, or request new features.
It's well known that developers will do everything they can to avoid actually writing code, so it's vitally important to avoid falling for their traps when reporting a bug. My fellow developers will be angry with me for giving away this secret information, but, well, it wants to be free!
Here are a few hints:
-
If you have multiple products or configurations avoid telling the developer which one you're talking about. This forces him to verify and fix all of them. If you're naive enough to specify the product he won't fix any of the others if they happen to be affected as well.
-
Sometimes a picture doesn't say quite as much as a thousand words. There are two schools of thought: the large and the small.
The first option is to make sure the screenshot includes everything: your complete desktop, your e-mail client, the application, your second monitor full of goat pornography and bonzi-buddy, ...
Ideally you'd save this screenshot as an uncompressed bitmap so it's at least 150MB in size. Don't let it be said that you didn't provide any information. 150MB is a lot of information!
For bonus points, use a video closeup of the screen. Close enough that you can see the individual pixels. Now that's a detailed report.The second option is to include only the error message. Preferably focussed on the message box with the error message, if possibly cutting off most of the error message itself. A true master will only include the exclamation mark, skull & bones, or other icon.
Focus on the essentials! Compress this screenshot mercilessly. Make sure it's completely unreadable.
File lots and lots of bugs. If, for example, your application has four modes dealing with frobnicks and all four nick before frobbing rather than frobbing and then nicking make sure you file four bugs. There's no way these problems are related and could be tracked in the same bug.
-
Make sure to remind the developer that he's supposed to fix the problem. If you report a crash don't forget to tell him that the application is not supposed to crash. If you don't he'll just claim that this is normal, and do nothing.
Include as little information as possible in the bug report. Developers are like kittens. They have a very short attention span and are easily... ooh! A shiny!
If the application spouts a load of incomprehensible gibberish when it crashes whatever you do, don't include that information in the bug report! You don't understand what it means, so there's no way the developer will understand it either. Making him feel stupid isn't going to get your problem fixed any quicker.
Besides, he's a developer, if he was smart he'd have a real job.-
Whatever you do, do not follow up on requests for more information. Asking for more information is a favorite trick of programmers to avoid having to work on the problem. Don't fall for it, don't give him the excuse, so just ignore the request completely.
If the programmer is very experienced and lazy he might go as far as assigning the bug report back to you. Again, don't fall for that, but give him hell about being so lazy! Demand to know why he thinks he can assign bugs to you! His job is closing bugs, not assigning them! Whatever you do, do not give him more information.
-
If cornered, as a last resort, you can offer more information, but even then you can be crafty: make sure the follow-up information contradicts the original report.
-
Offer as much context as possible: make vague allusions to remarks made by a third party, in which no developer was present. You know what you mean, he should know too.
-
Whatever you do, don't attach logs files to the bug report. Instead, keep them somewhere the developer won't find them, so you have some evidence on hand to prove that he's not helping you.
Certainly don't attach logs if the bug is hard to reproduce, or only occurs rarely. The developer would have to wade though thousands of log lines and would never get round to actually fixing the bug!
Developers just *love* reading 'Time under test: +/- 700hours' in a bug report with basically no other details!
Ignore increasingly desperate requests for log files. They're just another form of the request for more information. As soon as you respond you validate the developer's excuse for not actually fixing the bug.
In conclusion, the ideal bug report is "It breaky. You fix.".
In case someone doesn't get it, the above suggestions are NOT something you should do in bug reports. Unfortunately just about all of these are based on one or more bug reports I have received over the years.
posted at: 22:22 | path: /rant | [ 0 comments ]
Sun, 29 Dec 2013
Hotmail
No, I don't use them, but sometimes I send e-mail to people who do. It turns out that they don't like my e-mail. It sends up in the spam bucket.
After finding someone with a little clue who still remembered having a hotmail address I obtained the headers for one of my mails. It had this in it:
Authentication-Results: hotmail.com; spf=temperror ...
The OpenSPF
people explain what this means:
Hotmail does not use live DNS for Sender ID. They have a DNS cache that they
update twice per day. All TempError means is that your domain's SPF record is
not in their cache. To get your record added to their cache, send an e-mail
message to senderid@microsoft.com with your domain in it. They will add it,
but be patient as it's a manual process and the cache only updates twice a
day.
It appears that Microsoft don't even understand DNS (or e-mail). Why does that still surprise me?
posted at: 16:42 | path: /rant | [ 0 comments ]