Category: quality

Goal/Question/Metric (GQM)

Goal/Question/Metric (GQM) is an established and elaborated method for measurement in software engineering. I have been using it, and doing evaluation research and method development on it since the 1990-ies. It can be useful in particular for the following purposes:

  • Systematically define measurement and reporting in software projects
  • Consolidate existing “ad hoc” measurement
  • Gain information needed for proces improvement and agile retrospectives

There have been reported many applications of GQM. Unfortunately, some involve misinterpretions of the method. For this reason, I propose in this article a few references and hints that can provide you with guidance and examples on how to apply GQM effectively.

GQM includes a data structure, the so-called GQM tree, that helps identifying and interpreting metrics for a given measurement goal. Specific types of questions clarify certain aspects of the measurement goal. Another data structure, the GQM Abstraction Sheet, facilitates handling of goal, questions and metrics.

Whenever I need metrics or reporting information about a piece of software or a software project, I find it highly useful to follow the GQM method in a pragmatic manner, to clarify what information exactly is required, how it can be obtained, and what needs to be considered when interpreting the data. Important GQM principles that provide guidance are:

  • Use the GQM goal template to clarify what shall be found out, and to what target group the information shall be directed.
  • Use only one or very few levels of Questions in order to keep the GQM tree concise.
  • Use exactly one level of metrics. If metrics tend to become complex, ensure that their definitions are clear and precise.
  • Focus on defining appropriate graphical representations of metrics information.
  • Be aware that the metrics data is only the raw material of measurement. Most important is the interactive data interpretation together with the GQM goal’s target group. This collaborative data interpretation is guided by the previously defined GQM questions.

The following literature gives a good overview of GQM. The article by van Latum et al. illustrates practical GQM application. The book by van Solingen and Berghout gives rich additional practical advice. The articles by Basili, Caldiera, and Rombach can be regarded the original source of GQM, although the method goes back to earlier work by Basili and Weiss from the 1980-ies.

Frank van Latum, Rini van Solingen, Markku Oivo, Barbara Hoisl, Dieter Rombach, Günther Ruhe. Adopting GQM-Based Measurement in an Industrial Environment. IEEE Software, pp. 78-86, January/February, 1998. (http://www.computer.org/portal/web/csdl/doi/10.1109/52.646887)

Rini van Solingen, Egon Berghout. The Goal/Question/Metric Method. McGraw-Hill Education, 1999. (http://www.iteva.rug.nl/gqm/GQM%20Guide%20non%20printable.pdf)

Victor R. Basili, Gianluigi Caldiera and H. D. Rombach. The Goal Question Metric Approach. In Encyclopedia of Software Engineering (John J. Marciniak, Ed.), John Wiley & Sons, Inc., 1994, Vol. 1, pp.528–532.

V. R. Basili, G. Caldiera, and H. Dieter Rombach. The Goal Question Metric Approach. NASA GSFC Software Engineering Laboratory, 1994. (ftp://ftp.cs.umd.edu/pub/sel/papers/gqm.pdf)

Two Essential Stages of Testing

Good test coverage is important and sometimes not easy to achieve. A simple principle can lay a solid foundation for test coverage: Distinguishing two essential stages of testing.

The initial low-level stage tests basic development artifacts immediately or soon after they have become available. This is usually called component, module or unit testing.

The later high-level stage tests the entire system or its higher-level aggregates as early as possible and lasting until very close before product delivery. This is usually called acceptance test.

The concepts of low-level and high-level tests are not new. Important is to relate them to different phases of the development cycle (or to activities within agile iterations, likewise; levels become stages) and to systematically plan associated activities. This way, good test coverage  can be achieved very efficiently.

Low-level testing stage High-level testing stage
Tests cover implementation of each basic development artifact from an implementation point of view (white or grey box testing) Tests cover design of the entire system or major system part from a business or usage point of view (black box testing)
Test cases defined by developers; derived from requirements and design Test cases defined by testers, domain experts from the software team, and/or customers; derived from explicit requirements or tacit domain knowledge
Tests conducted by developers Tests conducted by testers and/or customers or users
Defects usually fixed immediately or otherwise entered into defect database Defects usually entered into defect database, fixed, and being re-tested

I have seen many projects in trouble, because they did not properly address these test stages. Sometimes, low-level testing was replaced by pure faith (“My programs always run well”). Sometimes, high-level testing was shallow and ineffective (“We don’t have any time for more tests”). Often, the relation between both stages was not managed well, lowering product quality and limiting the efficiency of testing.

Taking care that both stages of testing are being addressed is a first and important step towards improved testing. Both stages are complementing each other well, so that higher test coverage can be achieved without very little planning and qualification efforts. This is also a good basis for subsequent improvement activities.

Additional details on the concepts of low-level and high-level testing are described in the testing literature, although the relation between the levels and phases of the development lifecycle is often not explored very much. A very instructive book is TMap® Next by Koomen et al. (2006). Another elaboration on the two testing levels are Brian Marick’s agile testing quadrants. Lisa Crispin’s presentation on  agile test planning provides a detailed explanation of those quadrants. Finally, an inspiring reflection on testing is Robert L. Glass’s text on The Many Flavors of Testing.