Steps to become a better software tester - can do these over a period of time - Part 11

I have been writing a series of posts (How to become a better tester) on how a tester can acquire the skills needed to become a better tester. There are a number of such steps that a person can do, with some of them being very logical, and some that many testers would not have thought about. Many of these are easy to do, and others are more difficult to do, but all of them are something that testers can do. In this series, I will write more steps that a person can do in order to improve their skills:
- Get into the business of collecting metrics about your test process and its results. These metrics could include the number of test cases written vs. the amount of time taken, the amount of test cases written vs. the complexity of the requirements / code / design (using various measures such as Function Point Analysis or other such parameters). Additional metrics that can be collected including determination of the results of the testing, such as the number of bugs generated on a daily basis, the number of bugs that were accepted as valid bugs, the number of high criticality bugs, the number of bugs that were withdrawn, the number of bugs that were marked as duplicate. Viewing these metrics can help a tester determine the efficiency of their bug logging measures. It is one thing to feel that the bugs you log are important, and that developers are happy that you are testing their feature, but to get a good validation of how you are actually doing, you need to actually do the metrics for these. Ideally, compare your data with that of the other testers, and if you find that a greater number of your bugs are withdrawn as compared to other testers, or if you have a higher number of bugs that are of a lower priority, then you need to improve things. It is only when you find yourself generating these metrics that are among the best in your comparable group that you should feel that you are improving as a tester.
The thing to note about this metrics based analysis is that this is an ongoing thing, with improvements showing up over a period of time. Do not suddenly try to generate high severity bugs, since that may actually cause a reduction in your performance. Analyse what you are doing, how you are doing your testing, and then see the benefits that will happen.