The Testing Vocabulary
- Errors, Defects, Failures
- White Box and Black Box Testing
- Classifying Tests
- The Agile Testing Quadrants
- Some Other Types of Testing
- Summary
Stephen Kochan and Patrick Wood provide tutorials on tools useful in writing shell programs. Tools covered include cut, paste, sed, grep, sort, tr, and uniq. They also present a detailed discussion of regular expressions used by many Unix commands, such as sed, grep, and ed.
This chapter is from the book
This chapter is from the book
This chapter is from the book
What do people mean when they say that software should be tested? What activities, performed when, and by whom do they refer to? The previous chapter described the objectives and styles of testing. This chapter will get more concrete and take on actual testing activities and the vocabulary of testing. Unfortunately, the language of testing is quite elusive and the terminology rather ambiguous at times. The use of terms and employment of techniques vary not only across different organizations, but chances are that as soon a new person enters your team, that person may attach a different meaning to some of the words that you use when you speak about testing and quality assurance.
This chapter is organized as a taxonomy of different types of testing and a dictionary of some terms frequently used by testers. As a developer, it’s crucial to be well familiar with the nuances of this vocabulary. There’s a high probability that it has affected the way your colleagues approach quality assurance, so you’d better know where the stuff in the walls comes from. This is especially true in organizations in which development and testing have been, or still are, disconnected.
In addition, knowing about various types of testing gives a developer a more solid understanding of the work needed to ensure correctness and other desirable properties of the software. Thus, it helps to decompose the mystical task of testing into very concrete activities, some of which are performed by developers, and some by team members with other specialties. Estimating testing activities gets easier and it becomes clear when the software is “good enough.”
Putting this material together was challenging, because getting just one precise definition of a certain type of test is hard and maybe not even meaningful. The important fact to be aware of is that there are variations and differences. As you read this chapter, please keep this in mind: what’s really important is that you agree on the terminology in your organization. Ideally, your team decides on how its testing is conducted and how it uses the vocabulary, after which it documents the results so that they’re visible to everybody, like on a poster in the team’s room. In a not so ideal world, an architect or test manager makes these decisions and writes them down in a document (where they’ll likely never be found and read).
Errors, Defects, Failures
All developers sometimes make mistakes. These are known as errors in the language of testing. Errors lead to defects in the software. A more frequently used term for defect is bug,1 named for the insect that got trapped in the bowels of prehistoric hardware. Defects/bugs may lead to software failures. Not all of them do, though. A defect in code that’s never executed won’t cause a failure. Conversely, environmental conditions, like moisture, overheating, magnetic fields, or other events, may do so. So can incorrect or unintended use or abuse of the software.