Join Aaron Dolberg for an in-depth discussion in this video Understanding your project and quality goals, part of Programming Foundations: Software Quality Assurance.
- When your team is assembled, roles are assigned, and development is underway it could tempting to race ahead with your eyes focused on nothing but the finish line. However, when thinking about quality, there's one critical piece that's needed to put it all together, structure and definition. Keep in mind that without structure and definition, it's easy for items to get lost in all of the moving pieces in your project. You may find yourself looking an at imminent milestone with more work than possible to meet the delivery deadline.
The key is to make sure that you have clearly defined goals for every milestone, and that every member of you team is aware of what they are. It sounds incredibly simple but it can so often be forgotten and it can result in a unmanageable backlog of bugs, and you can find yourself forced to make hard decisions that you wouldn't have had to make with a little bit planning up front. Regardless of your methodology, you need to define what done means for each step in your development cycle. Think of a couple of extremes.
On one side of the spectrum, you could say that once a developer checks in their code for the first time, they're done. No bug fixing is required and catastrophic failures in the software are okay to meet milestone goals. Doesn't sound quite right, does it? Now on the other side of the spectrum, you could state that each and every bug must be fixed, regressed, and closed regardless of how minor it is, or you won't declare a milestone successful until each and every condition is met.
This also doesn't match reality in most projects and you'll end up wasting cycles on trivial items that will have no impact on the success of your project. There's a misconception about quality that it's about achieving absolute perfection. But that's not the case at all. It's about understanding what you hope to accomplish from a quality perspective and working to ensure that your teams meet these goals. This is something that should happen early on in your process. And it's a discussion that should be owned by your quality leader and involve all key stakeholders.
Let's look at a simple project timeline and how this might be viewed. Here, we're going to assume that the project tests milestones that your team will work towards from beginning to end. And this terminology should be familiar to anyone working in the software industry. In this example, it should be easy enough to envision that before you hit your alpha milestone, you want to make sure that you've addressed all high priority items. By beta, you want to hit all the medium priority items. And before release, you want all the lower priority items addressed.
I want to point out that a certain classification of items should addressed before hitting a milestone. I didn't say fixed. This doesn't mean that your not going to be fixing bugs but rather you should be organized and focused on fixing the right items at the right time. You may be making decisions about what your going to be deferring for later assessment or you may make the determination that you don't need to address a bug at all in order to meet your goals. These definitions will be extremely helpful for your team.
Contributors should know what they should be focused on depending on where you are in your cycle, and if you map this out in advance, you'll find it easier for everyone to have a conversation about progress towards any milestone.
- 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