One of the most common pitfalls in software testing is performing too few tests. An inadequate number of tests can lead to gaps in coverage, which allow defects to go undetected until they are discovered by a tester later in development or an end user after release. Neither of these outcomes are desirable, as both will lead to an increase in the cost of development and a decrease in the overall quality of the product.
Equally problematic, however, is performing too many tests. After a certain number of tests have already been performed, executing more provides sharply diminishing returns, wasting tester time and resources and inflating development costs.
Finding the right number of tests to perform is thus central to an effective (and low cost!) testing process. Hexawise’s coverage charts, which show the exact level of coverage provided by a certain number of tests, can help your team strike this delicate balance. Hundreds of companies across a variety of industries use Hexawise’s coverage visualization to take the guesswork out of testing:
A leading health insurance company that provides coverage to over 2.5 million people used Hexawise to identify applications that were being under-tested. The company’s development teams used the tool to generate visual coverage reports that allowed them to immediately identify and rectify coverage gaps, improving both the thoroughness of their testing and the stakeholder confidence in their end product.
A leading Canadian bank utilized Hexawise to create test cases on a high-impact lending application. Hexawise’s automatically generated coverage charts allowed stakeholders to weigh their options and select the right amount of tests that balanced their need for high levels of coverage and a fast testing process.
Hypothetical coverage charts generated in Hexawise
A leading multinational bank implemented Hexawise in the development of a portfolio reporting tool that had consistently suffered from defects in production despite steep testing costs. Hexawise’s coverage visualization allowed the team to avoid both under-testing and over-testing. Both under- and over-testing contribute to inflated testing costs; finding the proper midpoint between the two contributed to a 90% reduction in spending.