Finding and raising good bugs is something every tester should know how to do and should take the time to do properly. It may cost you a couple of hours to raise a good bug, but you'll be saving developers hours of installing wrong versions of the system trying to find the right combination that leeds to reproducing and ultimately fixing the problem.
When you raise a good bug, goodness follows:
- Someone can look at the bug and figure out what's wrong without having to waste time.
- Anyone with the right hw environment can reproduce it and therefore fix it.
- The problem will be gone soon, and you'll be able to use that part of the system from then onwards.
When I look at a bug and see:
Ubuntu doesn't install.
Unity doesn't work.
… I want to cry. Because these two descriptions are the worst bugs ever, they don't say what is not working, nor how to reproduce it, no indication of what kind of system Ubuntu was running on, or version of the OS, they don't even say what the user was doing / trying to achieve when everything went south, or whether there are conditions that need to be met for the bug to be reproduced. They are essentially useless bugs.
When I do testing and I find a problem I know it is going to take me a while to raise it, because there are some things that need to be done to be thorough:
- Is the problem consistent and reproducible, i.e. does it happen every time I do the same thing?
- If it only happens sometimes, can I determine the factors that make it more likely to occur?
- Does it also happen in this other hardware, on a VM, on my laptop, on the other laptop? (This tells me whether developers will be able to reproduce it to fix it)
- Which logs do I need to add to demonstrate my system was in a problematic state?
And once I have put the bug in the database, I ask myself:
- Is this the only problem or is this area problematic and has more than one issue? And continue to test cases around the one found, to make sure the problem was isolated or to start the bug raising process again. This process is called exploratory testing, when I know which area of the system I need to explore and I poke around the functionality to make sure it is solid and behaving as expected. Exploratory testing needs to be done in a scientific way to be fully useful, documenting the things that I tried and making sure there's no bugs left for other people to find in the vicinity.
Making sure the area is sound helps, because there is going to be someone looking at one bug, so they may as well fix other problems if there are more problems associated with the initial issue.