Software Testing and Quality Assurance: The Testing Perspective

Software Testing and Quality Assurance: The Testing Perspective • Reading Assignment: • John McGregor and David A. Sykes, A Practical Guide to Testing Object-Oriented Software, Addison-Wesley, 2001, ISBN: 0-201-325640. • Chapter 2 • http://www.javaworld.com/javaworld/jw-02-2001/jw-0216-cooltools.html

Outline • Testing perspective. • Object-Oriented concepts. • Overview of UML models.

Introduction: Testing perspective • Testing perspective: a way of looking at any development product and questioning its validity. • The person examining work products from this perspective utilizes a thorough investigation of the software and all its representations to identify faults. • It makes reviews and inspections just as powerful a tool as execution-based testing. • Requires that a piece of software demonstrate that it not only performs according to its specification, but also performs only to that specification.

Inspection, review, and test execution • Software testing is typically accomplished by: • Inspection: an examination of software based on checklist of typical problems, most items on the check list are based on programming language semantics and coding conventions (e.g. ensuring that each variable is initialized before its first use). • Review: an examination of software with the purpose of finding errors and faults even before the software is executed (uncover errors such as missed or misunderstood requirements or faults in a program’s logic). • Test execution: testing software in the context of a running program (test if the program has the required behavior by giving the program some input and verifying that the resulting output is correct).

Testing perspective • Skeptical • Wants proof of quality. • Objective • Makes no assumptions. • Thorough • Doesn’t miss important areas. • Systematic: • Searches are reproducible.

Object-Oriented concepts • Object • Message • Interface • Class • Inheritance • Polymorphism

Object-Oriented concepts: object • An object is an operational entity that encapsulates both specific data values and code that manipulates those values. • Objects are the direct target of the testing process during software development. • The life cycle for an object begins when it is created, proceeds through a series of status, and ends when the object is destroyed.

Object-Oriented concepts: object (cont...) • An object encapsulates and hides information. • An object has a state that persists for the life of the object. • An object has a lifetime. • Testers care about: • Whether the object behaves according to its specification. • Whether it interacts appropriately with collaborating objects in an executing program.

Object-Oriented concepts: message • A message is a request that an operation be performed by some object. • A message has a sender (originating a message). • A message has a receiver (receiving the message). • A message may include actual parameters. • Some messages result in some form of reply such as: return value and exception. • Testers care about: • Senders • Receivers • Parameters

Object-Oriented concepts: interface • An interface is an aggregation of behavioral declarations. • An interface is a building block for specifications. • In Java: interface • In C++: abstract class with public, pure virtual methods. • An interface encapsulates operation specifications. • An interface has relationships with other interfaces and classes. • Testers care about • Relationships with other interfaces

Object-Oriented concepts: interface example (cont…) public interface Movable { public Point getPosition(); public void move(); }

Object-Oriented concepts: class • A class is a set of objects that share a common conceptual bases (a template for creating objects). • Objects form the basic element for executing OO programs while classes form the basic elements for defining OO programs. • Instantiation: the process of creating an object. • Instance (object): the result of instantiation. • The conceptual basis common to all the objects in a class is expressed in terms: • A class specification: what each object can do (C++ header file). • A class implementation: how each object carries out what it can do.

Object-Oriented concepts: class —class specification • Describes what the class represents and what an instance of the class can do. • An operation is an action that can be applied to an object to obtain a certain effect: • Accessor (or inspector) operations: provide information about an object. • Modifier (mutator) operations: change the state of an object by setting one or more attributes to have new values. • Other types of operations: • A constructor is a class object operation used to create a new object including the initialization of the new instance when it comes into existence. • A destructor is an instance object operation used to perform any processing needed just prior to the end of an object’s lifetime.

Object-Oriented concepts: class —class specification (cont...) • Semantics can be specified at several different points: • Preconditions: conditions that must hold before the operation is performed. • Postconditions: conditions that must hold after the operation is performed. • Invariants: conditions that must always hold within the life time of the object. • Testers care about • Preconditions • Postconditions • Invariants • Relation to other classes (interactions)

Object-Oriented concepts: class —class specification (cont...) • To write specifications for an operation, two basic approaches can be used to define the interface between the receiver and the sender: • Design by contract approach. • Defensive programming approach. • Each approach has a set of rules about how to define the constraints and the responsibilities for the sender and receiver when an operation to be performed.

