Bug Reporting

Problems are going to occur. The way your developer handles problems is what sets good developers apart from bad ones. I have never found a website that was 100% bug free; not even the largest websites. Knowing this ahead of time may help you handle problems more rationally.

Do your best to keep emotion and drama out of the situation. When a problem arises, take a deep breath and count to 10. Most emergencies are usually resolved very quickly. What may seem like a major problem to you might actually be a minor technical problem that your developer can fix in 5 minutes.

Your bug reporting procedure should be established during the planning phase of your project. You and your developer should agree on how emergencies are handled as well as non-emergencies. You need to agree first on what constitutes an emergency. Typically on our projects, an emergency is when any part of the site is not accessible by the public. This happens when either a page fails to load or the server is acting slow for some reason. For all other situations, we have our clients submit a ticket to our project management system.

Developers do not like guesswork. When reporting a bug, don’t send an email to your developer with something like “My site isn’t working.” Lack of detail is very frustrating for you developer and the “hunting” time can cost you extra money.

Good bug reporting is an art form that can take some practice to master. To report a bug, you need to give as much detail as possible in a concise document.  Start by giving a brief description of the issue in plain English. Don’t try to analyze any technical issues.

Then, give the exact steps to reproduce the problem. Tell your developer exactly what you were doing at the time the problem occurred. Also, include your operating system, browser version and any virus or firewall software you might be running.

An easy way to send your system details to your developer is http://supportdetails.com. Our customer service people at Real Estate Shows use this site extensively. When a customer reports a problem, they have the customer send an email from that site.

VERY IMPORTANT! When reporting problems, make sure you specify the priority. Be realistic. Is this a mission critical problem? Can it wait a few days? A week? If you don’t regularly specify a priority, your developer should get into the habit of asking the priority.

If your site is inaccessible, check out http://downforeveryoneorjustme.com before contacting your developer. This site will let you know if the problem is limited to just you or if the public is experiencing it as well.

A Few Additional Tips

Brainstorming is a good thing, but there is a fine line between brainstorming and feature creep. As you see your project being built, your mental wheels will start to spin. You will be thinking of additional enhancements to these features. However, if you want them added in your current working phase, be prepared to revise your statement of work. There will be an impact on the schedule and/or budget.

Many developers speak in languages that sometimes I don’t even understand. You will hear them refer to technology using terms and acronyms that will make your head spin. And they will rattle them off like you are supposed to know exactly what they are referring to. When this happens, make Wikipedia and Google your friend. Jot down the terminology and look it up later.

Conclusion

The bottom line is that many of the horror stories that I hear could have been avoided with clear communication. While there are a few bad seeds, I believe that most developers are not maliciously screwing up projects. Several factors may have contributed to projects that went wrong. If you have a developer horror story, I encourage you to look back at what could have been done differently to avoid the problem(s). Learn from it so that you don’t fall into the same trap next time around.

The post How To Speak Geek, Part 4 – Bug Reporting appeared first on Zeek Interactive.