Here is my short list of techniques for achieving quality in software:
- Code-driven Testing
- Programming by Contract
- Heavy User Involvement
- Code Reviews
- Test Automation Reviews
Do you have any suggestions or disagreements? I would welcome other ideas. I might not put all of the suggestions on a “short” list, but I am eager to hear what others are doing these days. Please post your ideas.
In my job, we do the first three practices (most of the time), but do not do code or test reviews very often. However, we certainly do ask for help from one another, which might count in some cases as a “code review.” Below, I’ve provided more details on what I mean by these terms.
|Category||Practice||Description||Qualities Enhanced by Practice|
Favor Code-driven testing where possible
|Write automated tests for all features, and run the tests often. Write them first where possible (also known as Test Driven Design). What do you gain? Automated tests detect coding defects quickly, so they can be fixed before the software is seen by anyone other than the developer. If you write the tests first, you also gain additional clarity in requirements and uncover more requirement defects sooner. And writing tests first helps you ensure you do not “forget” to write tests later.||
|Coding||Programming by Contract||Embed automated assertions in your code to express rules (contracts). Eiffel has this built in to the language (thank you Bertrand Meyer). Microsoft .Net languages have this available in the 4.0 version of the .Net framework (thank you Microsoft).||
|Collaboration||Heavy User Involvement||Involve real users heavily, throughout the process. This may seem obvious, but I challenge you to explain whether you are really doing this on your current project. What do you gain from this? You detect requirement defects quickly, and produce more usable designs.||
|Collaboration||Code Reviews||These come in many styles. Old style code reviews involve a partner or several, reviewing code line by line. Modern alternatives include pair programming which includes code reviews and much more.||
|Collaboration||Test Automation Reviews||These are like code reviews, but you involve multiple people in developing or reviewing test plans. My favorite approach is to do Test Driven Design with input from my team’s professional tester. Usually, the tester first writes some test cases in collaboration with the business analyst and maybe the programmer. Then I translate those test cases into automated functional tests. This raises the quality and value of my tests a great deal. To enhance the technical aspect of the test automation, I may ask for help from another programmer. In pair programming, you automatically get this. If you prefer a more sequential and less collaborative process, there is a detailed article on how to do these on MSDN. Although that article describes a process that is too formal and sequential for my test, it has some good ideas and makes the point powerfully. So I encourage you to read the introduction for principles, and proceed to pursue the implementation in whatever manner suits your culture.||
Tip to achieve quality when outsourcing development:
If you are a developer, you can introduce these practices or adopt them yourself. If you delegate development work to remote development groups, you can use automated tests as a part of your specification. If they get the test to pass, then the code is considered acceptable. This is a smart division of labor. You can have a small, well-informed development team write automated tests, while a larger outsourced development group could write the implementation. Programming by contract is another powerful tool to improve quality in the outsourcing scenario, because it helps to prevent accidental misuse of existing code.