Join Aaron Dolberg for an in-depth discussion in this video Interpreting bug models, part of Foundations of Programming: Software Quality Assurance.
- Now that you have a basic overview of what a bug model is, I think it's important to dive a little deeper into what the data means to different people on your team. Some people may argue that giving a bug model to much emphasis can be a hit to morale if the project is off. Developers may feel that they aren't pulling their own weight in helping keep the open bug count under control, or that the management team is setting unrealistic expectations. Now others might argue that highlighting when your off on your projections may raise unnecessary red flags to your executive leadership, and these can be true.
But when looking at a bug model, and how it matches your current reality, it is critical that you are viewing it as it relates to you and your specific responsibilities. If you're a manager, you've been tasked with overseeing the project and all of the work that's going into it. This is going to include new feature development, as well as bugs that need to be addressed before you ship. When you look at your bug model, you should be thinking about the right balance to make sure that you're giving emphasis that ensures the product is being built as intended along with meeting your overall quality goals.
If you find yourself in a situation where you have too many defects that need to be addressed before a deadline, you might have to make some hard choices about cutting less critical functionality from your release. Or, revisiting the date in which you can actually ship your product. Tracking the cumulative number of items you're intending to fix helps keeps things in check so you don't up in such a dire situation at the last minute. It gives you visibility into times when you need to revisit what you have open and assigned to your development team and make sure that the workloads are balanced and realistic.
It allows you take the human factor into account and it empowers to prevent the team from burning out. Development takes time and occasionally we find ourselves in a situation where there is much we would like to do but time is limited. So, unless you have a way to stop time, you need to take a higher level view of all of the work that's left, and make informed decisions about what's an acceptable trade-off and what's not. If you're an individual contributor, you should be well aware of the work that's assigned to you and the part that you play in the whole process.
Taking a deeper look at your assigned tasks and open bugs compared to where with the team is according to the model, is an opportunity to work with your management team and help keep things on track. If a model is significantly off, it's rarely because of a single individual. You need to keep in mind that it's a group effort to deliver your project as intended. As an individual contributor, you are likely going to have specific expertise into one particular area and you should be able to highlight when the open bug count puts new development at risk.
You have the ability to take a number and present it with the depth that allows the right decision to be made. Regardless of the role you play, you should think of a bug model as a tool that helps monitor and manage what you've set out to deliver and the reality of what it will take to meet your definition of done. Being off of your model doesn't necessarily mean that your team isn't working hard and it should never be taken that way. It's an indicator that your reality isn't what you expected it to be.
And it's also a chance for everyone to contribute to getting things back on track using whatever means are necessary.
- 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