chapter 2 - testing in sdlc
TRANSCRIPT
-
7/29/2019 Chapter 2 - Testing in SDLC
1/26
Satyam Computer Services Limited1
Chapter 2
Testing in SDLC
-
7/29/2019 Chapter 2 - Testing in SDLC
2/26
Satyam Computer Services Limited2
Objective
Testing in Different Development Lifecycles
The V concept of testing
Verification and Validation
Testing Levels/Stages Component Test Issues
Integration Testing
System and Acceptance Testing Maintenance and Regression Testing
Static Vs Dynamic testing
-
7/29/2019 Chapter 2 - Testing in SDLC
3/26
Satyam Computer Services Limited3
Process models
The following process models are used for
development of software.
Waterfall model
Modified waterfall model
V - Model
Prototype model
RAD Spiral model
Agile Model (newly followed)
-
7/29/2019 Chapter 2 - Testing in SDLC
4/26
Satyam Computer Services Limited4
Waterfall model
Testing in done after
development
Testing is last activity
before delivery
The waterfall model is a sequential software development model (a process for the creation of software) in which
development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis,
design, implementation, testing (validation), integration, and maintenance. The origin of the term "waterfall" is often cited
to be an article published in 1970 by W. W. Royce; ironically, Royce himself advocated an iterative approach to software
development and did not even use the term "waterfall". Royce originally described what is now known as the waterfall
model as an example of a method that he argued "is risky and invites failure".
-
7/29/2019 Chapter 2 - Testing in SDLC
5/26
Satyam Computer Services Limited5
Waterfall Strengths
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability
Good formanagement control (plan, staff, track)
Works well when quality is more important than
cost or schedule
-
7/29/2019 Chapter 2 - Testing in SDLC
6/26
Satyam Computer Services Limited6
Modified waterfall models
In response to the perceived problems with the "pure"
waterfall model, many modified waterfall models have
been introduced. These models may address some or
all of the criticisms of the "pure" waterfall model. Many
different models are covered by Steve McConnell in the
"lifecycle planning" chapter of his book Rapid
Development: Taming Wild Software Schedules.
Royce's final model
Royce's final model, his intended improvement upon his
initial "waterfall model", illustrated that feedback could
(should, and often would) lead from code testing to
design (as testing of code uncovered flaws in the
design) and from design back to requirementsspecification (as design problems may necessitate the
removal of conflicting or otherwise unsatisfiable /
undesignable requirements).
-
7/29/2019 Chapter 2 - Testing in SDLC
7/26 Satyam Computer Services Limited7
Waterfall Deficiencies
All requirements must be known upfront Deliverables created for each phase are
considered frozeninhibits flexibility
Can give a false impression of progress
Does not reflect problem-solving nature ofsoftware development iterations of phases
Integration is one big bang at the end
Little opportunity for customerto preview thesystem (until it may be too late)
-
7/29/2019 Chapter 2 - Testing in SDLC
8/26 Satyam Computer Services Limited8
Modified waterfall models
The "sashimi" model
The name "Sashimi" comes from a Japanese
hardware development model (from Fuji-Xerox) and
refers to the Japanese style of presenting
overlapping slices of raw fish.
It is sometimes simply referred to as the "waterfall
model with overlapping phases" or "the waterfall
model with feedback".
For example, since the design and implementation
phases will overlap in the sashimi model,
implementation problems may be discovered during
the "design and implementation" phase of thedevelopment process. This helps alleviate many of
the problems associated with the Big Design Up
Front philosophy of the waterfall model.
-
7/29/2019 Chapter 2 - Testing in SDLC
9/26 Satyam Computer Services Limited9
Modified waterfall models
The "sashimi" model
The name "Sashimi" comes from a Japanese
hardware development model (from Fuji-Xerox) and
refers to the Japanese style of presenting
overlapping slices of raw fish.
It is sometimes simply referred to as the "waterfall
model with overlapping phases" or "the waterfall
model with feedback".
For example, since the design and implementation
phases will overlap in the sashimi model,
implementation problems may be discovered during
the "design and implementation" phase of thedevelopment process. This helps alleviate many of
the problems associated with the Big Design Up
Front philosophy of the waterfall model.
-
7/29/2019 Chapter 2 - Testing in SDLC
10/26 Satyam Computer Services Limited10
V model
A variant of the Waterfall
that emphasizes the
verification and validation
of the product.
Testing of the product is
planned in parallel with a
corresponding phase of
development
-
7/29/2019 Chapter 2 - Testing in SDLC
11/26 Satyam Computer Services Limited
11
V-Model Strengths
Emphasize planning forverification and
validationof the product in early stages of
product development
Each deliverable must be testable
Project management can track progress
by milestones
Easy to use
-
7/29/2019 Chapter 2 - Testing in SDLC
12/26 Satyam Computer Services Limited
12
V-Model Weaknesses
Does not easily handleconcurrent events
Does not handle iterationsor phases
Does not easily handle dynamic changesin requirements
Does not contain risk analysis activities
-
7/29/2019 Chapter 2 - Testing in SDLC
13/26 Satyam Computer Services Limited
13
Prototyping Model
A preliminary project plan is developed
An partial high-level paper model is created
The model is source for a partial requirementsspecification
A prototype is built with basic and critical attributes The designer builds
the database
user interface
algorithmic functions
The designerdemonstrates the prototype, the userevaluates for problems and suggests improvements.
This loop continues until the user is satisfied
-
7/29/2019 Chapter 2 - Testing in SDLC
14/26 Satyam Computer Services Limited
14
Rapid Application Model (RAD)
Requirements planning phase (a workshoputilizing structured discussion of businessproblems)
User description phase automated toolscapture information from users
Construction phase productivity tools, such ascode generators, screen generators, etc. inside
a time-box. (Do until done) Cutover phase -- installation of the system, user
acceptance testing and user training
-
7/29/2019 Chapter 2 - Testing in SDLC
15/26 Satyam Computer Services Limited
15
RAD Strengths
Reduced cycle time and improved productivitywith fewer people means lower costs
Time-boxapproach mitigates cost and schedulerisk
Customer involved throughout the completecycle minimizes risk of not achieving customersatisfaction and business needs
Focus moves from documentation to code
(WYSIWYG). Uses modeling concepts to capture information
about business, data, and processes.
-
7/29/2019 Chapter 2 - Testing in SDLC
16/26
Satyam Computer Services Limited16
RAD Weaknesses
Accelerated development processmust givequick responsesto the user
Risk ofnever achieving closure
Hard to use with legacy systems Requires a system that can be modularized
Developers and customers must be committedto rapid-fire activitiesin an abbreviated time
frame.
-
7/29/2019 Chapter 2 - Testing in SDLC
17/26
Satyam Computer Services Limited17
Spiral SDLC Model
Adds risk analysis,and 4gl RAD
prototyping to the
waterfall model
Each cycle involvesthe same sequence of
steps as the waterfall
process model
-
7/29/2019 Chapter 2 - Testing in SDLC
18/26
Satyam Computer Services Limited18
Agile SDLCs
Speed up or bypass one or more life cycle
phases
Usually less formal and reduced scope
Used for time-critical applications
Used in organizations that employ
disciplined methods
-
7/29/2019 Chapter 2 - Testing in SDLC
19/26
Satyam Computer Services Limited19
Some Agile Methods
Adaptive Software Development (ASD)
Feature Driven Development (FDD)
Crystal Clear
Dynamic Software Development Method(DSDM)
Rapid Application Development (RAD)
Scrum
Extreme Programming (XP)
Rational Unify Process (RUP)
-
7/29/2019 Chapter 2 - Testing in SDLC
20/26
Satyam Computer Services Limited20
Verification
Verification ensures that the system
(software, hardware, documentation, and
personnel) complies with an organizations
standards and processes, relying onreview or non-executable methods
Did we built the right system ?
-
7/29/2019 Chapter 2 - Testing in SDLC
21/26
Satyam Computer Services Limited21
Verification
-
7/29/2019 Chapter 2 - Testing in SDLC
22/26
Satyam Computer Services Limited22
Validation
Validation physically ensures that the
system operates according to plan by
executing the system functions through a
series of tests that can be observed andevaluated.
Did we build the system right?
-
7/29/2019 Chapter 2 - Testing in SDLC
23/26
Satyam Computer Services Limited23
Validation
-
7/29/2019 Chapter 2 - Testing in SDLC
24/26
Satyam Computer Services Limited24
Testing levels
Unit
Integration
System Acceptance
Regression
-
7/29/2019 Chapter 2 - Testing in SDLC
25/26
Satyam Computer Services Limited25
Static testing Vs Dynamic testing
Static testing is performed using the
software documentation. The code is not
executing during static testing.
Dynamic testing requires the code to be in
an executable state to perform the tests.
-
7/29/2019 Chapter 2 - Testing in SDLC
26/26
S t C t S i Li it d26
Points to remember
Waterfall model does not all modification after
reaching to its next phase
Prototyping is an iterative model
Regression testing is also called as selective re-testing
All the reviews are called as Verification
Unit, integration, system, acceptance testing arethe various levels of testing