Join Aaron Dolberg for an in-depth discussion in this video Recording defects, part of Programming Foundations: Software Quality Assurance.
- Throughout the course so far, I've talked a lot about testing and techniques. And I mentioned bugs quite a bit. But we haven't actually talked about the bug record itself in detail. It's a simple concept, but it warrants a brief discussion. And we've already covered the basics. A good bug record contains the simplest and most basic steps required to reproduce an issue. Keeping this in mind will ultimately help your developers identify where the problem is and how it can be fixed. When logging an issue, you should be thinking about how you would tell a computer what steps to follow in order to reach a specific endpoint.
If you think of it this way, you're less likely to track items that are vague and expensive to interpret in order to resolve. Incorrectly reporting an issue can also lead to a situation where you may think a bug is no longer reproduceable when in fact a real issue still exists and needs to be addressed. Imagine an abstract example where I have a room. And somewhere in this room is an invisible object that I'll trip over if it's in my path. Let's say I'm walking around the room, and at one point I trip over this object.
But I also continue walking around the room for a bit longer. This can be similar to when people hit a bug in an application. They use it for a while, experience an issue, and maybe keep using it a bit more. They know a bug exists, but they're not sure where or what they did to produce it. I have the same problem in this example. There's an object I tripped over, and I'd like to get rid of it. But I did a number of things, and when I try to retrace my steps, I may not experience it again. I know it's there, but I just can't see it.
Here, I can't simply state that if you walk around the room, you'll absolutely find the object. I might not find it at all. In testing, I'd be more systematic until I found the issue. And I'd also be sure to communicate the exact steps to reproduce the issue. Rather than having a bug record that looked like this, walk around the room until eventually you'll hit some object and trip, I should be reporting something like this. Start at the bottom left corner of the room. Walk towards the top left corner of the room.
The result is, halfway across the room, you'll trip over the invisible object. I mentioned this example was abstract, but it's a situation that's all too common in bug reporting. Individuals reporting a bug don't always acknowledge the simplest way to reproduce a bug. And the result is a convoluted record with vague steps that alerts a developer that a problem exists but it doesn't really tell them where. The important takeaway here is that you should always be focused on logging clear and easy-to-reproduce steps.
Much like creating test cases, you want to be writing the simplest steps that will help you get to the bottom of a problem quickly. A good quality engineer will make this a standard practice and take it upon themselves to assure that every bug meets these standards.
- How to think about quality
- Incorporating black box, white box, and grey box testing into your process
- Understanding your quality goals
- Ranking issues by priority and severity
- Testing core functionality
- Testing the backend
- Using a test case management system
- Interpreting bug models
- Recording defects automatically