Entering a world with a common language

Entering a world with a common language

Whenever a group of people gathers to discuss the pre-release phase of a piece of software, the word test appears on the agenda. While the general idea of testing seems more or less clear to everybody, only rarely do two people have the same implicit understanding of the details. To name a few, try to discuss the following terms with your colleagues from the same or another project:

  • Acceptance test
  • Integration test
  • System test
  • Component test

Image via CC BY-SA 2.0 from Dave Heuts

Once you have done this, you have an idea why the world is in utter need of a common test language. The problem is a lack of definitions but rather the big variety of similar or competing definitions on the one hand, and as a result the missing motivation in looking up any of them on the other hand.

The ISTQB is a not-for-profit organization that works on advancing the software testing profession. It managed to define a glossary on terms needed in software testing that was authored and thus accepted by a large number of professionals from many different countries. The glossary is in the version 2.2 at the date of writing this with the latest update in October 2012. The knowledge of it’s existence is not wide spread which is a pity because this is a quite useful reference document.

To give some examples, this glossary defines integration testing as “Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems.” By itself this does not have too much meaning, and rightfully so, since this term is used so vaguely in the industry. But the glossary goes on to also list integration testing in the small (“see component integration testing”) and integration testing in the large (“see system integration testing“), and now people can speak meaningful to each other again.

To me a minor surprise was the equality of component and unit. According to the glossary a unit test is a component test and vice versa. In both cases it applies to the “Minimal software item that can be tested in isolation”. I suspect that projects that work with different abstraction layers of components (such as Class and Bundle) need a more detailed definition. But such differentiation can not be covered by such a general document.
A quite useful definition is given for functional testing as “Testing based on an analysis of the specification […]” and references to black box testing.

This glossary it worth some glances and to be kept close. In the next discussion about the details in testing, bring it along and spread the word. The industry will be able to move faster with a common understanding of testing terms.

Do you know other testing glossaries that might compete with this one that lists 57 authors from 15 countries?