How to develop high-quality software

What if we take an approach to software development that would significantly improve software quality? As you begin to design a system, think about how to make “manufacturing” and testing as efficient as possible throughout the entire product lifecycle.
When a physical product is designed for manufacturing, a lot of time is spent on organizing how the item is built and testing the completed product. Manufacturing issues and testing processes are addressed during the design phase, not at the time of production. Consider the design of a circuit board. It is necessary to include test points on a board, as they can’t be added later. While software affords the luxury of being able to include the tests later, the longer one waits, the more expensive it becomes.

Design software with testability in mind

During the initial design and prototyping of a software system, the focus is on functionality and performance. These two items are extremely important, but how useful are they if the resulting program is full of bugs and takes too many resources to maintain? If you are able to shift your focus to designing with “testability” in mind, or at least including it early in your process, then your resulting software code would be far higher in quality. In return, it leads to greater saved opportunity costs down the road. Consider the initiatives below to start moving in this direction.

Steps to test your code easily

High-quality software needs a peer review process

A great starting point for improving testability is to begin paying close attention to coding style and architecture. While size constraints and time-critical components still exist within applications, the overall size and lifecycle of an application have gotten much larger and longer. This increase in size helps to accentuate the benefits of easy to understand code.

Large, bug-addled programs often contain piles of technical debt. One could make the argument that this, in turn, results in the need for greater QA expenditure and thus increased development cost of the product. Alongside this, a lower quality, buggier product also harms the image of the product and producer to the customer which may ultimately result in a lost user.

A related practice to adopting new code styles is implementing a peer-review process. This allows developers not only to familiarize themselves with other aspects of the product but also helps ensure that each developer’s code is readable to someone other than themselves.

Establish a repeatable workflow with metrics

The best method to shift a company’s cultural focus towards high-quality software is to establish a repeatable workflow with metrics for any team member who is undertaking quality improvements. It’s important to find a middle-ground of allowance. Don’t be too lenient allowing buggy code. Don’t be too strict preventing a new version from ever being released. These workflows must be appropriate and take into account the circumstances of your organization and product.

It would not be prudent to try and achieve 100% code coverage on an application that has existed for decades. Instead, put this cultural shift into place by performing completeness testing for all new code additions. The code can then be peer-reviewed and tested for correctness. In many cases, doing something is a step better than those who do nothing to improve their code quality. It is also important to show team members tangible results of this new effort as overall issue counts should move down. This also gives QA teams more time for deeper, more efficient, and more comprehensive testing, improving your development of high software quality even further.

Test automation for high-quality software

Another way to take the pressure off of your QA team is to implement some level of test automation (more: How to test like Google using test automation). Often, organizations perform testing periodically via manual processes rather than constantly and automatically. Alongside this, similarly to different coding styles, each developer can implement their own testing methodology rather than operating through an organization-wide platform created for testing. This creates a disconnect between the piece of new code and the master branch. It also creates a time lag between when a bug is introduced to the code base and when it is found. The longer the bug lies buried under newer code additions or hacks on top of the original issue, the more difficult it becomes to fix. Automated testing, e.g. with VectorCast catches these issues before they are merged.

Further readings

• White paper on how to develop high-quality software
• Cost of fixing vs. preventing software bugs
• How to test like Google using test automation