Chapter 12

 Pattern-Based Design
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 1
Design Patterns
 Each of us has encountered a design
problem and silently thought: I wonder if
anyone has developed a solution to for this?
 What if there was a standard way of describing a
problem (so you could look it up), and an
organized method for representing the solution
to the problem?
 Design patterns are a codified method for
describing problems and their solution
allows the software engineering community
to capture design knowledge in a way that
enables it to be reused.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 2
Design Patterns
 Each pattern describes a problem that
occurs over and over again in our
environment and then describes the core
of the solution to that problem in such a
way that you can use the solution a
million times over without ever doing it
the same way twice.
• Christopher Alexander, 1977
 “a three-part rule which expresses a
relation between a certain context, a
problem, and a solution.”
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 3
Basic Concepts
 Context allows the reader to understand
the environment in which the problem
resides and what solution might be
appropriate within that environment.
 A set of requirements, including
limitations and constraints, acts as a
system of forces that influences how
 the problem can be interpreted within its
context and
 how the solution can be effectively applied.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 4
Effective Patterns
 Coplien [Cop05] characterizes an effective design
pattern in the following way:
 It solves a problem: Patterns capture solutions, not just abstract
principles or strategies.
 It is a proven concept: Patterns capture solutions with a track
record, not theories or speculation.
 The solution isn't obvious: Many problem-solving techniques (such
as software design paradigms or methods) try to derive solutions
from first principles. The best patterns generate a solution to a
problem indirectly--a necessary approach for the most difficult
problems of design.
 It describes a relationship: Patterns don't just describe modules, but
describe deeper system structures and mechanisms.
 The pattern has a significant human component (minimize human
intervention). All software serves human comfort or quality of life;
the best patterns explicitly appeal to aesthetics and utility.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 5
Generative Patterns
 Generative patterns describe an
important and repeatable aspect of a
system and then provide us with a way
to build that aspect within a system of
forces that are unique to a given context.
 A collection of generative design
patterns could be used to “generate” an
application or computer-based system
whose architecture enables it to adapt to
change.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 6
Kinds of Patterns
 Architectural patterns describe broad-based design problems
that are solved using a structural approach.
 Data patterns describe recurring data-oriented problems and
the data modeling solutions that can be used to solve them.
 Component patterns (also referred to as design patterns)
address problems associated with the development of
subsystems and components, the manner in which they
communicate with one another, and their placement within a
larger architecture
 Interface design patterns describe common user interface
problems and their solution with a system of forces that
includes the specific characteristics of end-users.
 WebApp patterns address a problem set that is encountered
when building WebApps and often incorporates many of the
other patterns categories just mentioned.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 7
Kinds of Patterns
 Creational patterns focus on the “creation, composition,
and representation of objects, e.g.,
 Abstract factory pattern: centralize decision of what factory to instantiate
 Factory method pattern: centralize creation of an object of a specific type
choosing one of several implementations
 Structural patterns focus on problems and solutions
associated with how classes and objects are organized and
integrated to build a larger structure, e.g.,
 Adapter pattern: 'adapts' one interface for a class into one that a client expects
 Aggregate pattern: a version of the Composite pattern with methods for
aggregation of children
 Behavioral patterns address problems associated with the
assignment of responsibility between objects and the manner
in which communication is effected between objects, e.g.,
 Chain of responsibility pattern: Command objects are handled or passed on to
other objects by logic-containing processing objects
 Command pattern: Command objects encapsulate an action and its parameters

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 8
Frameworks
 Patterns themselves may not be sufficient to
develop a complete design.
 In some cases it may be necessary to provide an
implementation-specific skeletal infrastructure,
called a framework, for design work.
 That is, you can select a “reusable mini-architecture that
provides the generic structure and behavior for a family of
software abstractions, along with a context … which specifies
their collaboration and use within a given domain.” [Amb98]
 A framework is not an architectural pattern, but
