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.

Career and team evaluation?

interesting like Glassdoor, but more recruitment-oriented: 

https://www.siliconrepublic.com/start-ups/tabspace-re-engineered-hiring-process-software-engineers

Quoting:
"“Since developers are data-driven people, aggregated values are presented in a structured way, using graphs and charts, and provide insight into a team’s values very quickly. Different developers prioritise different things. For example, some might emphasise working with high-quality equipment while others might care the most about team collaboration. That is where Tabspace comes in; you can quickly find out which teams share your professional and personal values and then you can go ahead and interview for those. As for the teams, Tabspace helps them to attract developers that share their team’s values and are a good fit for the team.

“Our goal is to help both sides; developers will be happier having found the teams that share their values, while teams will be more productive having developers that are happier at their workplace.”"

SW Construction: Which programming languages you should learn now...

... in order to improve your chances/value in the market. An interesting list of languages to learn additionally if you're from the Java, C/C++, Ruby, etc. world and/or if you're a newbie:

• Which programming languages you should learn now | InfoWorld

And the top 50 (in the not much scientific TIOBE index):

• https://www.tiobe.com/tiobe-index/

PS: Cross-check with a previously provided list here around:

• http://silvaonsoftware.blogspot.pt/2017/12/sw-construction-languages-to-know-in.html

SW Construction: Rust, the new safe, performant language (from Mozilla)?

https://www.infoworld.com/article/3218074/application-development/what-is-rust-safe-fast-and-easy-software-development.html

Quoting:
"Rust is meant to be fast, safe, and reasonably easy to program in. It’s also intended to be used widely, and not simply end up as a curiosity or an also-ran in the language sweepstakes. Good reasons abound for creating a language where safety sits on equal footing with speed and development power. After all, there’s a tremendous amount of software—some of it driving critical infrastructure—built with languages where safety wasn’t the first concern."
(...)
"The Rust team is conscious of many of these issues, and it has plans on the 2017 Rust roadmap to improve them. For example, to make Rust easier to work with C and C++, the Rust team is investigating whether to expand projects like bindgen, which automatically generates Rust bindings to C code."

SW Construction: Building taking into account perfomance?

Maybe so. Because of hardware security flaws and its workarounds:
http://www.idgconnect.com/blog-abstract/29406/why-spectre-demands-elegantly-coded-software

Citando:
"Why Spectre demands more elegantly coded software

Write it well, write it efficiently, write it as though the underlying hardware isn’t going to get any faster. Because it isn’t"

(...)

"There are some Spectre-immune systems, but they tend to be slow or old or both. The Raspberry Pi is one and I’m writing this article on another, a pre-2013 Intel Atom box. It doesn’t do out-of-order (OoO) execution, but therefore it doesn’t do anything particularly quickly. This is now the choice facing everyone who cares about security: fast and flawed or slow and safe (or at least safer).

Until that changes, until a new generation of chips somehow circumvents the flaws and gives us full-speed computing without speculative execution vulnerabilities, software developers must step up and make a difference. Yes, efficient coding is suddenly back in fashion, because developers can no longer assume that tomorrow’s hardware will be faster than today’s. But what does this mean in development terms?"

REUSE: The Elements of Reusable Code (Chris Wash)

An excellent (oldie but goldie) article summing up the elements of reusable code:
The Elements of Reusable Code

More from Chris Wash:
https://www.captechconsulting.com/search#q=Chris Wash

FUN Dept.: Quality Sayings and Quality Quotes

Not properly the typical Fun Dept. but a whole bunch of interesting quotes related to QUALITY can be found here:

• Quality Sayings and Quality Quotes | Wise Old Sayings

... and that does not include the famous quote by the quality guru W. Edwards Deming:
"It is not enough to do your best; you must know what to do, and then do your best." 

In SW engineering, this is where processes enter. QMS Processes do tell you what to do. Then you need to know how to do (and the tools). And then you need attitude and do your best. And only then you are ready to not waste your efforts out of the window.

Source: http://quotes.deming.org/authors/W._Edwards_Deming/quote/10084