Software Health versus Software Quality
Software quality is often measured by the number of bugs remaining in the product, as an instanteneous view on the state of the system (also called external quality).
When software evolution is important we better talk about software health, look at the state of the software over time, how does it respond to stress ? when the load changes ? when the requirements changes ? when the customer base changes ? (also called internal quality)
Developer testing provides an excellent means to ensure software health. What can you do as a developer:
- Start with developer testing now. What problems can you think about, write tests for them. Think about the design, how can can you increase the testability of your code.
- continue with developer testing, also when you are under stress or don't get the neccesary support from your environment
- give frequent attention to the results, look at the numbers
- provide visibility of the software health through your test lists
- if your tests do not occasionally break, you are not testing enough
- Balance between bug fixing, refactoring, and retrofitting tests, keep the software's internal quality at a high level.
- compared to what ? throwing your code over the wall to the testing department will cost you and your organisation a lot more time and effort
- in general developer testing would not take any longer
- reduce cost using automation tools like JUnit, CruiseControl
- fewer bugs, the improvement is substantial
- immediate feedback when something goes wrong
- enabler for other improvements, ie. continuous integration
Listen to a one hour interview about developer testing with Kent Beck on ITConversations