Object-Oriented concepts: class —class specification (cont...) • Design by contract: • A contract is between the sender and the receiver of a message. • The sender is responsible for ensuring that the preconditions are met. • The receiver is responsible for ensuring that the postconditions are met and maintaining class invariants. • Testers care about how this contract is enforced. • Language support: • (Eiffel) by Meyer • iContract

Object-Oriented concepts: class —class specification (cont...) • Pre and Postcondition - Summary

contract Class B m(x); pre: p post: q Class A Object-Oriented concepts: class —class specification (cont...) p binds the client A.It is an obligation for A but a benefit for B. q binds the supplier B. It is an obligation for B but a benefit for A. Class B says to its clients: “If you promise to call m with p satisfied, then I, in return, promise to deliver a final state in which q is satisfied.”

double sqrt (double x) require x >= 0 do … ensure result * result == x end //** return Square root of x @pre x >= 0 @post return * return == x */ double sqrt (double x) { … } Object-Oriented concepts: class —class specification (cont...) • Design by contract example: • The same example using iContract syntax:

Object-Oriented concepts: class —class specification (cont...) • Invariant example: class Stack[G] private int count; boolean isEmpty() { … } … other things … invariant isEmpty() == (count == 0) end

Object-Oriented concepts: class —class specification (cont...) • Defensive programming • An operation returns some indication concerning the status of the result of the request (success or failure) in terms of return code. • The receiver can provide the sender an object that encapsulates the status of the request. • Exceptions are used frequently. • The goal is to identify “garbage in” and hence eliminate “garbage out”. • A member function checks for the improper values coming in and then report that status of the request to the sender.

Object-Oriented concepts: class —class specification (cont...) • Defensive programming • This approach increases the complexity of the software. • Each sender must follow a request for an operation with code to check the processing status and then; for each possible outcome, provide code to take an appropriate recovery action. • Testers care about how the receiver ensures pre and postconditions.

Object-Oriented concepts: class —class specification (cont...) Defensive programming example: sqrt (x, epsilon: REAL): REAL is -- Square root of `x’, precision `epsilon’ require x >= 0 epsilon >= 0 do if x < 0 then … Do something about it (?) … else … Normal square root computation … end ensure abs (Result ^ 2 – x) <= 2 * epsilon * Result end

