NCover allows users to quickly create new code coverage projects and then refine those projects to promote overall code health and greater quality.
First released in 2003 by Peter Waldschmidt, NCover is the leading .NET coverage tool that helps development and quality assurance teams improve their tests- and therefore their code- by revealing which areas of code have not been tested. While this sounds simple, the implications for code quality, team performance, and company results are significant. NCover was created to help improve tests, catch bugs earlier, reduce development costs, make code easier to maintain, and to improve end-customer satisfaction.
"Code coverage" shows which areas of code have been tested ("covered") and which have not. Before release, every team tests their application in some way, even if the testing only involves manually using the application itself. However, many teams still do not know how well they have tested their application before it is released. Code coverage provides critical information to show teams where to focus their testing.
Regardless of the testing process used, code coverage can provide insight and focus to help teams improve their testing. In waterfall development processes, pre-release testing is the last work done before release, so robust and thorough testing is critical. Despite the importance of this stage, many organizations time box this testing phase, so efficient use of time is required for project success. Code coverage metrics can provide feedback that allows teams to efficiently focus on untested areas and not to duplicate efforts. Just as important, code coverage can help testers and developers work together to define the best testing strategy given time and resource constraints.
As teams move towards an agile development process, many adopt continuous integration of the build with frequent check-ins by developers and automated testing to prevent regressions from ongoing code changes. Code coverage metrics can help the team monitor their automated tests as the code base and automated tests grow and change. Just as important, code coverage can help developers improve their tests before they commit to a build. Better testing before check-in means less bugs. Less bugs mean fewer broken builds. Fewer broken builds mean more development time and less waiting by the development team. This cycle means HUGE ROI. For the teams moving towards a test driven development process, code coverage metrics are the best way to get rapid feedback on the tests- and code- being written.
With software, the only constant is change. The company's direction, the projects, the teams, the tools, the processes, and the code itself are all in constant flux. As companies get larger, the code base gets larger and maintenance or ongoing development may shift from department to department, team to team. Mergers, acquisitions, and restructuring often include legacy code that must be integrated or maintained. Legacy code can be tough to maintain or change without causing major unintended problems in other areas of the code base, especially if it is not code that is familiar! New projects are expected to flow more smoothly than the last one, cost less, and deliver more. Code coverage used throughout an organization can provide some consistency when all else is changing by providing benchmarks, goals, and rapid feedback to the teams tasked with making their project work.
A major business trend of the last two decades is the shift from in-house development to outsourced development. However, many teams aren't sure how the quality of the development work should be measured. Relying solely on whether user acceptance tests have been presents two main risks. First, the user acceptance tests, however well thought out, may not effectively cover an application's core code base and major bugs may still be present. Second, many acceptance tests are not defined well or are defined by the company doing the outsourced development work. Code coverage can provide a key measure of quality control on outsourced work being done. In fact, many companies now require code coverage thresholds to be met to consider a project as complete.
Code coverage can be used by large and small teams who are using a range of development tools and processes to help improve code quality, customer satisfaction, revenue, productivity, and communication while also helping to reduce costs and risks.
Here are some of the top reasons your team will not only love using NCover, but will come to rely on it for all of your future development work:
Our customers are from many different industries and all have different development and testing approaches, but they have all recognized the negative impact low quality software can have on an organization. Despite the variations in our customers, we see recurring themes that have created interest in code coverage and NCover and the themes are many. Perhaps some of these apply to your team or organization.
NCover is already used by over 1 in 4 Fortune 100 companies who count on NCover to help them improve their code and eliminate bugs. That doesn't even include all of the government, education, and non-profit organizations that use NCover too.