Maintainability: A promising new metric to track maintainability

A promising new metric to track maintainability - JAXenter

Quoting:
"[A] new metric to track maintainability.

A good metric to measure software maintainability is the holy grail of software metrics. What we would like to achieve with such a metric is that its values more or less conform with the developer’s own judgment of the maintainability of their software system. If that would succeed we could track that metric in our nightly builds and use it as the canary in the coal mine. If values deteriorate it is time for refactoring. We could also use it to compare the health of all the software systems within an organization. And it could help to make decisions about whether it is cheaper to rewrite a piece of software from scratch instead of trying to refactor it.

A good starting point for achieving our goals is to look at metrics for coupling and cyclic dependencies. High coupling will definitely affect maintainability in a negative way. The same is true for big cyclic group of packages/namespaces or classes. Growing cyclic coupling is a good indicator for structural erosion. (...)"
(...)
"Try it yourself

Now you might wonder what this metric would say about the software you are working on. You can use our free tool Sonargraph-Explorer to compute the metric for your system written in Java, C# or Python. 

 is currently only considered for Java and C#. For systems written in C or C++ you would need our commercial tool Sonargraph-Architect."

SW Testing: 64 Essential Test Metrics For Measuring Software Quality, Testing & More

Should you measure things while testing? Sure. In order to be able to manage the phase (and the resources available to execute it) it is mandatory... What should you measure? Here is an interesting article on the topic:

• 64 Essential Test Metrics For Measuring Software Quality, Testing & More!

Quoting:

"Software testing metrics are a way to measure and monitor your test activities. More importantly, they give insights into your team’s test progress, productivity, and the quality of the system under test. When we ask ourselves “What have we tested?”, metrics will give us better answers than just “we have tested it.” Different teams measure various aspects depending on what they want to track and control or improve.

A metric usually conveys a result or a prediction based on the combination of data.

Result Metrics:  metrics that are mostly an absolute measure of an activity/process completed.

Example: Time taken to run a set of test cases in a suite

Predictive Metrics:  metrics that are derivatives and act as early warning signs of an unfavorable result.

Example: Defects created vs. Resolved chart shows the rate of defect fixing.  This grabs the team’s attention if this rate is slower than the rate desired.

Are you using the right software test metrics? Get answers, best practices and strategies in our 14-page guide to improving your software quality through data and analytics.

Why Test Metrics? Why Should You Care?

The aim of collecting test metrics is to use the data for improving the test process, rather than to just show fancy reports. This includes finding tangible answers to the questions:

• How long will it take to test?
• How much money will it take to test?
• How bad are the bugs?
• How many bugs found were fixed? reopened? closed? deferred?
• How many bugs did the test team did not find?
• How much of the software was tested?
• Will testing be done on time? Can the software be shipped on time?
• How good were the tests? Are we using low-value test cases?
• What is the cost of testing?
• Was the test effort adequate? Could we have fit more testing in this release?

Good answers to these questions need measurement. This post includes 64 of the absolute, derivative, result, and predictive metrics that testers and QA managers use the most often.

The Fundamental Metrics 

As a tester, your road to metric creation has to start somewhere.  Fundamental QA metrics are a combination of absolute numbers that can then be used to produce derivative metrics.

Absolute Numbers:

• Total number of test cases
• Number of test cases passed
• Number of test cases failed
• Number of test cases blocked
• Number of defects found
• Number of defects accepted
• Number of defects rejected
• Number of defects deferred
• Number of critical defects
• Number of planned test hours
• Number of actual test hours
• Number of bugs found after shipping"

For the derivative and other type of metrics, follow the link above.