Object-Oriented concepts: class —class specification (cont...) • Defensive programming example using assert: void test( int *p ) { assert( p != 0 ); if (p == 0) return; // use p. }

Object-Oriented concepts: class —class specification (cont...) • Contract vs. defensive programming: • The contract approach simplifies class testing, but complicates interaction testing because we must ensure any sender meets preconditions. • The defensive programming approach complicates both class testing (test cases must address all possible outcomes) and interaction testing (we must ensure all possible outcomes are produced and that they are properly handled by a sender).

Object-Oriented concepts: class —class implementation • Class implementation describes how an object represents its attributes and carries out operations. • It compromises several components: • A set of data values stored in data members (instance variables or variables). • A set of methods (member functions in C++ or methods in Java) constitutes code that will be used to implement an algorithm that accomplishes one operation declared in the public or private class specification. • A set of constructors to initialize a new instance. • A destructor that handles any processing associated with the destruction on an instance. • A set of primitive operations in a private interface.

Object-Oriented concepts: class —class implementation (cont...) • From testing perspective, potential causes of failures within class design and implementation: • A class specification contains operations to construct instances. These operations may not properly initialize the attributes of the new instances. • A class relies on collaboration with other classes to define its behaviors and attributes. These other classes may be implemented incorrectly. • A class’ implementation “satisfies” its specification, but that is no guarantee that the specification is correct. • The implementation might not support all required operations or may incorrectly perform operations. • A class specifies preconditions to each operation. The class may not provide a way for the precondition to be checked by a sender before sending a message.

Object-Oriented concepts: class —class implementation (cont...) • The design approach used gives rise to different sets of potential problems: • In contract approach we only need to test situations in which the precordinations are satisfied. • In defensive programming approach we must test every possible input to determine that the outcome is handled properly.

Object-Oriented concepts: inheritance • Inheritance is a relationship between classes that allows the definition of a new class based on the definition of an existing class. • Inheritance is “is-a” (or “is a kind of”) relationship. • Preexisting class does not have to be modified or made aware in any way of the new class. • The new class is referred to as a subclass or derived class (in C++). • If a class inherits from another class, the other class is referred to as a super class or base class (in C++).

Object-Oriented concepts: inheritance (cont...) • The set of classes that inherit either directly or indirectly from a given class form an inheritance hierarchy. • Testers care about • Propagation of errors • Potential for test reuse

Object-Oriented concepts: inheritance (cont...) • From testing perspective: • Provides a mechanism by which bugs can be propagated from a class to its descendents. Testing a class as it is developed eliminates faults early before they are passed on to the other classes. • Provides a mechanism by which we can reuse test cases (reuse test cases for the super class in testing the subclass because the subclass inherits from the super class). • Models an “is a kind of” relationship. Proper use of inheritance in design leads to benefits in execution testing of classes.

Object-Oriented concepts: inheritance (cont...) • Substitution principle: • If D is a subclass of C, then if an instance of C performs acceptably in a context, you can replace that instance of C with an instance of D and it will perform acceptably in that context.

Object-Oriented concepts: polymorphism • Polymorphism is the ability to treat an object as belonging to more than one type. • Testers care about: • Unanticipated interactions

Object-Oriented concepts: polymorphism (cont...) • Inclusion polymorphism: Inclusion polymorphism is the occurrence of different forms in the same class (dynamic binding) -substitute an object whose specification matches another object’s specification for the later object in a request for an operation: • In C++: • Inclusion polymorphism arises from the inheritance relationship. A derived class inherits the public interface of its base class and thus instances of the derived class can respond to the same message as the base class. • In Java: • Inclusion polymorphism is supported both through inheritance between classes and an implementation relationship between interfaces and classes.

A polymorphic reference is a reference variable that can refer to different types of objects at different points in time. Object-Oriented concepts: polymorphism (cont...) • Inclusion polymorphism from testing perspective: • Inclusion polymorphism allows systems to be extended incrementally by adding classes rather than modifying existing ones. • Inclusion polymorphism allows any operation to have one or more parameters of a polymorphic reference. This increases the number of possible kinds of actual parameters that should be tested.

Object-Oriented concepts: polymorphism (cont...) • Parametric polymorphism is the capability to define a type in terms of one or more parameters (e.g. templates in C++) • From testing perspective: • Parametric polymorphism supports a different type of relationship from inheritance. If the template works for one instantiation, there is no guarantee it will work for another.

Development products • Unified Modelling Language • Developed by Grady Booch, James Rumbaugh, and Ivar Jacobson • Combined Booch's O-O design, Rumbaugh's OMT, and Jacobson’s OOSE • A notation for modelling

Development products: analysis models • Two levels of analysis domain: • Domain analysis: focuses on an understanding of the problem domain-that is, the general area of interest in which the problem of immediate interest lies. • Application analysis: focuses on specific problem and the requirements for a solution. • Analysis models: use case, class, state, sequence, and activity diagrams

UML diagrams • Use case diagram: represents the actors and uses of the system and relationships between the uses. • Class diagram: represents the individual class definitions and the relationships between classes. • Package diagram: presents conceptual groupings of classes with dependencies between groups. • Sequence diagrams: records the sequence of messages that represent an algorithm. • State diagram: presents different configurations of data-attribute values and the messages that transform the data from one configuration to another. • Activity diagram: aggregates all possible paths through the logic of a method.

Development products: design models • A design model represents how the software meets requirements. • From a testing perspective, we can reuse and extend use cases developed for analysis models. • Design models: class, state, and sequence diagrams

Development products: source code • Source code and source code documentation are the final representation of the software. • Major issues: • Who tests: testing can be done by developers who adopt a testing perspective. • What to test: each class can be tested separately before it is used as part of the system. • When testing is done: testing can be done at any time during development. • How testing is done: function-based and specification-based. • How much testing is done: exhaustive testing of each software component and of a whole system is seldom practical or possible.

Key points • Testing perspective: a way of looking at any development product and questioning its validity. • Software testing is typically accomplished by: inspection, review, and test execution. • Testing perspective is: skeptical, objective, thorough, and systematic.

Key points (cont...) • Object-oriented concepts: • Object, message, interface, class (specification and implementation), inheritance, polymorphism • Overview of UML models. • Analysis models (use cases, class, state, sequence, activity) • Design models (class, state, sequence, source code).

Software Testing and Quality Assurance: The Testing Perspective