Modern programming environments have come a long way, with powerful development libraries, rapid development frameworks and fancy new language features. But I think the biggest advance in the past ten years has been the widespread adoption of automated testing. In my opinion, there are really two basic ways to produce quality code.
- Quality by Specification focuses on making the definition of the project as stable as possible so that the code-base can settle on a stable configuration and quality assurance staff staff can verify the program against a written definition. By making changes few and predictable, testers can verify the product functionality with a manageable amount of effort.
- Pros – The earlier the scope of the project is understood, the easier it is to plan and execute. For line of business applications and enterprise projects where the requirements are well-known ahead of time, this approach may work well.
- Cons – Often software is not completely understood before the user has interacted with it. As a result, either the specification process is long and expensive, or software is not specified well enough. This is especially true for a very dynamic product, such as a consumer web site where the features can change very rapidly.
- Quality by Verification focuses on making tests automated and quickly repeatable so the project can change rapidly without unsettling the quality assurance staff. As the programmers’ intent changes, the tests move with them. Automated tests also uncover hidden dependencies between different pieces of a large project (as breaks ripple through a project under rapid change, the tests highlight the issues and point developers to the problem.)
- Pros – Results can be seen earlier and the project can change and grow more quickly as requirements are discovered. Testing allows for dynamic development environments like scripting languages. Automated tests can live as long as the code and offer continual validation of program output long after they are created.
- Cons -Automated testing can be difficult without a disciplined approach to software architecture. It is often not feasible to adapt a code-base to automated testing if it was not designed with that in mind to begin with.
<li><strong>Quality by Specification</strong> - tightly controlling product specification and defining up front as much of the functionality as possible to minimize unknowns and limit project risk.
<li><strong>Quality by Verification </strong>- continuously monitoring and verifying program outputs with automated scripts to make sure they match up with the programmer's intent.
I hope it’s clear that the most successful teams use elements of both approaches, but I think it’s been interesting to see the shift from specification-based quality management to an increased emphasis on automated testing.
What approaches do your teams use? Where do the best quality gains come from?