Metrics:
- Those measurements from your test process that will help to determine where application stands and when it will be ready for release.
Measure progess:
- They are essential for measuring progress.
Code coverage:
- Measurement of what percentage of underlying application source code was executed during the test cycle.
- It does not tell you how much of the code passed the test, only how much was executed during the test.
Requirements coverage:
- measures the percentage of requirements that were tested.
- This does not mean requirements were met, only that they were tested.
- Requirements must be known and documented
- Tests are cross referenced to the requirements
Requirements satisfied:
- Measure percentage of requirements that were met - number that passed the test.
- Ultimately this is a more meaningful measurement, it tells you how close the application is to meeting its intended purpose.
Priority requirements:
- It is better to rate requirements by priority, or risk and then measure coverage at each level.
- For ex:
1) Requirement met to for system to be operational
2) System to be acceptable
3) Necessary but not critical
4) Those that are desirable
5) Those that are cosmetic
Exit criteria:
- Successful requirement coverage is useful exit criteria for test process.
Test case coverage:
- Measures how many test cases have been executed.
Predicting time to release
Defect ratio
Fix rate:
Recurrence ratio:
Post- release defects
Defect prevention;
Continuous improvement:
Management Reporting:
- Once management has invested time and money in test automation, they will also want to know what their return is.
- This would mean savings in time, money or improved quality.
Saving money:
- There are two kinds of savings from automated testing.
- First is productivity that comes from repeating manual tests.
- Divide automated time into manual test time.
Saving time:
- Getting the application into market or back into production faster also saves company time.
- If the reason for release is to correct errors, that extra time could translate into significant productivity.
Higher quality:
- Few companies know the cost to fix the error.
- Best way to tell if you are making progress is when post release defect rate declines.
Better coverage:
- Measure increasing number of test cases that are executed for each release.
- If we assume more tests means fever errors in production, this expanded coverage has value.
- Those measurements from your test process that will help to determine where application stands and when it will be ready for release.
Measure progess:
- They are essential for measuring progress.
Code coverage:
- Measurement of what percentage of underlying application source code was executed during the test cycle.
- It does not tell you how much of the code passed the test, only how much was executed during the test.
Requirements coverage:
- measures the percentage of requirements that were tested.
- This does not mean requirements were met, only that they were tested.
- Requirements must be known and documented
- Tests are cross referenced to the requirements
Requirements satisfied:
- Measure percentage of requirements that were met - number that passed the test.
- Ultimately this is a more meaningful measurement, it tells you how close the application is to meeting its intended purpose.
Priority requirements:
- It is better to rate requirements by priority, or risk and then measure coverage at each level.
- For ex:
1) Requirement met to for system to be operational
2) System to be acceptable
3) Necessary but not critical
4) Those that are desirable
5) Those that are cosmetic
Exit criteria:
- Successful requirement coverage is useful exit criteria for test process.
Test case coverage:
- Measures how many test cases have been executed.
Predicting time to release
Defect ratio
Fix rate:
Recurrence ratio:
Post- release defects
Defect prevention;
Continuous improvement:
Management Reporting:
- Once management has invested time and money in test automation, they will also want to know what their return is.
- This would mean savings in time, money or improved quality.
Saving money:
- There are two kinds of savings from automated testing.
- First is productivity that comes from repeating manual tests.
- Divide automated time into manual test time.
Saving time:
- Getting the application into market or back into production faster also saves company time.
- If the reason for release is to correct errors, that extra time could translate into significant productivity.
Higher quality:
- Few companies know the cost to fix the error.
- Best way to tell if you are making progress is when post release defect rate declines.
Better coverage:
- Measure increasing number of test cases that are executed for each release.
- If we assume more tests means fever errors in production, this expanded coverage has value.
No comments:
Post a Comment