Once you move into writing software, you have the best opportunity to set the standard of quality that your team will follow for the duration of the project. Let things slide early, and it’s unlikely higher standards will emerge naturally during development.

It can often be tough to balance getting the ball rolling with putting your infrastructure in place. While the up front investment isn’t trivial, the dividends paid will be enormous. Alternatively, if you have a legacy codebase and would like to begin improving the quality, these would be your likely first steps.

Logistics & Setup

One of the best ways to think of quality and testing is that they should permeate everything the team does. This begins with setup and configuration. With each of these fundamental tools, the sooner they’re implemented, the easier it is to get them up and running. Similarly, if any of these processes break down as development proceeds, it’s imperative that you address those problems as soon as possible before they spiral out of control.

Source Control

Source control will almost certainly become the foundation upon which you'll build all of your future quality processes.

Automated testing

Setting up an automated test suite is likely to be the most manual of these processes, but lowering the friction for developers to write automated tests, you're ensuring that developers will embrace automated testing but follow the same standards when doing so.

Continuous Integration

Once your automated test suite is in place, you'll want to set up continuous integration to make sure that the tests are run automatically every time someone modifies the codebase.

Release management

Release management will grow organically with the project as you increase the complexity of your infrastructure and as you move into additional environments, but it works best if it starts with a simple core on day one and grows slowly.

Environment Setup

Depending on the size of your team, this may not be as high of a priority, but having a scripted and consistent setup across each developer's computer will go a long ways to help avoid the "works for me" scenario where a bug is actually caused by an underlying machine configuration issue.

Static Code Analysis

This will depend on your technology stack, but the sooner you're automatically reviewing the quality of your code's organization, the sooner you can prevent it from spiraling out of control.

Platform and Device Testing

While this could be as simple as using a hosted tool running virtual machines to test, your requirements may need multiple devices. Organizing and obtaining physical devices can be a challenge that's worth starting on well in advance of needing them.

Peer/Code Reviews

Code reviews have proven to be the single most cost-effective method of avoiding software defects. Good code reviews can catch as much as 60 percent of a project’s defects. ¹ When you consider the added value of knowledge transfer and educating junior team members, the benefits are incredible. Despite not being a hot topic, code reviews are very widespread amongst companies that truly value software quality. ²

While you can’t automate code reviews or configure them to be a part of the process, making sure to set the expectation and commit the time to doing them early on is key. Despite the surface-level simplicity, doing code reviews correctly and getting the most value without spending too much time is challenging. Like any other skill, it requires deliberate practice. If you’re ready to dig in and learn even more about code reviews, I highly recommend Best Kept Secrets of Peer Code Review by Jason Cohen.

Bugs During Development

With design and development, your issue tracking will evolve to begin including bug tracking. At this point, you’re using source control, hopefully writing automated tests, and beginning to log the occasional development bug or issue as new problems arise.

Even though you may not have entered your first testing cycle, it’s still important to have a bug tracker set up to keep track of any bugs that are uncovered and can’t be fixed right away. This can help you ensure that these bugs can be fixed prior to going into testing, thus saving time by avoiding duplicate reports. Ideally, developers will be fixing bugs as they encounter them, but that’s not always possible. In those cases where the bug can’t immediately be fixed, it’s imperative that it gets logged so it can be fixed prior to testing.

Issues During Development

As the team begins writing software, they’ll also be learning more about both the domain and the subtle challenges brought about by some of the requirements. These aren’t always bugs, but they’re definitely worth tracking and discussing. For instance, the team may have decided on a certain third party plugin and uncover some key limitations during implementation. These limitations can be just as crippling to a project as a show-stopping bug if left unchecked. An issue tracker helps make sure that these kinds of problems can and will be addressed.

Wrapping Up

At this point in the process, the most important thing to remember is that this is your chance to set the tone for the upcoming development. It’s often tempting to cut some corners to get the ball rolling on development, but if you don’t lay the foundation for quality with these tools early on, adding them later will not only be difficult but unlikely to happen. Make time to make the investment up front, and you’ll save time down the road.

As design and development wind down, most issues should be resolved and completely closed out at this point. There may still be a few lingering bugs going into quality assurance, but that's alright as long as they're small and on the radar. Let's move onto testing your results.

1. Forrest Shull, et. al., What We Have Learned About Fighting Defects (2002), 6. ↩
2. Jason Cohen, Steven Teleki, and Eric Brown, Best Kept Secrets of Peer Code Review (SmartBear Software, 2013), 14. ↩