Join Aaron Dolberg for an in-depth discussion in this video How to think about quality, part of Programming Foundations: Software Quality Assurance.
- When you start thinking about quality and what's best for your particular project, it's a good idea to have an opinion as to what you plan on doing and why. Throughout this course, I'm going to assume that you're watching because you're interested in quality and want to understand not only what it means but also why you should be concerned about it. You may also be watching because you want to know when you should start to incorporate quality assurance into your process. Now this is a question that has varying opinions on what the right answer is throughout the industry. Some will argue that development should begin with writing tests, while others believe that it's only necessary to begin testing once functionality is quite mature.
Regardless of when you believe it's an appropriate time to begin formal testing, it's always wise to include everyone responsible for quality as early as possible in your cycle. The more familiar these people are with what your goals are, the easier it will be for them to determine the best test strategy. Ideally, you'll be focused on testing early and often to identify bugs as soon as they arise. It's important to keep in mind that the sooner you know about an issue, the easier it is to address. Let's take an example that takes a step away from software development entirely, but it still embraces some of the principles of incorporating testing early.
Now, when you build a house, you need blueprints, materials, people to put it all together, and someone who will manage the overall project. Before you start, you generally apply for permits. And then you'll have some inspections along the way. Let's say we have our basic framing for our house and an electrician is starting to run wires that ultimately will be concealed within the walls. Once the wiring is in place, an inspector will generally want to schedule a time to inspect the work. Now, some people find this inconvenient and unnecessary, as their perception is that it will slow down progress.
But that's not really the case. If you were to move forward without inspecting to ensure that there were no problems, let's just think about what that might look like. First someone would likely add insulation within your walls. Then, new sheet rock would be installed over the insulation and wiring. Then there's usually tape applied to the seams of the sheet rock. Next, a texture may be applied to the walls. Eventually, they'll be primed and painted. The further along in the process you get, the harder and more expensive it will be to go back and fix a problem that occurred at an earlier step.
Keep in mind, you aren't just paying for the issue you discovered. It's not just a basic materials cost. There's also a human factor in the labor involved. And sub-steps may be owned by different individuals, which can make it more costly. If you had inspected your wiring before anything else was done and found a problem, you would have only a single individual who would have had to fix a single problem. And nothing else in the series of steps would have been affected. In actuality, you would have saved quite a bit of time and money. If you discover an issue after every step has been completed, there can be a lot that has to be undone in order to address it.
This philosophy holds true with software, and it's one that should be embraced. Bugs that are found and fixed early are less costly to address. If you've been thinking about quality throughout the development process, you're able to deploy the right systems at the right time. It's not about delaying a project, slowing down progress, or calling out a single developer who might have caused an issue. It's more a practice of operational efficiency. Not only are you trying to get features implemented, but you're also focused on making sure that they're implemented in a way that meets your overall quality goals and the needs of your users all along the way.
- 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