Creating Test Groups in the Coverage Analyzer

Use test groups to isolate Coverage Analyzer statistics of a particular group of users from all other statistics in the system. You can view and manage the code coverage produced by these users in isolation from all other activity in the system.

Test groups work by storing the statistics of the users in the group separately from all others. (These statistics are also always stored in the standard test groups ALL and COND as well.)

Uses: Test groups may be useful to you in situations like these:

• You want to isolate the code coverage results from specific groups of testers from general activity in the system.

• You use separate users for automatic and manual testing. With test groups you can separately quantify and evaluate the code coverages achieved by these parts of your test suite.

Restriction: Test groups increase the workload produced by the data collection job RSCVR_TRIGGER_COLLECT.

Define as few test groups as possible. Do not define more than 10 test groups in a system.

Guidelines in Development and QA Systems: Test groups can be useful to both developers and Quality Assurance managers. Here are some guidelines for making good use of test groups:

• Users often decide not to set up test groups in development systems.

  On the one hand, developers can use code coverage to validate their unit and functional or integration tests. It is therefore an appealing idea to define a test group for each developer in a development system.

  However, because of the restriction on the number of test groups, setting up a group for each developer is usually not practical.

  The compromise of setting up a test group for each development project also is often impractical. Each project team could then get an idea of how good their code coverage is, especially if the test group is reset before testing.

  But often teams overlap. Since each user can be assigned only to one test group, it is not possible to define groups that are both complete and discrete from one another.

  Further, the ABAP Unit Browser makes test groups unnecessary for checking the code coverage of unit tests in isolation from other activity in the system.

  For these reasons, users often decide not to set up test groups in development systems, or to use them only in special situations. Perhaps, for example, one project team is discrete from all others and can make use of a test group of its own.

• In Quality Assurance test systems, it is usually much more practical to work with test groups. QA managers can use code coverage statistics from test groups as an indicator of the quality of each test suite.

  If you have separate testers for each development project, then you can create a test group per project.

  Alternatively, if you have separate users for automatic and manual testing, then you can use test groups to evaluate these test procedures separately. Or you may be able to use test groups to evaluate code coverage by testing site.

  In all of these cases, you can use test groups to isolate code coverage in tests from activity of other users in the test system.

  If there is no good basis for defining test groups, then use code coverage statistics efficiently by resetting the statistics at the start of test cycles and filtering the statistics with the set of relevant development packages.