rather a skeleton with a collection of “plug
points” (also called hooks and slots) that enable
it to be adapted to a specific problem domain.
 The plug points enable you to integrate problem
specific classes or functionality within the skeleton.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 9
Describing a Pattern
 Pattern name—describes the essence of the pattern in a short but
expressive name
 Problem—describes the problem that the pattern addresses
 Motivation—provides an example of the problem
 Context—describes the environment in which the problem resides
including application domain
 Forces—lists the system of forces that affect the manner in which the
problem must be solved; includes a discussion of limitation and constraints
that must be considered
 Solution—provides a detailed description of the solution proposed for the
problem
 Intent—describes the pattern and what it does
 Collaborations—describes how other patterns contribute to the solution
 Consequences—describes the potential trade-offs that must be
considered when the pattern is implemented and the consequences of
using the pattern
 Implementation—identifies special issues that should be considered
when implementing the pattern
 Known uses—provides examples of actual uses of the design pattern in
real applications
 Related patterns—cross-references related design patterns

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 10
Pattern Languages
 A pattern language encompasses a collection of
patterns
 each described using a standardized template
(Section 12.1.3) and
 interrelated to show how these patterns collaborate
to solve problems across an application domain.
 a pattern language is analogous to a hypertext
instruction manual for problem solving in a
specific application domain.
 The problem domain under consideration is first
described hierarchically, beginning with broad
design problems associated with the domain and
then refining each of the broad problems into lower
levels of abstraction.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 11
Pattern-Based Design
 A software designer begins with a
requirements model (either explicit or
implied) that presents an abstract
representation of the system.
 The requirements model describes the
problem set, establishes the context, and
identifies the system of forces that hold
sway.
 Then …

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 12
Pattern-Based Design

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 13
Thinking in Patterns
 Shalloway and Trott [Sha05] suggest the following
approach that enables a designer to think in
patterns:
 1. Be sure you understand the big picture—the
context in which the software to be built resides. The
requirements model should communicate this to you.
 2. Examining the big picture, extract the patterns
that are present at that level of abstraction.
 3. Begin your design with ‘big picture’ patterns that
establish a context or skeleton for further design work.
 4. “Work inward from the context” [Sha05] looking
for patterns at lower levels of abstraction that
contribute to the design solution.
 5. Repeat steps 1 to 4 until the complete design is
fleshed out.
 6. Refine the design by adapting each pattern to the
specifics of the software you’re trying to build.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 14
Design Tasks—I
 Examine the requirements model and develop a
problem hierarchy.
 Determine if a reliable pattern language has
been developed for the problem domain.
 Beginning with a broad problem, determine
whether one or more architectural patterns are
available for it.
 Using the collaborations provided for the
architectural pattern, examine subsystem or
component level problems and search for
appropriate patterns to address them.
 Repeat steps 2 through 5 until all broad
problems have been addressed.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 15
Design Tasks—II
 If user interface design problems have been
isolated (this is almost always the case),
search the many user interface design
pattern repositories for appropriate
patterns.
 Regardless of its level of abstraction, if a
pattern language and/or patterns repository
or individual pattern shows promise,
compare the problem to be solved against
the existing pattern(s) presented.
 Be certain to refine the design as it is
derived from patterns using design quality
criteria as a guide.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 16
Pattern Organizing Table

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 17
Common Design Mistakes
 Not enough time has been spent to understand
the underlying problem, its context and forces,
and as a consequence, you select a pattern that
looks right, but is inappropriate for the solution
required.
 Once the wrong pattern is selected, you refuse to
see your error and force fit the pattern.
 In other cases, the problem has forces that are
not considered by the pattern you’ve chosen,
resulting in a poor or erroneous fit.
 Sometimes a pattern is applied too literally and
the required adaptations for your problem space
are not implemented.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 18
Chapter 16
 Software Quality Assurance
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 19
Comment on Quality
 Phil Crosby once said:
 The problem of quality management is not what
