chapter 2 - testing in sdlc

7/29/2019 Chapter 2 - Testing in SDLC

1/26

Satyam Computer Services Limited1

Chapter 2

Testing in SDLC


2/26


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


3/26


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)


4/26


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


5/26


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


6/26


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




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.



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


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



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



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



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



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.


16/26


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.


17/26


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


18/26


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


19/26


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)


20/26


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 ?


21/26


Verification


22/26


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?


23/26


Validation


24/26


Testing levels

Unit

Integration

System Acceptance

Regression


25/26


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.


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

chapter 2 - testing in sdlc

Documents