Debark University
Department of cs
System Analysis & Design
COSC3092
Jan, 2020
03/12/2021 Shimels T. 1
Chapter 6 – Software Testing
• Introduction to Software Testing
• OO testing Activities
• Verification and Validation
• Object-oriented Testing Strategies
• Software Testing and the life cycle
03/12/2021 Shimels T. 2
Software Testing
• Software testing is defined as an activity to check whether
the actual results match the expected results and to ensure
that the software system is defect free.
• Testing is the process of evaluating a system or its
component(s) with the intent to find whether it satisfies the
specified requirements or not.
• Testing is executing a system in order to identify any gaps,
errors, or missing requirements
• “Testing is the process of executing a program with the
intention of finding errors.” – Myers
• “Testing can show the presence of bugs but never their
absence.” - Dijkstra
03/12/2021 Shimels T. 3
Error, Bug, Fault & Failure
• Error : It is a human action that produces the incorrect
result that produces a fault.
• Bug : The presence of error at the time of execution of
the software.
• Fault : State of software caused by an error.
• Failure : Deviation of the software from its expected
result. It is an event.
03/12/2021 Shimels T. 4
OO testing Activities
• Review OOA and OOD models
• Class testing after code is written
• Integration testing within subsystems
• Integration testing as subsystems are added to the
system
• Validation testing based on OOA use-cases
03/12/2021 Shimels T. 5
Correctness of OOA/OOA Models
• Syntactic correctness
– judged by making sure proper modeling
conventions and symbolism were used
• Semantic correctness
– Does the model reflect the real world problem?
03/12/2021 Shimels T. 6
Consistency of OOA/OOD Models
Consistency of OOA/OOD Models
• Assess the class-responsibility-collaborator (CRC) model and
object-relationship diagram
• Review system design
– examine the object-behavior model to check mapping of
system behavior to subsystems
– review concurrency and task allocation
– examine the use-case scenarios and exercise the user
interface design
• Test object model against the object relationship network to
ensure that all design object contain necessary attributes and
operations needed to implement the collaborations defined for
each CRC card
03/12/2021 Shimels T. 7
1. Revisit the CRC model and the object-relationship model
Class Model Assessment
2. Inspect the description of each CRC card to determine if a
delegated responsibility is part of the collaborator's
definition
3. Invert the connection to ensure that each collaborator that
is asked for service is receiving requests from a
responsible source
4. Using the inverted connections from step 3, determine
whether
– Other classes might be required
– Responsibilities are properly grouped among classes
5. Determine whether widely requested responsibilities might
be combined into a single responsibility
6. Steps 1 to 5 are applied iteratively to each class and during
OOA model evaluation Shimels T.
03/12/2021 8
Verification and Validation
Verification
• The software should confirm to its specification
• Are we building the product right?
Validation
• The software should do what the user really requires
• Are we building the right product?
• Apply:
– Black-box testing to create a deficiency list
– Acceptance tests through alpha (at developer’s site)
and beta (at customer’s site) testing with actual
customers
03/12/2021 Shimels T. 9
Testing Methodologies
Black box testing
• No knowledge of internal program design or code
required.
• Tests are based on requirements and functionality.
White box testing
• Knowledge of the internal program design and code
required.
• Tests are based on coverage of code statements,
branches, paths, conditions.
03/12/2021 Shimels T. 10
Object Oriented Programming Testing Concerns
• Classes may contain operations that are inherited from super
classes
• Subclasses may contain operations that were redefined rather than
inherited
• All classes derived from an previously tested base class need to
be thoroughly tested
Fault-Based Testing
• Best reserved for operations and the class level
• Uses the inheritance structure
• Tester examines the OOA model and hypothesizes a set of
plausible/reasonable defects that may be encountered in operation
calls and message connections and builds appropriate test cases
• Misses incorrect specification and errors in subsystem
interactions
03/12/2021 Shimels T. 11
Scenario-Based Testing
• Using the user tasks described in the use-cases and
building the test cases from the tasks and their variants
• Uncovers errors that occur when any actor interacts
with the Object Oriented software
• Concentrates on what the user does, not what the
product does
• You are better off spending more time on reviewing
the use-cases as they are created and less time on use-
case testing
03/12/2021 Shimels T. 12
Object-oriented Testing Strategies
03/12/2021 Shimels T. 13
Unit testing
• Smallest testable unit is the encapsulated class or
object.
• Tests each module individually.
• Approach:
– Test each method within a class
– Test the attributes of the class between methods
• Follows a white box testing (Logic of the program).
• Done by developers
03/12/2021 Shimels T. 14
Integration Testing
• Once all the modules have been unit tested, integration
testing is performed.
• It is systematic testing.
• Focuses on groups of classes that collaborate in some
manner
• Produce tests to identify errors associated with
interfacing.
Types:
• Big Bang Integration testing
• Top Down Integration testing
• Bottom Up Integration testing
03/12/2021 Shimels T. 15
System Testing
• The system as a whole is tested to uncover
requirement errors.
• Verifies that all system elements work properly and
that overall system function and performance has been
achieved.
Types:
• Alpha Testing
• Beta Testing
• Acceptance Testing
• Performance Testing
03/12/2021 Shimels T. 16
Cont….
Alpha Testing
• It is carried out by the test team within the developing
organization .
Beta Testing
• It is performed by a selected group of friendly customers.
Acceptance Testing
• It is performed by the customer to determine whether to
accept or reject the delivery of the system.
Performance Testing
• It is carried out to check whether the system meets the
nonfunctional requirements identified in the SRS
document.
03/12/2021 Shimels T. 17
Types of Performance Testing:
• Stress Testing
• Regression Testing
• Configuration Testing
• Compatibility Testing
• Recovery Testing
• Maintenance Testing
• Documentation Testing
• Usability Testing
03/12/2021 Shimels T. 18
Software Testing and the life cycle
• Requirements engineering
– criteria: completeness, consistency, feasibility, and testability.
– typical errors: missing, wrong, and extra information
– determine testing strategy
– generate functional test cases
– test specification, through reviews and the like
• Design
– functional and structural tests can be devised on the basis of the
decomposition
– the design itself can be tested (against the requirements)
– formal verification techniques
– the architecture can be evaluated
03/12/2021 Shimels T. 19
Testing and the life cycle (cont’d)
• Implementation
– check consistency implementation and previous
documents
– code-inspection and code-walkthrough
– all kinds of functional and structural test techniques
– extensive tool support
– formal verification techniques
• Maintenance
– regression testing: either retest all, or a more selective
retest
03/12/2021 Shimels T. 20
03/12/2021 Shimels T. 21