people don't know about it. The problem is what
they think they do know . . .
 Everybody is for it. (Under certain conditions, of
course.)
 Everyone feels they understand it. (Even though
they wouldn't want to explain it.)
 Everyone thinks execution is only a matter of
following natural inclinations. (After all, we do get
along somehow.)
 And, of course, most people feel that problems in
these areas are caused by other people. (If only
they would take the time to do things right.)
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 20
Elements of SQA
 Standards
 Reviews and Audits
 Testing
 Error/defect collection and analysis
 Change management
 Education
 Vendor management
 Security management
 Safety
 Risk management

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 21
Role of the SQA Group-I
 Prepares an SQA plan for a project.
 The plan identifies
• evaluations to be performed
• audits and reviews to be performed
• standards that are applicable to the project
• procedures for error reporting and tracking
• documents to be produced by the SQA group
• amount of feedback provided to the software project team
 Participates in the development of the project’s software
process description.
 The SQA group reviews the process description for compliance
with organizational policy, internal software standards, externally
imposed standards (e.g., ISO-9001), and other parts of the
software project plan.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 22
Role of the SQA Group-II
 Reviews software engineering activities to verify
compliance with the defined software process.
 identifies, documents, and tracks deviations from the process and
verifies that corrections have been made.
 Audits designated software work products to verify
compliance with those defined as part of the software
process.
 reviews selected work products; identifies, documents, and tracks
deviations; verifies that corrections have been made
 periodically reports the results of its work to the project manager.
 Ensures that deviations in software work and work
products are documented and handled according to a
documented procedure.
 Records any noncompliance and reports to senior
management.
 Noncompliance items are tracked until they are resolved.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 23
SQA Goals (see Figure 16.1)
 Requirements quality. The correctness,
completeness, and consistency of the requirements
model will have a strong influence on the quality of
all work products that follow.
 Design quality. Every element of the design model
should be assessed by the software team to ensure
that it exhibits high quality and that the design
itself conforms to requirements.
 Code quality. Source code and related work
products (e.g., other descriptive information) must
conform to local coding standards and exhibit
characteristics that will facilitate maintainability.
 Quality control effectiveness. A software team
should apply limited resources in a way that has the
highest likelihood of achieving a high quality result.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 24
Statistical SQA
Product Collect information on all defects
Find the causes of the defects
& Process Move to provide fixes for the process

measurement

... an understanding of how

to improve quality ...

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 25
Statistical SQA
 Information about software errors and defects is
collected and categorized.
 An attempt is made to trace each error and defect
to its underlying cause (e.g., non-conformance to
specifications, design error, violation of standards,
poor communication with the customer).
 Using the Pareto principle (80 percent of the
defects can be traced to 20 percent of all possible
causes), isolate the 20 percent (the vital few).
 Once the vital few causes have been identified,
move to correct the problems that have caused the
errors and defects.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 26
Six-Sigma for Software Engineering
 The term “six sigma” is derived from six standard deviations—
3.4 instances (defects) per million occurrences—implying an
extremely high quality standard.
 The Six Sigma methodology defines three core steps:
 Define customer requirements and deliverables and project goals
via well-defined methods of customer communication
 Measure the existing process and its output to determine current
quality performance (collect defect metrics)
 Analyze defect metrics and determine the vital few causes.
 Improve the process by eliminating the root causes of defects.
 Control the process to ensure that future work does not
reintroduce the causes of defects.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 27
Software Reliability
 A simple measure of reliability is mean-time-
between-failure (MTBF), where
MTBF = MTTF + MTTR
 The acronyms MTTF and MTTR are mean-
time-to-failure and mean-time-to-repair,
respectively.
 Software availability is the probability that a
program is operating according to requirements
at a given point in time and is defined as
Availability = [MTTF/(MTTF + MTTR)] x 100%

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 28
Software Safety
 Software safety is a software quality assurance
activity that focuses on the identification and
assessment of potential hazards that may
affect software negatively and cause an entire
system to fail.
 If hazards can be identified early in the
software process, software design features can
be specified that will either eliminate or control
potential hazards.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 29
ISO 9001:2000 Standard
 ISO 9001:2000 is the quality assurance standard that
applies to software engineering.
 The standard contains 20 requirements that must be
present for an effective quality assurance system.
 The requirements delineated by ISO 9001:2000 address
topics such as
 management responsibility, quality system, contract
review, design control, document and data control, product
identification and traceability, process control, inspection
and testing, corrective and preventive action, control of
quality records, internal quality audits, training, servicing,
and statistical techniques.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 30
Chapter 17
 Software Testing Strategies
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 31
Software Testing

Testing is the process of exercising

a program with the specific intent of
finding errors prior to delivery to the
end user.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 32
What Testing Shows
errors
requirements conformance

performance

an indication
of quality

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 33
Strategic Approach
 To perform effective testing, you should conduct
effective technical reviews. By doing this, many
errors will be eliminated before testing commences.
 Testing begins at the component level and works
"outward" toward the integration of the entire
computer-based system.
 Different testing techniques are appropriate for
different software engineering approaches and at
different points in time.
 Testing is conducted by the developer of the
software and (for large projects) an independent
test group.
 Testing and debugging are different activities, but
debugging must be accommodated in any testing
strategy.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 34
V&V
 Verification refers to the set of tasks that
ensure that software correctly implements
a specific function.
 Validation refers to a different set of tasks
that ensure that the software that has been
built is traceable to customer
requirements. Boehm [Boe81] states this
another way:
 Verification: "Are we building the product
right?"
 Validation: "Are we building the right product?"

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 35
Who Tests the Software?

developer independent tester

Understands the system Must learn about the system,
but, will test "gently" but, will attempt to break it
and, is driven by "delivery" and, is driven by quality

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 36
 Testing Strategy
System engineering

Analysis modeling
Design modeling

Code generation Unit test

Integration test
Validation test

System test

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 37
 Testing Strategy
 We begin by ‘testing-in-the-small’ and move
toward ‘testing-in-the-large’
 For conventional software
 The module (component) is our initial focus
 Integration of modules follows
 For OO software
 our focus when “testing in the small” changes from
an individual module (the conventional view) to an
OO class that encompasses attributes and
operations and implies communication and
collaboration

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 38
 Strategic Issues
 Specify product requirements in a quantifiable manner
long before testing commences.
 State testing objectives explicitly.
 Understand the users of the software and develop a
profile for each user category.
 Develop a testing plan that emphasizes “rapid cycle
testing.”
 Build “robust” software that is designed to test itself
 Use effective technical reviews as a filter prior to testing
 Conduct technical reviews to assess the test strategy
and test cases themselves.
 Develop a continuous improvement approach for the
testing process.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 39
Unit Testing

module
to be
tested

results

software
engineer
test cases

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 40
 Unit Testing
module
to be
tested
interface
local data structures
boundary conditions
independent paths
error handling paths

test cases
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 41
 Unit Test Environment
driver
interface
local data structures

Module boundary conditions

independent paths
error handling paths

stub stub

test cases

RESULTS
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 42
 Integration Testing Strategies

• Top down testing

• Bottom-up testing

• Sandwich testing

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 43
 Top Down Integration
A
top module is tested with
stubs

B F G

stubs are replaced one at

a time, "depth first"
C
as new modules are integrated,
some subset of tests is re-run
D E

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 44
Bottom-Up Integration
A

B F G

drivers are replaced one at a

time, "depth first"
C

worker modules are grouped into

builds and integrated
D E

cluster
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 45
 Sandwich Testing
A
Top modules are
tested with stubs

B F G

Worker modules are grouped into

builds and integrated
D E

cluster
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 46
Regression Testing
 Regression testing is the re-execution of some
subset of tests that have already been conducted
to ensure that changes have not propagated
unintended side effects
 Whenever software is corrected, some aspect of
the software configuration (the program, its
documentation, or the data that support it) is
changed.
 Regression testing helps to ensure that changes
(due to testing or for other reasons) do not
introduce unintended behavior or additional
errors.
 Regression testing may be conducted manually,
by re-executing a subset of all test cases or using
automated capture/playback tools.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 47
Smoke Testing
 A common approach for creating “daily builds” for product
software
 Smoke testing steps:
 Software components that have been translated into code are
integrated into a “build.”
• A build includes all data files, libraries, reusable modules, and engineered
components that are required to implement one or more product
functions.
 A series of tests is designed to expose errors that will keep the build
from properly performing its function.
• The intent should be to uncover “show stopper” errors that have the
highest likelihood of throwing the software project behind schedule.
 The build is integrated with other builds and the entire product (in its
current form) is smoke tested daily.
• The integration approach may be top down or bottom up.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 48
Object-Oriented Testing
 begins by evaluating the correctness and
consistency of the analysis and design models
 testing strategy changes
 the concept of the ‘unit’ broadens due to
encapsulation
 integration focuses on classes and their execution
across a ‘thread’ or in the context of a usage
scenario
 validation uses conventional black box methods
 test case design draws on conventional
methods, but also encompasses special
features

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 49
 Testing the CRC Model
1. Revisit the CRC model and the object-relationship
model.
2. Inspect the description of each CRC index 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
reasonable source.
4. Using the inverted connections examined in step 3,
determine whether other classes might be required or
whether responsibilities are properly grouped among the
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
through each evolution of the analysis model.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 50
OO Testing Strategy
 class testing is the equivalent of unit testing
 operations within the class are tested
 the state behavior of the class is examined
 integration applied three different strategies
 thread-based testing—integrates the set of
classes required to respond to one input or event
 use-based testing—integrates the set of classes
required to respond to one use case
 cluster testing—integrates the set of classes
required to demonstrate one collaboration

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 51
 High Order Testing
 Validation testing
 Focus is on software requirements
 System testing
 Focus is on system integration
 Alpha/Beta testing
 Focus is on customer usage
 Recovery testing
 forces the software to fail in a variety of ways and verifies that recovery is
properly performed
 Security testing
 verifies that protection mechanisms built into a system will, in fact, protect it
from improper penetration
 Stress testing
 executes a system in a manner that demands resources in abnormal quantity,
frequency, or volume
 Performance Testing
 test the run-time performance of software within the context of an integrated
system

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 52
Debugging: A Diagnostic Process

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 53
The Debugging Process

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 54
 Debugging Effort
time required
to diagnose the
symptom and
time required determine the
to correct the error cause
and conduct
regression tests

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 55
 Symptoms & Causes
symptom and cause may be
geographically separated

symptom may disappear when

another problem is fixed

cause may be due to a

combination of non-errors

cause may be due to a system

or compiler error

symptom cause may be due to

assumptions that everyone
cause believes

symptom may be intermittent

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 56
Consequences of Bugs
infectious
damage

catastrophic
extreme
serious
disturbing

annoying
mild

Bug Type

Bug Categories: function-related bugs,

system-related bugs, data bugs, coding bugs,
design bugs, documentation bugs, standards
violations, etc.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 57
Correcting the Error
 Is the cause of the bug reproduced in another part of the
program? In many situations, a program defect is caused
by an erroneous pattern of logic that may be reproduced
elsewhere.
 What "next bug" might be introduced by the fix I'm about
to make? Before the correction is made, the source code
(or, better, the design) should be evaluated to assess
coupling of logic and data structures.
 What could we have done to prevent this bug in the first
place? This question is the first step toward establishing
a statistical software quality assurance approach. If you
correct the process as well as the product, the bug will
be removed from the current program and may be
eliminated from all future programs.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 58
Final Thoughts
 Think -- before you act to correct
 Use tools to gain additional insight
 If you’re at an impasse, get help from someone
else
 Once you correct the bug, use regression
testing to uncover any side effects

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 59