Incorporating code coverage as an integral part of your .NET development processÂ is not as simpleÂ as evaluating code coverage tools and picking one. Â Although it is critical to ensure that the code coverage solution tool you select can generate anÂ unified coverage number across your team, there is more to code coverage than metrics.
This webinar reviews several of the key organizational issues that must be present in order to measurably improve the overall quality of your .NET code base. Â As we will discuss, the organization and its approach to quality is crucial and helps balance the trade-offs between coverage and risk. Â Other key items we discuss include the need for a team-based approach and a deeper understanding of what different code coverage metrics reveal.
Code Coverage and your .NET Team
Hello and welcome to our NCover webinar on code coverage and your .NET team. Today we are going to discuss some of the key trends we see in the highest performing .NET development organizations. This is based on our experience over the past ten years and literally the thousands of developers and development organizations weâ€™ve worked with around the globe. Letâ€™s get started. The first trend we consistently see among these groups is that quality truly is a part of their culture. Itâ€™s not just a buzzword and itâ€™s not just a department. One of the activities that they engage in as part of this culture is that they are constantly asking themselves, â€śhow do we know our code is good?â€ť What these organizations do know is that great code is not a matter of of hope and, although there is obviously a ton of effort that goes into designing, testing and delivering these applications, effort alone does not indicate that they are going to be successful. In fact, itâ€™s not even whether or not they intend to deliver a great application. Of course they do. I donâ€™t think any of us get into this intending not to deliver great software applications. What these organizations have infused in their culture is an understanding that great code is something than can be measured and embracing the concept of measurement across their organization. What we have seen at these organizations is itâ€™s not just a matter of if they have metrics in place but itâ€™s have they embraced the concept that â€śwe really want to deliver great applicationsâ€ť as part of who they are and at these organizations delivering high quality applications is really celebrated part of an achievement in development, in QA and even in support and itâ€™s not just a requirement or a box they have to check off. This leads us into the second common trend we see at these organizations and thatâ€™s an understanding that itâ€™s â€śteamsâ€ť that really deliver. Individuals contribute, individuals are important but at the end of the day itâ€™s about the teamâ€™s ability to work together and deliver great applications. Some of the key characteristics of these teams is that they are always looking for feedback and not just feedback at the end of the process, but throughout, as part of an agile development process they want to know as quickly as possible if there are issues so they can direct resources and keep them from becoming larger issues. These results are shared team-wide ensuring that each group and each individual within the group is able to engage in the important process of directing their limited time and resources to deliver the best possible results. In order for this work everyone obviously has to be on the same page. Development has to be working hand-in-hand with QA and they have to be unified by management through a common set of goals and a common focus on quickly identifying trouble areas and knocking them out. That brings us right in to our third and final trend and that is knowledge that confidence can be measured. Every development group, regardless of size or regardless of formality, is engaged in some form of testing and what you know is that those tests give you confidence in your code. But that is only half the story because code coverage is what gives you confidence in your tests. What these groups know is that it is not how many tests you write or how long you run them, itâ€™s â€śdo those tests fully exercise your code base?â€ť Letâ€™s look at three code coverage metrics. The first metric is branch coverage. Itâ€™s how we â€śmeasureâ€ť success. Branch coverage refers to the percentage of individual code segments, or branches, that have been covered during the testing of the application. Branch coverage goals will vary across organizations but we typically see a target range of between 80 to 90 percent. Itâ€™s worth noting that each additional improvement in branch coverage typically requires greater effort. The next metric is sequence point coverage. If branch coverage is how we â€śmeasureâ€ť success, sequence point coverage is how we â€śachieveâ€ť success and itâ€™s primary purpose is to help you figure out how to increase your overall branch coverage. Sequence point coverage refers to the percentage of sequence points, or actual lines of code, that were covered during the testing of the application. When used with source code highlighting it allows you to quickly identify those areas that need additional testing. This brings us to our third most common code coverage metric, change risk anti-patterns. If branch coverage is how we â€śmeasureâ€ť success and sequence point coverage is how we â€śachieveâ€ť success, change risk anti-patterns let us know how we can â€śmitigate the riskâ€ť or â€śbarriers to achieving success.â€ť Change risk anti-patterns is a well accepted industry metric that scores the amount of uncovered code against the complexity of that code. It really lets you know how risky your overall code base is based on complexity. Your two greatest assets in keeping down your change risk anti-patterns score, and also reducing the overall risk of your code base are modularity and readability. Regardless of the specific code coverage metrics your organization may choose to focus on, what we have seen time and time again is that integrating code coverage into your team-based development process can have a significant impact on increasing confidence, reducing bugs and improving the overall quality of your code. Whether you are an individual developer working within Visual Studio, a member of QA or a manager looking for better results and better visibility, NCover has a solution for you. In order to learn more about NCover, we encourage you to visit us online and access any of our free resources including videos, articles and support documentation. When you are ready to take the next step, we offer free, fully-functioning versions of all of our software products. If you donâ€™t see the trial you want, get in contact with us and weâ€™ll setup a custom evaluation specifically for your team. If youâ€™re short on time and looking to get started as quickly as possible, we encourage you to request an online overview where one of our Integration Resources will work with you one-on-one to show you exactly how best to put code coverage to work in your organization. We appreciate your time today and hope you found todayâ€™s webinar useful. If at any time you have questions, please, donâ€™t hesitate to ask. Thanks again and we hope you have a great day.
The post Code Coverage And Your .NET Team appeared first on NCover.