Metrics gives the depth of Application quality; they give you self-assurance in the product. You may think about these product management indicators, which can be either quantitative or qualitative. They are typically the providers of the visibility you need.
Metrics usually fall in to a few categories:
-Project management (which includes process efficiency)
People are often confused about what metrics they ought to be using. You may use different metrics for different purposes. For example, you may have a set of metrics that you use to assess the output of your check team. One such metric may be the project management measure of the number of bugs found. Others may be an efficiency measure of the number of check cases written, or the number of tests executed in a given period of time. The aim is to select metrics that will help you understand the state of your product. Ultimately, when you think about the value of a metric, you need to ask if it provides visibility in to the application product's quality. Metrics are only useful if they help you to make sound business decisions in a timely manner. If the relevancy or integrity of a metric cannot be justified, don't use it. Think about, for example, how management analysis & control makes use of financial reports such as profit/loss, money flow, ratios, job costing, etc. These reports help you navigate your business in a timely manner. Engineering metrics are analogous, providing information to help perform analyses & control the development process. However, your engineers may not be the right people to give you the metrics you need to help in making business decisions, because they are not trained financial analysts. As an executive, you need to select what metrics you require & tell your staff to provide them.
For example, coverage metrics are essential for your team. Coverage is the measure of some amount of testing. You could have requirements coverage metrics, platform coverage metrics, path coverage metrics, scenario coverage metrics, or even check plan coverage metrics, to name a few. Cem Kaner lists over 100 types of coverage measures in his paper "Negligence & Testing Coverage." Before the project starts, it is important to come to agreement on how you will measure check coverage. Obviously, the more coverage of a sure type, the less risk associated with that type. The aim is to select metrics that will help you understand the state of your product. Wisely select a handful of these metrics specific to your type of project & use them to give you visibility in to how close the product is to release. The check group needs to be providing you lots of useful information with these metrics