Specify Testability Requirements

The purpose of testability requirements is to tell a software engi- neer during subsequent development activities, which classes have to be designed and implemented with testability in mind and which level of testability must be achieved thereby.

Testability requirements as a concept can be found e.g. in the context of the OPEN process [Fire01]. This section adds some new guidelines on how to define them.

Testability Requirements by Customers and Developers Testability requirements improve the efficiency of testability improvement efforts during subsequent development activities by focusing them on the most relevant parts of the system. Testability requirements can belong to the customer require- ments and/or the technical requirements:

• Testability requirements belong to the customer require- ments if they are specified by the customer. For example, a purchaser of a telecommunication equipment may have spe- cific demands concerning the ability to diagnose system fail- ures. In this case, the testability requirements are specified during the requirements capture activity.

• If testability requirements are specified by the software developer, then they belong to the technical requirements which are specified during the analysis activity.

Scope and Scale

Scope Testability requirements should be specified at least for hard-to- test classes and test-sensitive classes, either on a global level, package level, or for each relevant class on an individual level. Scale We propose to use a simple scale to specify the required level of

testability, for example a scale with the following values: do not care, low, medium, and high.

58 Chapter 6: Analysis

Testability Requirements and Necessary Trade-offs

During the specification of testability requirements it is neces- sary to consider the costs of testability and possible conflicts with other software quality characteristics like performance requirements.

For example, while the effect of testability on performance is usually limited, performance-tuning has a more severe impact on testability (see Appendix D). If testability is in conflict with performance, it is a good strategy to give testability require- ments the higher priority during earlier stages of design and implementation and to improve performance afterwards.

Clearly, it is only meaningful to specify testability requirements, if the savings earned at least outweigh their costs. While the costs for achieving testability only have to be invested once, the sav- ings are multiplied by the (usually large) number of unit tests, maintenance tests, and debugging activities.

59

Chapter 7

Design

The design model contains more classes and dependencies than the analysis class model as the result of accounting for non-functional requirements and managing complexity. Addi- tionally, the direction of dependencies and the mechanisms used to realize the dependencies is specified during design. This chapter introduces different categories of design depen- dencies with different effects on testing and provides a number of design guidelines and hints on techniques which help to con- trol dependencies during the design activity.

7.1

Introduction

Like in the previous chapters, we start with an overview of the design activity, describe important design concepts, and discuss briefly how testability relates to the design activity.

7.1.1

Overview of Design Activity

Design activity The analysis specification and those parts of the requirements specification which are not covered by it are the starting point for the design activity. All functional and non-functional require- ments are transformed during the design into classes with well- defined responsibilities. Breaking the system into classes enables to manage complexity. The functionality and interaction of the classes is specified at a level of granularity which allows to implement them directly using a programming language. Care has to be taken, that the technical and quality requirements specified on an architectural level are correctly refined during design.

Design specification The result of the design activity is the design specification which describes the responsibilities, relationships, and interactions of the classes constituting the system.

60 Chapter 7: Design

Design class model The main component of the design specification is the design

class model which contains more details than the analysis class

model. Interaction diagrams and state diagrams supplement the design class model to facilitate its direct implementation. The implementation itself is not part of the design activity. [Six03]

7.1.2

Important Concepts

Classes The basic building blocks of an object-oriented design are

classes.

Interfaces Interfaces are treated within this document as a special type of classes without any method implementations and instance attributes.

Concrete class For the sake of simplicity, we often use the term class to denote both classes and interfaces. If a class needs to be distinguished from an interface, we call it a concrete class.

Final class A class can be declared final in Java which makes is impossible to derive a subclass from it.

Final method Java allows to declare a method final, which makes it impossible to redefine it within a subclass.

Final attribute If an attribute is declared final in Java, its value can not be changed after initialization.

Type A class can be used to define the type of attributes, parameters, or return values.

Between classes and types there is a m-to-n relationship: A given type can be realized by more than one class and a given class can realize more than one type. For example, a class can implement more than one interface, a subclass implements the type of its superclass(es).

Layered system architecture

We assume a layered system architecture including interface classes, control classes, and entity classes.

7.1.3

Design and Testability

Considering testability during the design activity is very impor- tant in order to achieve a testable system implementation. Not to care about testability during design usually can’t be compen- sated during subsequent development activities.

Chapter 7: Design 61

1 To transform the testability requirements defined in previous development activities into testable classes and testability features.

2 To define the responsibilities of the classes in a way that facilitates testing.

3 To define the interactions of the classes in a way that facili- tates testing.

In the remainder of this chapter we mainly focus on the third task: first we describe different categories of class dependencies and how the differ in their effect on testing, then we propose new guidelines on how to avoid untestable class dependencies.