4 Keys To Successful Team-Based Code Coverage

More and more teams are focusing on the quality of their code. The reasons are pretty obvious. Most everyone has heard the old Benjamin Franklin adage that “an ounce of prevention is worth a pound of cure.” It is particularly relevant today, especially in software development. The cost of errors and bugs, both in hard dollars and resources used to fix them, is typically many multiples of the investment of a good testing process. That is in a good scenario. If the whole world is watching and things go awry, it can be disastrous. No matter what else comes of healthcare.gov, it will always be remembered as a fiasco of a launch.

4 Keys To Successful Team-Based Code Coverage

So, how do you make sure that your entire team is on-board when it comes to delivering high quality code? It is not as easy as sending an email detailing the importance of quality, running some tests or even running a lot of tests. Truth be told, it’s not even as simple as just buying a code coverage solution and hoping for the best.

The following are the 4 keys we have seen from our clients who are successful at team-based code coverage:

1.  Adopt Quality As A Part Of Your Culture

The first key is not easy, but critical, to delivering excellent applications. It is something that has to be preached and practiced day in and day out. How can you get started? Every time code is promoted to the build ask this simple question, “how do we know it’s good?” If the answer isn’t something along the lines of “we tested 92% of all our branches without failures or errors,” there is still work to be done. Ask the question. Demand metric driven answers. And, finally, celebrate as a team when you achieve them.

2. Share Results Team-Wide

The second key requires a high level of transparency as an organization and can be daunting for some, but it is crucial for developing and maintaining a high quality code base. For example, every time development checks in code, submit the coverage based on unit tests. Every time automated tests are run against the build, distribute them to everyone on the team. When QA becomes involved in testing, merge the results of every testing method. Organizations that share results team-wide are able to encourage rapid feedback and are generally more effective in guiding the future allocation of resources than those that do not.

3. Measure What Matters

The third key involves making the decision as a team to focus on metrics that can not only be measured but can actually guide efforts and not just produce pretty graphs. The number of hours running tests, the number of modules touched during testing or even the number of hours spent developing new functionality can all be measured but they are not particularly useful in answering the question “how do we know it’s good.” When it comes to code quality, branch coverage is a great leading indicator of how well your tests are exercising your code. When it comes to understanding the riskiness of the code you have not tested, change risk anti-patterns are where you should look. Remember, you can only measure what matters if you are using metrics that matter.

4. Provide The Team With Tools That Deliver

The final key is all about deploying a solution that can be integrated seamlessly into the development process so that you focus on producing great end results and not shipping around files. When it comes to code coverage, ask yourself these questions about your code coverage solution.

• Can your developers use coverage directly within Visual Studio so they know how they are being measured and take action at the source?
• Can you share project settings and project results team-wide?
• Can you script the merging of coverage results by build ID across all applicable servers and testing environments?
• Can you collect coverage regardless of testing method?
• Are results easily shared and easily interpreted to keep everyone on track and on task?

For teams, these are just a few of the most basic requirements to ensure that your next great application will rock the world…and not your support desk.