Software Testing and Quality Assurance: The Testing Perspective

1
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-0
  216-cooltools.html

2
Outline

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

3
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.

4
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 programs 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).

5
Testing perspective

• Skeptical
• Wants proof of quality.
• Objective
• Makes no assumptions.
• Thorough
• Doesnt miss important areas.
• Systematic
• Searches are reproducible.

6
Object-Oriented concepts

• Object
• Message
• Interface
• Class
• Inheritance
• Polymorphism

7
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.

8
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.

9
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

10
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

11
Object-Oriented concepts interface example
(cont)

• public interface Movable
• public Point getPosition()
• public void move()

12
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.

13
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 objects lifetime.

14
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)

15
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.

16
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

17
Object-Oriented concepts class class
specification (cont...)

• Pre and Postcondition - Summary

Client (i.e. caller) Supplier (i.e. method)
Obligation Must ensure precondition (i.e. correct input parameter) Must ensure postcondition (i.e. method works correctly)
Benefit Need not ensure postcondition (i.e. special values or exceptions) Need not ensure precondition(i.e. validity of input parameters), although it needs to check it before it runs.
18
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.
19
Object-Oriented concepts class class
specification (cont...)

• Design by contract example
• The same example using iContract syntax

20
Object-Oriented concepts class class
specification (cont...)

• Invariant example

class StackG private int count boolean
isEmpty() other things
invariant isEmpty() (count 0) end
21
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.

22
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.

23
Object-Oriented concepts class class
specification (cont...)

• Defensive programming example

sqrt (x, epsilon REAL) REAL is -- Square root
of x, precision epsilon require x gt
0 epsilon gt 0 do if x lt 0 then Do
something about it (?) else Normal square
root computation end ensure abs (Result 2
x) lt 2 epsilon Result end
24
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.
25
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).

26
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.

27
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.

28
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.

29
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).

30
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

31
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.

32
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.

33
Object-Oriented concepts polymorphism

• Polymorphism is the ability to treat an object as
  belonging to more than one type.
• Testers care about
• Unanticipated interactions

34
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 objects
  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.

35
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.

36
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.

37
Development products

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

38
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

39
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.

40
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

41
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.

42
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.

43
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).