Achieving optimum test and requirement coverage is critical for delivering high quality applications to the marketplace. Coverage can be very useful in determining the extent to which code and requirement has been tested. However, at the same time, a high coverage result (something in high 80s or 90s) cannot be taken as a measure of effective testing or an indicator of testers achieving perfection. Leveraging processes and tools that help determine sufficient coverage metrics, account for risk, trim costs incurred from unnecessary tests is therefore important. In this webinar, Nikhil Kaul, Product Manager, joins Engineer, Rick Almeida, to discuss how to balance the trade-off between achieving high test coverage and testing code and requirements that matter. In this session, we will cover: What coverage metrics to use and what percentages to aim for? - How coverage metrics can be misused? - How to use requirement and code coverage well? - What metrics won’t tell you? - Establish the connection between requirement and test coverage.

1. Efficient Coverage Metrics That
Won’t Leave You Exposed

2. Who are we?
2
Nikhil Kaul Rick Almeida

3. On our plate today
3
• Why use coverage metrics?
• Different types of coverage metrics
• Where these coverage metrics may go wrong
• Coverage goals and where to start?

4. Coverage metrics can come in handy in a variety
of ways
4
1
Areas not covered by tests
Indirect measure of quality
2
3
Identifying redundant test cases

5. Variety of coverage metrics are available to
achieve these results
5
Coverage Metrics
Statement Branch Path

6. Let’s start with Statement Coverage
6
No of statements run
Statement Coverage = -------------------------------- * 100
Total number of statements
Statement
Coverage
Branch
Coverage
Path
Coverage

7. Source Code
100% statement coverage doesn’t mean effective
testing
7
Statement
Coverage
Branch
Coverage
Path
Coverage



TestCase Statement Coverage
100%

8. Statement coverage comes with other challenges
8
Terminal condition Do-While Switch Statements
Statement
Coverage
Branch
Coverage
Path
Coverage

9. Branch Coverage
9
Statement
Coverage
Branch
Coverage
Path
Coverage
• Each branch (if statements, loops) has been executed at least once
• Every “if statement” has two distict branches
• No branches lead to abnormal behavior

10. Source Code
To cover 100% of branches, we need one more
test case
10
Statement
Coverage
Branch
Coverage
Path
Coverage



TestCase Statement Coverage
100%
Branch Coverage
50%

11. However, branch coverage can ignore short
circuit operators
11
Statement
Coverage
Branch
Coverage
Path
Coverage
No call to function1
Test Case 1:
Condition 1 = true
Condition 2 = true
Test Case 2:
Condition 1 = false
Condition 2 = false

12. Next comes path coverage
12
Statement
Coverage
Branch
Coverage
Path
Coverage
T F
T F T F
1 2 3 4

13. Source Code
50% path coverage with TT and FF
13
Statement
Coverage
Branch
Coverage
Path
Coverage



TestCases Branch Coverage
100%
Path Coverage
50%

14. You are missing 2 paths
14
Statement
Coverage
Branch
Coverage
Path
Coverage
T F
T F T F
1 2 3 4

15. Path coverage is not always optimal
15
Statement
Coverage
Branch
Coverage
Path
Coverage
Exponential increase in branches with added conditionals
End up creating extra test cases

16. Where to start with coverage
16
Find evident issues early and often
Don’t focus on hitting high coverage metrics for individual parts of you app
Test some of each part of you application

17. What to do once you get started?
17
Call at least one method in every file or class
Attain 80% to 90% branch coverage in each method
Invoke 8 out of 10 methods, ignoring branch coverage

18. TestComplete for automated functional
testing
18

19. AQTime for code coverage
Optimizes code for developers & testers
Supports multiple languages & frameworks
Integrates with IDEs and TestComplete

20. DEMO
20

21. QUESTIONS?
21