Research & Development for 3D & the Web

Logging Bugs Effectively as a Tester

I’ve only been at it for a short while (just under 4 years as of the date of this post) and it may come as a surprise that logging a bug as a tester is not really that difficult.. Doing so effectively on the hand can be somewhat more of a skill. Something doesn’t work the way you it should or the way you expect it to work, you tell the developer or designer right? Right. Well kind of… There’s a right way and a wrong way to do this and the difference is usually the amount of time spent looking over an issue. There are a number of things to keep in mind when you start testing something which are pretty much just common sense things but all of them add up to make things a hell of a lot easier, faster and therefore more effective.

Planning before you start

Take a bit of time before you start something to look over the documentation if there is some available, look at the specifications and either find a test plan that you have written up which fits the job and edit it with some extra case-specific tests or make a new one specifically for it. I use spreadsheets – they work really well. I’m pretty sure some people at work think that I tend to stare into space a lot or look at my list of tasks and not do anything for strangely long periods of time. That’s OK, what they don’t realise is that I’m “planning” (well most of the time anyway – sometimes I really am just staring into space).

Why all this planning? What a waste of time, especially for a small feature you might think.. I find it very worthwhile and this is because the most important part of logging bugs effectively is logging an issue with short, concise replication steps so that the person you pass it on to can reproduce the issue in the shortest way possible and see what the issue is as clearly as possible. You need to set the stage so that they can see exactly what you did when you found the issue. A bug is not able to be fixed unless it is able to be reproduced. If need be, check the bug is reproducible in different Browsers or different machines to ensure it’s not something specific to your machine. Things like Caching can catch me out sometimes so clearing cache and things is a good idea in some situations too if you don’t have another machine available to use.

Check for Duplicates

Don’t waste people’s time, before writing up a bug of any kind, have a quick check through your logging system and make sure no one else has already logged it (or that you haven’t and forgotten as I’ve found on occasions when a project runs over a long period of time…).

Be Consistent

Use the same test plan framework as often as possible – you can eventually memorise a lot of the tests which makes you able to look for new ones or ways to refine it which makes you a better tester in the long run. When reporting issues, use the same reporting structure. Perhaps having a text file which you can copy/paste and add the details into the blanks is a good way to go, it depends on what you’re testing and how you’re reporting it. These are just a couple of sensible things you can do to make life easier for everyone involved.

Undoubtedly there is so much more to say on this topic however so long as your ironing out bugs and doing so as effectively as possible with constant refining  to the process you’re using you can’t really go wrong. I’m writing this as a read about the best ways to do things so this is just a quick brain dump of my own experiences mixed with other people’s experiences and recommendations.