Test Coverage explained..

What is Test Coverage?

Amount of testing performed by a set of test cases is called Test Coverage. By amount of testing we mean that what/which parts of the application program are exercised when we run a test suite. In other words, test coverage is defined as a technique which determines whether our test cases are actually covering the application code and how much code is exercised when we run those test cases.

The basic coverage measure is where the "coverage item" which have been identified, and then check and see whether a test has exercised or used this item.

But remember!! 100% coverage does not mean 100% tested!!

What are the advantages of Test coverage Analysis?

  • We can prevent defect leakage using Test coverage analysis. Defects can be prevented by this early stage of application life cycle.
  • It also creates additional test cases to increase coverage. The test coverage analysis can determine the decision points and important path made in the application which helps us to increase the test coverage.
  • With this we can check the paths of the code which are not tested (exercised).
  • We can determine the quality of the testing we are performing.
  • We can find the easily gaps in requirements, test cases and defects at an early level and code level.
  • It helps in determining a quantitative measure of code coverage, which indirectly measure the quality of the application or product.

What are the disadvantages of Test Coverage?

  • In test coverage we can find the gaps in application code that has been written. There is no measurement of the part of the software that is not coded. Thus it has coverage only of the written part (it measures coverage of what has been written).
  • If a specified function has not been implemented or a function was omitted from the specification, then structure-based techniques cannot say anything about them it only looks at a structure which is already there.

How do we perform Test Coverage Analysis?

  • Test Coverage can be implemented by Static testing techniques. These test techniques include peer reviews, code inspections and code walkthroughs.
  • We can convert the adhocs defects into test cases and analyse test coverage.
  • We can use code level tools and automation to achieve test coverage at unit level.
  • We can use test management tools to perform functional test coverage which will establish traceability between, requirements, defects and test cases.
  • We can use Bi- directional traceability matrix to achieve test coverage.

Why to measure code coverage?

  • To know whether we have enough testing in place
  • To maintain the test quality over the life cycle of a project
  • To know how well our tests actually test our code

Where to apply this Test Coverage?

Test coverage can be used in any level of the testing. Test coverage can be measured based on a number of different structural elements in a system or component. Coverage can be measured at component testing level, integration-testing level or at system or acceptance-testing levels.

We can also measure coverage for each of the specification-based techniques or black-box testing:

• EP: percentage of equivalence partitions exercised (we could measure valid and invalid partition coverage separately if this makes sense);
• BVA: percentage of boundaries exercised (we could also separate valid and invalid boundaries if we wished);
• Decision tables: percentage of business rules or decision table columns tested;
• State transition testing: there are a number of possible coverage measures:

— Percentage of states visited
— Percentage of (valid) transitions exercised (this is known as Chow’s 0- switch coverage)
— Percentage of pairs of valid transitions exercised (‘transition pairs’ or
Chow’s 1-switch coverage) – and longer series of transitions, such as transition triples, quadruples, etc.
— Percentage of invalid transitions exercised (from the state table).

The coverage measures for specification-based techniques would apply at whichever test level the technique has been used (e.g. system or component level).