Manual Testing document

8/18/2019 Manual Testing document

1/138

Manual Testing Testing Tools MindQ

Software

Computer software has become a driving force. It is the engine that drives businessdecision making. It serves as the basis for modern scientific investigation and engineering problem solving. It is a key factor that differentiates modern products and services. It is

embedded in systems of all kinds: Transportation, Medical, Telecommunications Military,

Industrial processes, Entertainment, ffice products,!, the list is almost endless.

"oftware is virtually inescapable in a modern world. #nd as we move into the twenty$first century, it will become the driver for new advances in everything from elementary

education to genetic engineering.

It affects nearly every aspect of our lives and has become pervasive in our commerce, our

culture, and our everyday activities.

Why Software has bugs?

"oftware have bugs because of% Mis$interpretation of re&uirements or no communication,

software comple'ity, programming errors, changing re&uirements, time pressure, egos of

people, poorly documented code, and software development tools used.

5 common problems in the Software Development Process

(. Poor requirement – if re&uirements are unclear, incomplete, too general, or not

testable, there will be problems

). Unrealistic schedule – If too much work is crammed in too little time, problems

are inevitable*. nadequate testing – no one will know whether or not the program is any good

until the customer complains or systems crash.+. !uturities – e&uests to pile on new features after development is underway,

e'tremely common.

-. "iscommunications – If developers dont know whats needed or customers

have erroneous e'pectations, problems are guaranteed.

5 #ommon Solutions to Software Development Problems$

(. "olid re&uirements). ealistic schedule

*. #de&uate Testing+. "tick to initial re&uirements as much as possible-. Communication

(


2/138


Software %ngineering$&

The application of a systematic, disciplined, &uantifiable approach to the development,

operation, and maintenance of software% that is, the application of engineering tosoftware.

Software 'uality$& /uality software is reasonably bug$free, delivered on time, within

budget, meets re&uirements, and is maintainable% 0owever, &uality is obviously a

sub1ective term. It will depend on who the 2customer is and their overall influence in the

scheme of things.

Software 'uality (ssurance )S'(*$ &Involves the entire "oftware development 3rocess

4 monitoring and improving the process, and making sure that any agreed$upon standardsand procedures are followed, and ensuring that problems are found and dealt with. It is

oriented to 2prevention of bugs.

Software 'uality #ontrol $& )'#*

It is a process in which actual testing of the software happens by following the process

defined by the /# team, it is mainly driven by the 56efect 6etection7Measuring and monitoring the &uality of s8w by conducting reviews after completion of

every development phase through review meetings.

+esting Definitions$

• Testing is the process of e'ecuting a program with the intent of finding errors

r

• 9erifying and validating the application with respect to customer re&uirements

r

inding the differences between customer e'pected and actual values

Testing should also ensure that a &uality product is delivered to the customer.

+ester ,esponsibilities$

• Identifying the most appropriate implementation approach for a given test

• Implementing individual tests.

• "etting up and e'ecuting the tests

• ;ogging outcomes and verifying test e'ecution• #naly


3/138


• easibility = #nalysis

• 6esign

• Coding• Testing

• elease = Maintenance

./ Software Development -ife #ycle )SD-#*

#ll of the stages from start to finish that take place when developing a new software

is known as "6;C.

• The "oftware ;ife Cycle is a description of the events that occur between the

birth and death of a software pro1ect inclusively.

• 6efines the concrete strategy to engineer "oftware artifacts

• "6;C is separated into phases >steps, stages?

• "6;C also determines the order of the phases, and the criteria for

transitioning from phase to phase

• !easibility Study and Problem (nalysis

& @hat e'actly is this system supposed to doA

6etermine and spell out the details of the problem.

• Design

& 0ow will the system solve the problemA

;ogical implementation of the s8w happens.

• #oding

&Translating the design into the actual system $ 3hysical construction of the s8w product

• +esting

&6oes the system completely solve the problemA

&0ave the re&uirements been satisfiedA

&6oes the system work properly in all situationsA

• "aintenance"mall Enhancements to the s8w happens and the

support is provided to solve the real time problems that

the system faces when the system goes live

*

easibility study

#nalysis

6esign

Coding

Testing

Installation =

Maintenance


4/138


!easibility Study$

The Feasibility Report

easibility report contains, #pplications areas to be considered eg stock control, purchasing, accounts etc

"ystem investigations for each application

Cost estimates

"ystem re&uirements

Timescale for implementation

E'pected benefits

System (nalysis$

"ystem analysis and design is the process of investigating a business with a view todetermining how best to manage the various procedures and information processing

tasks that it involves.

+

easibility "tudy

#nalysis

6esign

Coding

easibility "tudy

#nalysis

6esign

Coding

Testing

Installation =

Maintenance

The #nalyst conducts an initial

study of the problem and asks if

the solution is!Technologically

possibleA

Economically possibleA;egally possibleA

perationally possibleA


5/138


System (nalysis ,eport

System (nalysis ,eport consists of0

B" >Business e&uirement 6ocument?

" >unctional e&uirement 6ocument? or unctional specifications

se Cases >ser action and system esponse?

D These * are the base documents for writing Test Cases

6ocumenting the results

"ystems flow charts

6ata flow diagramsrgani


6/138


System Design ,eport

•

6esign 6ocument consists of #rchitectural 6esign, 6atabase 6esign, Interface6esign

#oding$

+esting

Testing is e'ecuting a program with an intent of finding Error 8 ault and ailure. ault is

a condition that causes the software to fail to perform its re&uired function. Error refers

to difference between #ctual utput and E'pected utput. ailure is the inability of asystem of a system or component to perform re&uired function according to its

specification. ailure is an event% fault is a state of the software, caused by an error.

F

easibility "tudy

#nalysis

6esign

Coding

Testing

Installation = Maintenance

3rogram development

6raft up user guides


7/138


Why Software +esting?

To discover defects.

To learn about the reliability of the software

To ensure that product works as user e'pected.

To avoid being sued by customers To detect defects early, which helps in

reducing the cost of defect fi'ing.

#ost of Defect ,epair

Phase 2 #ost

e&uirements G

6esign (G

Coding )G

Testing -G

Customer "ite (GG

H

easibility "tudy

#nalysis

6esign

Coding

Testing

Installation =

Maintenance


8/138


e&uire 6esign Coding Testing Customer "ite Cost G (G )G -G (GG

Installation = Maintenance:

Installation:

• ile conversion

• "ystem changeover

• Jew system becomes operational

K

easibilit "tud

#nal sis

6esi n

Codin

Testin

Installation =

Maintenance


9/138


• "taff training

Maintenance:• Corrective maintenance

• 3erfective maintenance

• #daptive maintenance

Software Development "odels

Water!all "odel

This model is same like as "6;C . This is a step by step model, after completion

of one phase then the ne't phase is implemented. #lso, known as ;inear "e&uentialModel or Classical Model.

Waterfall Strengths

L Easy to understand, easy to useL 3rovides structure to ine'perienced staff

L Milestones are well understood

L "ets re&uirements stabilityL ood for management control >plan, staff, track?

L @orks well when &uality is more important than cost or

schedule

Disadvantages

The waterfall model is the oldest and the most widely used paradigm.0owever, many pro1ects rarely follow its se&uential flow. This is due to the inherent

problems associated with its rigid format. Jamely:

N

(nalysis

Design

#oding

"aintenance

+esting


10/138


• It only incorporates iteration indirectly, thus changes may cause considerable

confusion as the pro1ect progresses.

•#s the client usually only has a vague idea of what is re&uired from the software product, @aterfall Model has difficulty accommodating the natural uncertainty

that e'ists at the beginning of the pro1ect.

• The customer only sees a working version of the product after it has been coded.

This may result in disaster if any undetected problems are precipitated to this

stage.

When to use the Waterfall "odel

L e&uirements are very well known

L 3roduct definition is stable

L Technology is understoodL Jew version of an e'isting product

L 3orting an e'isting product to a new platform.

Prototyping "odelL 6evelopers build a prototype during the re&uirements phaseL 3rototype is evaluated by end users

L sers give corrective feedback

L 6evelopers further refine the prototypeL @hen the user is satisfied, the prototype code is brought up to the standards needed for

a final product.

Prototyping Steps

L # preliminary pro1ect plan is developed

L #n partial high$level paper model is created

L The model is source for a partial re&uirements specificationL # prototype is built with basic and critical attributes

L The designer builds

4 the database 4 user interface

4 algorithmic functions

L The designer demonstrates the prototype, the user evaluates for problems and suggests

improvements.L This loop continues until the user is satisfied

(G


11/138


Prototyping Strengths

L Customers can 5see7 the system re&uirements as they are being gatheredL 6evelopers learn from customers

L # more accurate end productL ne'pected re&uirements accommodated

L #llows for fle'ible design and development

L "teady, visible signs of progress produced

L Interaction with the prototype stimulates awareness of additional needed functionality

Prototyping Wea3nesses

L Tendency to abandon structured program development for 5code$and$fi'7 developmentL Bad reputation for 5&uick$and$dirty7 methods

L verall maintainability may be overlooked

L The customer may want the prototype delivered.L 3rocess may continue forever >scope creep?

When to use Prototyping "odel

L e&uirements are unstable or have to be clarified

L #s the re&uirements clarification stage of a waterfall model

L 6evelop user interfaces

L "hort$lived demonstrationsL Jew, original development

L @ith the analysis and design portions of ob1ect$oriented development.

Prototype "odel

This model is suitable when the client is not clear about the re&uirements. This isa cyclic version of the linear model. In this model, once the re&uirement analysis is done

and the design for a prototype is made, the development process gets started. nce the

prototype is created, it is given to the customer for evaluation. The customer tests the

package and gives his8her feed back to the developer who refines the product accordingto the customerOs e'act e'pectation. #fter a finite number of iterations, the final software

package is given to the customer. In this methodology, the software is evolved as a result

of periodic shuttling of information between the customer and developer. This is the most popular development model in the contemporary IT industry. Most of the successful

software products have been developed using this model $ as it is very difficult >even for

a whi< kidP? to comprehend all the re&uirements of a customer in one shot. There aremany variations of this model skewed with respect to the pro1ect management styles of

the companies. Jew versions of a software product evolve as a result of prototyping.

((


12/138


,apid (pplication Development "odel

The #6 model is a linear se&uential software development process that emphasiwhen possible? or createreusable components >when necessary?. In all cases, automated tools are used to facilitate

construction of the software.

F. +esting and turnover"ince the #6 process emphasi


13/138


Spiral "odel or terative "odel or %volutionary "odel

It is the most generic of the models Most life cycle models can be derived as special

cases of the spiral model. The spiral uses a risk management approach to "8@

development some advantages of the spiral model are:

• 6efers elaboration of low risk "8@ elements

• Incorporates prototyping as a risk reduction strategy

• ives an early focus to reusable "8@

•

#ccommodates life$cycle evolution, growth, and re&uirement changes• Incorporates "8@ &uality ob1ectives into the product

• ocus on early error detection and design flaws

• "ets completion criteria for each pro1ect activity to answer the &uestion: 5how

much is enoughA

• ses identical approaches for development and maintenance.

• Can be used for 08@$"8@ system development

6raw backs: $ Even though there is no technical draw back the maintanance is very high

(*


14/138


8 "odel

9 model stands for 9erification = 9alidation model which has the above stages of

software development, left side is all development and involves more verification where

as right side involves more validation and little bit of verification. It is a suitable modelfor large scale companies to maintain testing process. This model defines co$e'istence

relation between development process and testing process.

There are different levels of testing involved in 9$model

• nit Testing

•

Integration Testing• "ystem Testing

• ser #cceptance Testing

#fter Completion of every development phase the corresponding testing activities should

be initiated.

Draw 4ac3s$&

The cost of Maintaining of independent testing team is very high.

(+

" stem e

" stem Testin


15/138


(gile SD-#9sL "peed up or bypass one or more life cycle phasesL sually less formal and reduced scopeL sed for time$critical applications

L sed in organi#"6?

L eature 6riven 6evelopment >66?

L Crystal Clear L 6ynamic "oftware 6evelopment Method >6"6M?

L apid #pplication 6evelopment >#6?L "crumL E'treme 3rogramming >S3?

L ational nify 3rocess >3?

%:treme Programming – ;P

or small$to$medium$si


16/138


+. "imple design 4 system is designed as simply as possible >e'tra comple'ity removed

as soon as found?

-. Testing 4 programmers continuously write unit tests% customers write tests for featuresF. efactoring 4 programmers continuously restructure the system without changing its

behavior to remove duplication and simplifyH. 3air$programming $$ all production code is written with two programmers at one

machine

K. Collective ownership 4 anyone can change any code anywhere in the system at any

time.N. Continuous integration 4 integrate and build the system many times a day 4 every time

a task is completed.

(G. +G$hour week 4 work no more than +G hours a week as a rule((. n$site customer 4 a user is on the team and available full$time to answer &uestions

(). Coding standards 4 programmers write all code in accordance with rules emphasi


17/138


• Initiali


18/138


arithmetic e'pression. If a condition is incorrect, then at least one component of the

condition is incorrect. Thus the type of errors that may occur is.

• Boolean opearator error

• Boolean variable error

• Boolean 3arenthesis error

• elational operator error

• #rithmetic e'pression error

"tructure ( Entry R ( E'it with certain Constraints, Conditions and ;oops.

(pproach $&

Basic Path Testing :

Cyclomatic Comple'ity and McCabe Method Structure Testing :

Condition Testing , 6ata low Testing and ;oop Testing

>rey 4o: +esting $&

rey Bo' Testing is a new term, which evolved due to the different behaviors of thesystem.This is 1ust a combination of both Black Bo' = @hite Bo' Testing.Tester should

have the knowledge of both the internals and e'ternals of the function.

Even though you probably dont have full knowledge of the internals of the product you

test, a test strategy based partly on internals is a powerful idea. @e call this rey Bo'Testing. The concept is simple: If you know something about how the product works onthe inside, you can test it better from the outside. This is not to be confused with @hite

Bo' Testing, which attempts to cover the internals of the product in detail. In ray Bo'

mode, you are testing from the outside of the product, 1ust as you do with Black Bo', but

your testing choices are informed by your knowledge of how the underlying componentsoperate and interact.

ray Bo' Testing is especially important with @eb and Internet applications, because the Internet is built around loosely integrated components that connect via

relatively well$defined interfaces. nless you understand the architecture of the Jet,

your testing will be skin deep

+he +est Development -ife #ycle )+D-#*

sually, Testing is considered as a part of the "ystem 6evelopment ;ife Cycle. @ith our

practical e'perience, we framed this Test 6evelopment ;ife Cycle.

(K


19/138


The diagram does not depict where and when you write your Test 3lan and "trategy

documents. But, it is understood that before you begin your testing activities these

documents should be ready. Ideally, when the 3ro1ect 3lan and 3ro1ect "trategy are beingmade, this is the time when the Test 3lan and Test "trategy documents are also made.

+esting at %ach Stage of Development

(N

Requirement Study

Software RequirementSpecification

Requirement Checklist

Software RequirementSpecification

Functional SpecificationChecklist

Functional SpecificationDocument


Architecture Design

Architecture Design Detailed Design Document

Coding


Performance Criteria

Performance Test Casesand Scenarios

Software RequirementSpecificationRegression Test CaseDocument

Performance Test Casesand Scenarios

User Acceptance Test CaseDocumentsScenarios

Coding


Unit Test Case Documents

Design Document


Unit Test Case Document

System Test CaseDocument

!ntegration Test CaseDocument

Unit!ntegrationSystem

Test Case Documents

Regression Test Case

Document


20/138


8erification$&9erification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that

phase.

mportance of the 8erification Phase$&

9erification process helps in detecting defects early, and preventing their leakage

downstream. Thus, the higher cost of later detection and rework is eliminated.

,eviews$&

# process or meeting during which a work product, or set of work products, is presentedto pro1ect personnel, managers, users, customers, or other interested parties for comment

or approval.

The main goal of reviews is to find defects. eviews are a good compliment to testing to

help assure &uality. # few purposes of "/# reviews can be as follows:

• #ssure the &uality of deliverable before the pro1ect moves to the ne't stage.

• nce a deliverable has been reviewed, revised as re&uired, and approved, it can be

used as a basis for the ne't stage in the life cycle.

+ypes of reviews$&

Types of reviews include Management eviews, Technical eviews, Inspections,

@alkthroughs and #udits.

"anagement ,eviews$&

)G


21/138


Management reviews are performed by those directly responsible for the system in order

to monitor progress, determine status of plans and schedules, confirm re&uirements andtheir system allocation.

Therefore the main ob1ectives of Management eviews can be categori


22/138


In technical reviews, the following "oftware products are reviewed

• "oftware re&uirements specification

•"oftware design description

• "oftware test documentation

• "oftware user documentation

• Installation procedure

• elease notes

The participants of the review play the roles of 6ecision$maker, eview leader, ecorder,

Technical staff.

,equirement ,eview$&

# process or meeting during which the re&uirements for a system, hardware item, or software item are presented to pro1ect personnel, managers, users, customers, or other

interested parties for comment or approval. Types include system re&uirements review,

software re&uirements review.

@ho is involved in e&uirement eviewA

• 3roduct management leads e&uirement eview. Members from every affected

department participate in the review which includes functional consultants from

customer end.

nput #riteria

"oftware re&uirement specification is the essential document for the review. #

checklist can be used for the review.

%:it #riteria

E'it criteria include the filled = completed checklist with the reviewers

comments = suggestions and the re$verification whether they are incorporated in thedocuments.

Design ,eview$&# process or meeting during which a system, hardware, or software design is presented to

pro1ect personnel, managers, users, customers, or other interested parties for comment or

approval. Types include critical design review, preliminary design review, and systemdesign review.

))


23/138


@ho involves in 6esign eviewA

• /# team member leads design review. Members from development team and /#

team participate in the review.

nput #riteria$&

6esign document is the essential document for the review. # checklist can be used

for the review.

%:it #riteria$&


comments = suggestions and the re$verification whether they are incorporated in thedocuments.

#ode ,eview$&# meeting at which software code is presented to pro1ect personnel, managers, users,

customers, or other interested parties for comment or approval.

@ho is involved in Code eviewA

• /# team member >In case the /# Team is only involved in Black Bo' Testing, then

the 6evelopment team lead chairs the review team? leads code review. Members from

development team and /# team participate in the review.

nput #riteria$&

The Coding "tandards 6ocument and the "ource file are the essential documentsfor the review. # checklist can be used for the review.

%:it #riteria$&


comments = suggestions and the re$verification whether they are incorporated in the

documents.

Wal3throughs$&

# static analysis techni&ue in which a designer or programmer leads members of the

development team and other interested parties through a segment of documentation or

code, and the participants ask &uestions and make comments about possible errors,violation of development standards, and other problems.

The ob1ectives of @alkthrough can be summari


24/138


• Ensure >re?established standards are followed:

• Train and e'change technical information among pro1ect teams, which participate in

the walkthrough.• Increase the &uality of the pro1ect, thereby improving morale of the team members.

The participants in @alkthroughs assume one or more of the following roles:a? @alk$through leader

b? ecorder

c? #uthor d? Team member

To consider a review as a systematic walk$through, a team of at least two members shall

be assembled. oles may be shared among the team members. The walk$through leader

or the author may serve as the recorder. The walk$through leader may be the author.Individuals holding management positions over any member of the walk$through team

shall not participate in the walk$through.

Input to the walk$through shall include the following:

a? # statement of ob1ectives for the walk$through b? The software product being e'amined

c? "tandards that are in effect for the ac&uisition, supply, development, operation, and8or

maintenance of the software product

Input to the walk$through may also include the following:d? #ny regulations, standards, guidelines, plans, and procedures against which the

software product is to be inspectede? #nomaly categories

The walk$through shall be considered complete when

a? The entire software product has been e'amined b? ecommendations and re&uired actions have been recorded

c? The walk$through output has been completed

nspection$&

# static analysis techni&ue that relies on visual e'amination of development products to

detect errors, violations of development standards, and other problems. Types includecode inspection% design inspection, #rchitectural inspections, Test ware inspections etc.

The participants in Inspections assume one or more of the following roles:

a? Inspection leader

)+


25/138


b? ecorder

c? eader

d? #uthor e? Inspector

#ll participants in the review are inspectors. The author shall not act as inspection leader

and should not act as reader or recorder. ther roles may be shared among the team

members. Individual participants may act in more than one role.

Individuals holding management positions over any member of the inspection team shallnot participate in the inspection.

Input to the inspection shall include the following:a? # statement of ob1ectives for the inspection

b? The software product to be inspected

c? 6ocumented inspection procedured? Inspection reporting forms

e? Current anomalies or issues list

Input to the inspection may also include the following:

f? Inspection checklists

g? #ny regulations, standards, guidelines, plans, and procedures against which the

software product is to be inspectedh? 0ardware product specifications

i? 0ardware performance data

1? #nomaly categories

The individuals may make additional reference material available responsible for the

software product when re&uested by the inspection leader.The purpose of the e'it criteria is to bring an unambiguous closure to the inspection

meeting. The e'it decision shall determine if the software product meets the inspection

e'it criteria and shall prescribe any appropriate rework and verification. "pecifically, the

inspection team shall identify the software product disposition as one of the following:a? #ccept with no or minor rework. The software product is accepted as is or with only

minor rework. >or e'ample, that would re&uire no further verification?.

b? #ccept with rework verification. The software product is to be accepted after theinspection leader or

a designated member of the inspection team >other than the author? verifies rework.

c? e$inspect. "chedule a re$inspection to verify rework. #t a minimum, a re$inspectionshall e'amine the software product areas changed to resolve anomalies identified in the

last inspection, as well as side effects of those changes.

)-


26/138


White 4o: +esting$&

@hite bo' testing involves looking at the structure of the code. @hen you know theinternal structure of a product, tests can be conducted to ensure that the internal

operations performed according to the specification. #nd all internal components have been ade&uately e'ercised. In other word @BT tends to involve the coverage of the

specification in the code.

Code coverage is defined in si' types as listed below.

• "egment coverage 4 Each segment of code b8w control structure is e'ecuted at

least once.

• Branch Coverage or Jode Testing 4 Each branch in the code is taken in each

possible direction at least once.• Compound Condition Coverage 4 @hen there are multiple conditions, you must

test not only each direction but also each possible combinations of conditions,which is usually done by using a 2Truth Table

• Basis 3ath Testing 4 Each independent path through the code is taken in a pre$

determined order. This point will further be discussed in other section.

• 6ata low Testing >6T? 4 In this approach you track the specific variables

through each possible calculation, thus defining the set of intermediate paths

through the code i.e., those based on each piece of code chosen to be tracked.

Even though the paths are considered independent, dependencies across multiple

paths are not really tested for by this approach. 6T tends to reflect dependencies but it is mainly through se&uences of data manipulation. This approach tends to

uncover bugs like variables used but not initiali


27/138


• uarantee that all independent paths within a module have been e'ercised at

least once.

•E'ercise all logical decisions on their true and false values.

• E'ecute all loops at their boundaries and within their operational bounds

• E'ercise internal data structures to ensure their validity.

@hite bo' testing >@BT? is also called "tructural or lass bo' testing.

@hy @BTA

@e do @BT because Black bo' testing is unlikely to uncover numerous sorts of defects

in the program. These defects can be of the following nature:

• ;ogic errors and incorrect assumptions are inversely proportional to the probability that a program path will be e'ecuted. Error tend to creep into our

work when we design and implement functions, conditions or controls that are

out of the program

• The logical flow of the program is sometimes counterintuitive, meaning that

our unconscious assumptions about flow of control and data may lead to

design errors that are uncovered only when path testing starts.

• Typographical errors are random, some of which will be uncovered by synta'

checking mechanisms but others will go undetected until testing begins.

-imitations$&

nfortunately in @BT, e'haustive testing of a code presents certain logistical problems.

Even for small programs, the number of possible logical paths can be very large. or

instance, a (GG line C ;anguage program that contains two nested loops e'ecuting ( to )Gtimes depending upon some initial input after some basic data declaration. Inside the

interior loop four if$then$else constructs are re&uired. Then there are appro'imately (G (+

logical paths that are to be e'ercised to test the program e'haustively. @hich means that amagic test processor developing a single test case, e'ecute it and evaluate results in one

millisecond would re&uire *(HG years working continuously for this e'haustive testing

which is certainly impractical. E'haustive @BT is impossible for large software systems.But that doesnt mean @BT should be considered as impractical. ;imited @BT in which

a limited no. of important logical paths are selected and e'ercised and important datastructures are probed for validity, is both practical and @BT. It is suggested that white

and black bo' testing techni&ues can be coupled to provide an approach that thatvalidates the software interface selectively ensuring the correction of internal working of

the software.

)H


28/138


4asis Path +esting$&

Basis path testing is a white bo' testing techni&ue first proposed by Tom McCabe. The

Basis path method enables to derive a logical comple'ity measure of a procedural designand use this measure as a guide for defining a basis set of e'ecution paths. Test Cases

derived to e'ercise the basis set are guaranteed to e'ecute every statement in the program

at least one time during testing.

The flow graph depicts logical control flow using a diagrammatic notation. Eachstructured construct has a corresponding flow graph symbol.

#yclomatic #omple:ity$&

Cyclomatic comple'ity is a software metric that provides a &uantitative measure of the

logical comple'ity of a program. @hen used in the conte't of a basis path testing method,the value computed for Cyclomatic comple'ity defines the number for independent paths

in the basis set of a program and provides us an upper bound for the number of tests that

must be conducted to ensure that all statements have been e'ecuted at least once.#n independent path is any path through the program that introduces at least one new set

of processing statements or a new condition.

#omputing #yclomatic #omple:ity$&

Cyclomatic comple'ity has a foundation in graph theory and provides us with e'tremely

useful software metric. Comple'ity is computed in one of the three ways:(. The number of regions of the flow graph corresponds to the Cyclomatic comple'ity.

). Cyclomatic comple'ity, 9>?, for a flow graph, is defined as

9 >? E$JR)@here E, is the number of flow graph edges, J is the number of flow graph nodes.

*. Cyclomatic comple'ity, 9 >? for a flow graph, is also defined as:

9 >? 3R(

@here 3 is the number of predicate nodes contained in the flow graph .

>raph "atrices$&

The procedure for deriving the flow graph and even determining a set of basis paths isamenable to mechani


29/138


#ontrol Structure +esting$&

6escribed below are some of the variations of Control "tructure Testing.

#ondition +esting$&

Condition testing is a test case design method that e'ercises the logical conditions

contained in a program module.

Data !low +esting$&

The data flow testing method selects test paths of a program according to the locations of

definitions and uses of variables in the program.

-oop +esting$&

;oop Testing is a white bo' testing techni&ue that focuses e'clusively on the validity of loop constructs. our classes of loops can be defined: "imple loops, Concatenated loops,

nested loops, and unstructured loops.

Simple -oops$&

The following sets of tests can be applied to simple loops, where 2n is the ma'imum

number of allowable passes through the loop.

(. "kip the loop entirely.

). nly one pass through the loop.*. Two passes through the loop.

+. 2m passes through the loop where mVn.

-. n$(, n, nR( passes through the loop.

1ested -oops$&

If we e'tend the test approach from simple loops to nested loops, the number of possibletests would grow geometrically as the level of nesting increases.

(. "tart at the innermost loop. "et all other loops to minimum values.

). Conduct simple loop tests for the innermost loop while holding the outer loops at their minimum iteration parameter values. #dd other tests for out$of$range or e'clude values.

)N


30/138


*. @ork outward, conducting tests for the ne't loop, but keep all other outer loops at

minimum values and other nested loops to 5typical7 values.

+. Continue until all loops have been tested.

#oncatenated -oops$&

Concatenated loops can be tested using the approach defined for simple loops, if each of

the loops is independent of the other. 0owever, if two loops are concatenated and the

loop counter for loop ( is used as the initial value for loop ), then the loops are notindependent.

Unstructured -oops$&

@henever possible, this class of loops should be redesigned to reflect the use of the

structured programming constructs.

4lac3 4o: +esting$

Black bo' is a test design method. Black bo' testing treats the system as a Qblack$bo'Q,so it doesnOt e'plicitly use Unowledge of the internal structure. r in other words the Test

engineer need not know the internal working of the 5Black bo'7.

It focuses on the functionality part of the module.

"ome people like to call black bo' testing as behavioral, functional, opa&ue$bo', andclosed$bo'. @hile the term black bo' is most popularly use, many people prefer the

terms QbehavioralQ and QstructuralQ for black bo' and white bo' respectively. Behavioral

test design is slightly different from black$bo' test design because the use of internal

knowledge isnOt strictly forbidden, but itOs still discouraged.

3ersonally we feel that there is a trade off between the approaches used to test a product

using white bo' and black bo' types.There are some bugs that cannot be found using only black bo' or only white bo'. If the

test cases are e'tensive and the test inputs are also from a large sample space then it isalways possible to find ma1ority of the bugs through black bo' testing.

#dvantages:$

$ Tester can be non$technical.

$ This testing is most likely to find those bugs as the user would find.

*G


31/138


$ Testing helps to identify the vagueness and contradiction in functional specifications.

$ Test cases can be designed as soon as the functional specifications are complete

Disadvantages$&

$ Chances of having repetition of tests that are already done by programmer.$ The test inputs needs to be from large sample space.

$ It is difficult to identify all possible inputs in limited testing time. "o writing test cases

is slow and difficult

Chances of having unidentified paths during this testing

8alidation Phase$&

The 9alidation 3hase falls into picture after the software is ready or when the code is

being written. There are various techni&ues and testing types that can be appropriatelyused while performing the testing activities. ;et us e'amine a few of them.

Unit Testing:-

This is a typical scenario of Manual nit Testing activity$

# nit is allocated to a 3rogrammer for programming. 3rogrammer has to use

2unctional "pecifications document as input for his work. 3rogrammer prepares

23rogram "pecifications for his nit from the unctional "pecifications. 3rogram"pecifications describe the programming approach, coding tips for the nits coding.

The programmer implements some functionality for the system to be developed. The

same is tested by referring the unit test cases. @hile testing that functionality if

any defects have been found, they are recorded using the defect logging toolwhichever is applicable. The programmer fi'es the bugs found and tests the

same for any errors.

Stubs and Drivers$&

# software application is made up of a number of 2nits, where output of one 2nit

goes as an 2Input of another nit. e.g. # 2"ales rder 3rinting program takes a 2"ales

rder as an input, which is actually an output of 2"ales rder Creation program.

6ue to such interfaces, independent testing of a nit becomes impossible. But that iswhat we want to do% we want to test a nit in isolationP "o here we use 2"tub and

26river.# Driver9 is a piece of software that drives >invokes? the nit being tested. # driver

creates necessary 2Inputs re&uired for the nit and then invokes the nit.

*(


32/138


# nit may reference another nit in its logic. # 2"tub takes place of such subordinate

unit during the nit Testing. # 2"tub is a piece of software that works similar to a unit

which is referenced by the nit being tested, but it is much simpler that the actual unit. #Stub works as a 2"tand$in for the subordinate unit and provides the minimum re&uired

behavior for that unit.3rogrammer needs to create such 26rivers and 2"tubs for carrying out nit Testing.

Both the 6river and the "tub are kept at a minimum level of comple'ity, so that they do

not induce any errors while testing the nit in &uestion.

E'ample $ or nit Testing of 2"ales rder 3rinting program, a 26river program will

have the code which will create "ales rder records using hardcoded data and then call

2"ales rder 3rinting program. "uppose this printing program uses another unit whichcalculates "ales discounts by some comple' calculations. Then call to this unit will be

replaced by a 2"tub, which will simply return fi' discount data.

ntegration Testing:-

Integration testing is a systematic techni&ue for constructing the program structure while

at the same time conducting tests to uncover errors associated with interfacing. Theob1ective is to take unit tested components and build a program structure that has been

dictated by design.

sually, the following methods of Integration testing are followed:

(. Top$down Integration approach.

). Bottom$up Integration approach.

+op&Down ntegration$&

Top$down integration testing is an incremental approach to construction of programstructure. Modules are integrated by moving downward through the control hierarchy,

beginning with the main control module. Modules subordinate to the main control

module are incorporated into the structure in either a depth$first or breadth$first manner.

(. The Integration process is performed in a series of five steps:

). The main control module is used as a test driver and stubs are substituted for allcomponents directly subordinate to the main control module.

*. 6epending on the integration approach selected subordinate stubs are replacedone at a time with actual components.+. Tests are conducted as each component is integrated.

-. n completion of each set of tests, stub is replaced with the real component.

F. egression testing may be conducted to ensure that new errors have not been

introduced.

*)


33/138


4ottom&Up ntegration$&

Bottom$up integration testing begins construction and testing with atomic modules >i.e.

components at the lowest levels in the program structure?. Because components areintegrated from the bottom up, processing re&uired for components subordinate to a given

level is always available and the need for stubs is eliminated.

(. # Bottom$up integration strategy may be implemented with the following steps:

). ;ow level components are combined into clusters that perform a specific softwaresub function.

*. # driver is written to coordinate test case input and output.

+. The cluster is tested.6rivers are removed and clusters are combined moving upward in the program structure.

Syste! Testing:-

"ystem testing concentrates on testing the complete system with a variety of techni&ues

and methods. "ystem Testing comes into picture after the nit and Integration Tests.

#ompatibility +esting$&

Compatibility Testing concentrates on testing whether the given application goes wellwith third party tools, software or hardware platform.

or e'ample, you have developed a web application. The ma1or compatibility issue is, the

web site should work well in various browsers. "imilarly when you develop applications

on one platform, you need to check if the application works on other operating systems aswell. This is the main goal of Compatibility Testing.

Before you begin compatibility tests, our sincere suggestion is that you should have across reference matri' between various softwares, hardware based on the application

re&uirements. or e'ample, let us suppose you are testing a web application. # sample list

can be as follows:

0ardware "oftware perating "ystem

3entium 4 II, ()K MB #M IE +.', pera, Jetscape @indows N-

3entium 4 III, )-F MB

#M

IE -.', Jetscape @indows S3

3entium 4 I9, -() MB

#M

Mo


34/138


Compatibility Testing is very crucial to organi


35/138


"tress testing e'ecutes a system in a manner that demands resources in abnormal

&uantity, fre&uency, or volume. The following types of tests may be conducted during

stress testing%• "pecial tests may be designed that generate ten interrupts per second, when

one or two is the average rate.

• Input data rates may be increases by an order of magnitude to determine how

input functions will respond.

• Test Cases that re&uire ma'imum memory or other resources.

• Test Cases that may cause e'cessive hunting for disk$resident data.

• Test Cases that my cause thrashing in a virtual operating system.

Performance +esting3erformance testing of a @eb site is basically the process of understanding how the @ebapplication and its operating environment respond at various user load levels. In general,

we want to measure the esponse Time, Throughput, and tili


36/138


The ob1ective of load testing is to check whether the system can perform well for

specified load. The system may be capable of accommodating more than (GGG concurrentusers. But, validating that is not under the scope of load testing. Jo attempt is made to

determine how many more concurrent users the system is capable of servicing. Table (illustrates the e'ample specified.

Stress testing$&

"tress testing is another industry term of performance testing. Though load testing =

"tress testing are used synonymously for performance4related efforts, their goal is

different.

nlike load testing where testing is conducted for specified number of users, stresstesting is conducted for the number of concurrent users beyond the specified limit. Theob1ective is to identify the ma'imum number of users the system can handle before

breaking down or degrading drastically. "ince the aim is to put more stress on system,

think time of the user is ignored and the system is e'posed to e'cess load. The goals of load and stress testing are listed in Table ). efer to table * for the inference drawn

through the 3erformance Testing Efforts.

;et us take the same e'ample of online shopping application to illustrate the ob1ective of stress testing. It determines the ma'imum number of concurrent users an online system

can service which can be beyond (GGG users >specified limit?. 0owever, there is a

possibility that the ma'imum load that can be handled by the system may found to besame as the anticipated limit.

"tress testing also determines the behavior of the system as user base increases. It checkswhether the system is going to degrade gracefully or crash at a shot when the load goes

beyond the specified limit.

;oad and stress testing of illustrative e'ample

Types of Testing Jumber of Concurrent users 6uration

;oad Testing ( ser

-G sers

(GG sers

)-Gsers-GG sers!!!!.

(GGGsers

() 0ours

"tress Testing ( ser -G sers (GG sers )-G

sers-GG sers!!!!.

() 0ours

*F


37/138


(GGGsers Beyond (GGG

sers!!!..Ma'imum sers

oals of load and stress testing

Types of testing oals

;oad testing • Testing for anticipated user base

• 9alidates whether system is

capable of handling load under

specified limit

"tress testing • Testing beyond the anticipated

user base

• Identifies the ma'imum load a

system can handle

• Checks whether the system

degrades gracefully or crashes at

a shot

,egression +esting$&

egression testing as the name suggests is used to test 8 check the effect of changes madein the code. Most of the time the testing team is asked to check last minute changes in the

code 1ust before making a release to the client, in this situation the testing team needs to

check only the affected areas. "o in short for the regression testing the testing teamshould get the input from the development team about the nature 8 amount of change in

the fi' so that testing team can first check the fi' and then the side effects of the fi'.

In fact the regression testing is the testing in which ma'imum automation can be done.The reason being the same set of test cases will be run on different builds multiple times.

But again the e'tent of automation depends on whether the test cases will remain

applicable over the time, In case the automated test cases do not remain applicable for some amount of time then test engineers will end up in wasting time to automate and

dont get enough out of automation.

*H


38/138


egression Testing is retesting unchanged segments of application. It involves rerunning

tests that have been previously e'ecuted to ensure that the same results can be achieved

currently as were achieved when the segment was last tested.

The selective retesting of a software system that has been modified to ensure that any bugs have been fi'ed and that no other previously working functions have failed as a

result of the reparations and that newly added features have not created problems with

previous versions of the software. #lso referred to as verification testing, regression

testing is initiated after a programmer has attempted to fi' a recogni


39/138


document must provide generic test approach as well as specific details regarding the

pro1ect. The following areas are addressed in the test strategy document.

or e'ample we should have a master Test "trategy document at a pro1ect level and weshould have a detailed Test 3lan for every release. This document should give the overall

scope of pro1ect at a high level.

( +est -evels

The test strategy must talk about what are the test levels that will be carried out for that particular pro1ect. nit, Integration = "ystem testing will be carried out in all pro1ects.

But many times, the integration = system testing may be combined. 6etails like this may

be addressed in this section.

,oles and ,esponsibilities

The roles and responsibilities of test leader, individual testers, pro1ect manager are to beclearly defined at a pro1ect level in this section. This may not have names associated: but

the role has to be very clearly defined. The review and approval mechanism must be

stated here for test plans and other test documents. #lso, we have to state who reviews thetest cases, test records and who approved them. The documents may go thru a series of

reviews or multiple approvals and they have to be mentioned here.

6 +esting +ools

#ny testing tools, which are to be used in different test levels, must be, clearly identified.

This includes 1ustifications for the tools being used in that particular level also.

7 ,is3s and "itigation

#ny risks that will affect the testing process must be listed along with the mitigation. By

documenting the risks in this document, we can anticipate the occurrence of it well aheadof time and then we can proactively prevent it from occurring. "ample risks are

dependency of completion of coding, which is done by sub$contractors, capability of

testing tools etc.

5 ,egression +est (pproach

@hen a particular problem is identified, the programs will be debugged and the fi' will

be done to the program. To make sure that the fi' works, the program will be testedagain. egression test will make sure that one fi' does not create some other problems in

that program or in any other interface. "o, a set of related test cases may have to be

repeated again, to make sure that nothing else is affected by a particular fi'. 0ow this isgoing to be carried out must be elaborated in this section. In some companies, whenever

there is a fi' in one unit, all unit test cases for that unit will be repeated, to achieve a

higher level of &uality.

*N


40/138


@ +est >roups

rom the list of re&uirements, we can identify related areas, whose functionality issimilar. These areas are the test groups. or e'ample, in a railway reservation system,

anything related to ticket booking is a functional group% anything related with reportgeneration is a functional group. "ame way, we have to identify the test groups based on

the functionality aspect.

A +est Priorities

#mong test cases, we need to establish priorities. @hile testing software pro1ects, certain

test cases will be treated as the most important ones and if they fail, the product cannot be

released. "ome other test cases may be treated like cosmetic and if they fail, we canrelease the product without much compromise on the functionality. This priority levels

must be clearly stated. These may be mapped to the test groups also.

B +est Status #ollections and ,eporting

@hen test cases are e'ecuted, the test leader and the pro1ect manager must know, where

e'actly we stand in terms of testing activities. To know where we stand, the inputs fromthe individual testers must come to the test leader. This will include, what test cases are

e'ecuted, how long it took, how many test cases passed and how many$failed etc. #lso,

how often we collect the status is to be clearly mentioned. "ome companies will have a

practice of collecting the status on a daily basis or weekly basis. This has to be mentionedclearly.

C +est ,ecords "aintenance

@hen the test cases are e'ecuted, we need to keep track of the e'ecution details like

when it is e'ecuted, who did it, how long it took, what is the result etc. This data must be

available to the test leader and the pro1ect manager, along with all the team members, in acentral location. This may be stored in a specific directory in a central server and the

document must say clearly about the locations and the directories. The naming

convention for the documents and files must also be mentioned.

. ,equirements +raceability "atri:

Ideally each software developed must satisfy the set of re&uirements completely. "o, right

from design, each re&uirement must be addressed in every single document in thesoftware process. The documents include the 0;6, ;;6, source codes, unit test cases,

integration test cases and the system test cases. efer the following sample table which

describes e&uirements Traceability Matri' process. In this matri', the rows will have there&uirements. or every document D0;6, ;;6 etcX, there will be a separate column. "o,

in every cell, we need to state, what section in 0;6 addresses a particular re&uirement.

Ideally, if every re&uirement is addressed in every single document, all the individual

+G


41/138


cells must have valid section ids or names filled in. Then we know that every re&uirement

is addressed. In case of any missing of re&uirement, we need to go back to the document

and correct it, so that it addressed the re&uirement. or testing at each level, we may haveto address the re&uirements. ne integration and the system test case may address

multiple re&uirements.

.. +est Summary

The senior management may like to have test summary on a weekly or monthly basis. If

the pro1ect is very critical, they may need it on a daily basis also. This section mustaddress what kind of test summary reports will be produced for the senior management

along with the fre&uency.

The test strategy must give a clear vision of what the testing team will do for the whole

pro1ect for the entire duration. This document will8may be presented to the client also, if

needed. The person, who prepares this document, must be functionally strong in the product domain, with a very good e'perience, as this is the document that is going to

drive the entire team for the testing activities. Test strategy must be clearly e'plained to

the testing team members tight at the beginning of the pro1ect.

Test Plan:-

The test strategy identifies multiple test levels, which are going to be performed for the pro1ect. #ctivities at each level must be planned well in advance and it has to be formally

documented. Based on the individual plans only, the individual test levels are carried out.

The plans are to be prepared by e'perienced people only. In all test plans, the ET9SDEntry$Task$9alidation$E'itX criteria are to be mentioned. Entry means the entry point to

that phase. or e'ample, for unit testing, the coding must be complete and then only one

can start unit testing. Task is the activity that is performed. 9alidation is the way in whichthe progress and correctness and compliance are verified for that phase. E'it tells the

completion criteria of that phase, after the validation is done. or e'ample, the e'it

criterion for unit testing is all unit test cases must pass.

ET9S is a modeling techni&ue for developing worldly and atomic level models. It sands

for Entry, Task, 9erification and E'it. It is a task$based model where the details of eachtask are e'plicitly defined in a specification table against each phase i.e. Entry, E'it, Task,

eedback In, eedback ut, and measures.There are two types of cells, unit cells and implementation cells. The implementationcells are basically unit cells containing the further tasks.

or e'ample if there is a task of si


42/138


The unit cell containing these further tasks will be referred to as the implementation cell

and a separate table will be constructed for it.

# purpose is also stated and the viewer of the model may also be defined e.g. topmanagement or customer.

Unit +est Plan$&The test plan is the overall plan to carry out the unit test activities.The lead tester prepares it and it will be distributed to the individual testers, which

contains the following sections.

. What is to be tested?

The unit test plan must clearly specify the scope of unit testing. In this, normally the basic

input8output of the units along with their basic functionality will be tested. In this casemostly the input units will be tested for the format, alignment, accuracy and the totals.

The T3 will clearly give the rules of what data types are present in the system, their format and their boundary conditions. This list may not be e'haustive% but it is better tohave a complete list of these details.

Sequence of +esting

The se&uences of test activities that are to be carried out in this phase are to be listed in

this section. This includes whether to e'ecute positive test cases first or negative test

cases first, to e'ecute test cases based on the priority, to e'ecute test cases based on test

groups etc. 3ositive test cases prove that the system performs what is supposed to do%negative test cases prove that the system does not perform what is not supposed to do.

Testing the screens, files, database etc., are to be given in proper se&uence.

6 4asic !unctionality of Units

0ow the independent functionalities of the units are tested which e'cludes any

communication between the unit and other units. The interface part is out of scope of thistest level. #part from the above sections, the following sections are addressed, very

specific to unit testing.

• nit Testing Tools

• 3riority of 3rogram units

• Jaming convention for test cases

• "tatus reporting mechanism

• egression test approach

• ET9S criteria

ntegration +est PlanThe integration test plan is the overall plan for carrying out the activities in the

integration test level, which contains the following sections.

+)


43/138


/.What is to be tested?

This section clearly specifies the kinds of interfaces fall under the scope of testinginternal, e'ternal interfaces, with re&uest and response is to be e'plained. This need not

go deep in terms of technical details but the general approach how the interfaces aretriggered is e'plained.

/Sequence of ntegration

@hen there are multiple modules present in an application, the se&uence in which theyare to be integrated will be specified in this section. In this, the dependencies between the

modules play a vital role. If a unit B has to be e'ecuted, it may need the data that is fed

by unit # and unit S. In this case, the units # and S have to be integrated and then usingthat data, the unit B has to be tested. This has to be stated to the whole set of units in the

program. iven this correctly, the testing activities will lead to the product, slowly

building the product, unit by unit and then integrating them.

/6 -ist of "odules and nterface !unctions

There may be J number of units in the application, but the units that are going tocommunicate with each other, alone are tested in this phase. If the units are designed in

such a way that they are mutually independent, then the interfaces do not come into

picture. This is almost impossible in any system, as the units have to communicate to

other units, in order to get different types of functionalities e'ecuted. In this section, weneed to list the units and for what purpose it talks to the others need to be mentioned. This

will not go into technical aspects, but at a higher level, this has to be e'plained in plain

English.

6 System +est Plan ES+PFThe system test plan is the overall plan carrying out the system test level activities. In thesystem test, apart from testing the functional aspects of the system, there are some special

testing activities carried out, such as stress testing etc. The following are the sections

normally present in system test plan.

6/.What is to be tested? )Should define both in scope and out scope of testing*

This section defines the scope of system testing, very specific to the pro1ect. Jormally,

the system testing is based on the re&uirements. #ll re&uirements are to be verified in thescope of system testing. This covers the functionality of the product. #part from this what

special testing is performed are also stated here.

6/ !unctional >roups and the Sequence

The re&uirements can be grouped in terms of the functionality. Based on this, there may

be priorities also among the functional groups. or e'ample, in a banking application,

+*


44/138


anything related to customer accounts can be grouped into one area, anything related to

inter$branch transactions may be grouped into one area etc. "ame way for the product

being tested, these areas are to be mentioned here and the suggested se&uences of testingof these areas, based on the priorities are to be described.

6/6Special +esting "ethods

This covers the different special tests like load8volume testing, stress testing,

interoperability testing etc. These testing are to be done based on the nature of the

product and it is not mandatory that every one of these special tests must be performedfor every product.

#part from the above sections, the following sections are addressed, very specific to

system testing.

•

"ystem Testing Tools• 3riority of functional groups

• Jaming convention for test cases

• "tatus reporting mechanism

• egression test approach

• ET9S criteria

• Build8efresh criteria

6/7 (cceptance +est Plan E(+PFThe client at their place performs the acceptance testing. It will be very similar to the

system test performed by the "oftware 6evelopment nit. "ince the client is the one whodecides the format and testing methods as part of acceptance testing, there is no specific

clue on the way they will carry out the testing. But it will not differ much from the

system testing. #ssume that all the rules, which are applicable to system test, can beimplemented to acceptance testing also.

"ince this is 1ust one level of testing done by the client for the overall product, it may

include test cases including the unit and integration test level details.

# sample Test 3lan utline along with their description is as shown below:

+est Plan Gutline

(. B#CUJ6 4 This item summari


45/138


*. #""M3TIJ" 4 Indicates any anticipated assumptions which will be made

while testing the application.

+. TE"T ITEM" $ ;ist each of the items >programs? to be tested.-. E#TE" T BE TE"TE6 $ ;ist each of the features >functions or

re&uirements?, which will be tested or demonstrated by the test.

F. E#TE" JT T BE TE"TE6 $ E'plicitly lists each feature, function, or

re&uirement which wonOt be tested and why not.

H. #33#C0 $ 6escribe the data flows and test philosophy.

"imulation or ;ive e'ecution, Etc. This section also mentions all the approaches,

which will be followed at the various stages of the test e'ecution.

K. ITEM 3#""8#I; CITEI# Blanket statement $ Itemi


46/138


(+. "T#IJ = T#IJIJ

(-. "C0E6;E

(F. E"CE"

(H. I"U" = CJTIJEJCIE"

(K. #339#;"

The schedule details of the various test pass such as nit tests, Integration tests, "ystemTests should be clearly mentioned along with the estimated efforts.

+est Plan ,eview$

#fter completion of preperation of test plan test lead conducts a review meeting for

completeness and correctness.In most of the companies review meetings conducted

through coverage analysis.

Coverage analysis are driven by the Checklist for the following,

"" Based Coverage

B" Based Coverage

+est #ase Design$&

6esigning good test cases is a comple' art. The comple'ity comes from three sources:

Test cases help us discover information. 6ifferent types of tests aremore effective for different classes of information.

Test cases can be 5good7 in a variety of ways. Jo test case will be

good in all of them. 3eople tend to create test cases according to certain testing styles,

such as domain testing or risk$based testing. ood domain tests are

different from good risk$based tests.

What9s a test case?

5# test case specifies the pretest state of the IT and its environment, the test inputs or conditions, and the e'pected result. The e'pected result specifies what the IT should

produce from the test inputs. This specification includes messages generated by the IT,

e'ceptions, returned values, and resultant state of the IT and its environment. Test casesmay also specify initial and resulting conditions for other ob1ects that constitute the IT

and its environment.7

+F


47/138


r

# Test Case is a description of what to be tested, what data to be given, what data to be

done to check the actual result against the e'pected.

r

The process of designing test cases, including e'ecuting them as thought e'periments,

will often identify bugs before the software has even been built. It is not uncommon tofind more bugs when designing tests than when e'ecuting tests.

;et us now see how to design test cases in a generic manner:

nderstand the re&uirements document.

Break the re&uirements into smaller re&uirements >if it improves your testability?.

or each e&uirement, decide what techni&ue you should use to derive the test

cases. or e'ample, if you are testing a ;ogin page, you need to write test cases

basing on error guessing and also negative cases for handling failures.

0ave a Traceability Matri' as follows:

e&uirement Jo >In 6? e&uirement Test Case Jo

@hat this Traceability Matri' provides you is the coverage of Testing. Ueep filling in theTraceability matri' when you complete writing test cases for each re&uirement.

What9s a scenario?

# scenario is a hypothetical story, used to help a person think through a comple' problem

or system.

#haracteristics of good test case$&

TC should start with 5what are u testing7

TC should be independent

TC should be not contain If 8 2or statements.

+H


48/138


TC should be uniform.

Every TC designed should be traced back to at least one re&uirement.

# TC should have high probability of finding errors.

ssues to consider during test case design$&

#ll testcases should be traceble

There shold not be many duplicate test cases

ut dated test cases should be cleared off

#ll test cases should be e'ecutable.

+est #ases +echniques$&

Error uessing Boundary value #nalysis

E&uivalence Class partition

%rror >uessing$&uessing is the art of guessing where errors can be hidden. There are no specific tools

and techni&ues for this, but you can write test cases depending on the situation: Either

when reading the functional documents or when you are testing and find an error that youhave not documented.

Error guessing is based mostly upon e'perience, with some assistance from other

techni&ues such as boundary value analysis. Based on e'perience, the test designer guesses the types of errors that could occur in a particular type of software and designs

test cases to uncover them. or e'ample, if any type of resource is allocated dynamically,a good place to look for errors is in the de$allocation of resources. #re all resources

correctly de$allocated, or are some lost as the software e'ecutesA

Error guessing by an e'perienced engineer is probably the single most effective methodof designing tests, which uncover bugs. # well$placed error guess can show a bug, which

could easily be missed by many of the other test case design techni&ues presented in this

paper.

Conversely, in the wrong hands error guessing can be a waste of time. To make thema'imum use of available e'perience and to add some structure to this test case designtechni&ue, it is a good idea to build a checklist of types of errors. This checklist can then

be used to help 5guess7 where errors may occur within a unit.The checklist should be

maintained with the benefit of e'perience gained in earlier unit tests, helping to improve

the overall effectiveness of error guessing.

+K


49/138


4oundary 8alue (nalysis$&

Boundary 9alue #nalysis >B9#? is a test data selection techni&ue >unctional Testingtechni&ue? where the e'treme values are chosen. Boundary values include ma'imum,

minimum, 1ust inside8outside boundaries, typical values, and error values. The hope is

that, if a system works correctly for these special values then it will work correctly for allvalues in between.

E'tends e&uivalence partitioning

Test both sides of each boundary

;ook at output boundaries for test cases too

Test min, min$(, ma', ma'R(, typical values B9# focuses on the boundary of the input space to identify test cases

ational is that errors tend to occur near the e'treme values of an input

variable

There are two ways to generali


50/138


-imitations of 4oundary 8alue (nalysis$&

B9# works best when the program is a function of several independent variables thatrepresent bounded physical &uantities

Independent 9ariables

o Je't6ate test cases derived from B9# would be inade&uate: focusing

on the boundary would not leave emphasis on ebruary or leap yearso 6ependencies e'ist with Je't6ateOs 6ay, Month and Wear

o Test cases derived without consideration of the function

3hysical /uantitieso #n e'ample of physical variables being tested, telephone numbers $

what faults might be revealed by numbers of GGG$GGGG, GGG$GGG(,

---$----, NNN$NNNK, NNN$NNNNA

%quivalence Partitioning$&

E&uivalence partitioning is a black bo' testing method that divides the input domain of a

program into classes of data from which test cases can be derived.

E3 can be defined according to the following guidelines:

(. If an input condition specifies a range, one valid and one two invalid classes are

defined.

). If an input condition re&uires a specific value, one valid and two invalid e&uivalenceclasses are defined.

*. If an input condition specifies a member of a set, one valid and one invalid e&uivalence

class is defined.

+. If an input condition is Boolean, one valid and one invalid class is defined.

#omparison +esting$&

There are situations where independent versions of software be developed for criticalapplications, even when only a single version will be used in the delivered computer

based system. It is these independent versions which form the basis of a black bo' testing

techni&ue called Comparison testing or back$to$back testing.

-G


51/138


Grthogonal (rray +esting$&

The rthogonal #rray Testing "trategy >#T"? is a systematic, statistical way of testing

pair$wise interactions by deriving a suitable small set of test cases >from a large number of possibilities?.

#haracteristics of >ood Scenarios

# scenario has five key characteristics. It is >a? a story that is >b? motivating, >c? credible,

>d? comple', and >e? easy to evaluate.

The primary ob1ective of test case design is to derive a set of tests that have the highest

attitude of discovering defects in the software. Test cases are designed based on theanalysis of re&uirements, use cases, and technical specifications, and they should be

developed in parallel with the software development effort.

# test case describes a set of actions to be performed and the results that are e'pected. #

test case should target specific functionality or aim to e'ercise a valid path through a usecase. This should include invalid user actions and illegal inputs that are not necessarily

listed in the use case. # test case is described depends on several factors, e.g. the number

of test cases, the fre&uency with which they change, the level of automation employed,

the skill of the testers, the selected testing methodology, staff turnover, and risk.

The test cases will have a generic format as below.

Test case I6 $ The test case id must be uni&ue across the application

Test case description $ The test case description must be very brief.

Test prere&uisite $ The test pre$re&uisite clearly describes what should be present

in the system, before the test can be e'ecutes. Test Inputs $ The test input is nothing but the test data that is prepared to be fed to

the system. Test steps $ The test steps are the step$by$step instructions on how to carry out the

test. E'pected esults $ The e'pected results are the ones that say what the system

must give as output or how the system must react based on the test steps. #ctual esults 4 The actual results are the ones that say outputs of the action for

the given inputs or how the system reacts for the given inputs.

-(


52/138


3ass8ail $ If the E'pected and #ctual results are same then test is 3ass otherwise

ail.

The test cases are classified into positive and negative test cases. 3ositive test cases aredesigned to prove that the system accepts the valid inputs and then process themcorrectly. "uitable techni&ues to design the positive test cases are "pecification derived

tests, E&uivalence partitioning and "tate$transition testing. The negative test cases are

designed to prove that the system re1ects invalid inputs and does not process them.

"uitable techni&ues to design the negative test cases are Error guessing, Boundary valueanalysis, internal boundary value testing and "tate$transition testing. The test cases details

must be very clearly specified, so that a new person can go through the test cases step and

step and is able to e'ecute it. The test cases will be e'plained with specific e'amples inthe following section.

or e'ample consider online shopping application. #t the user interface level the client

re&uest the web server to display the product details by giving email id and sername.The web server processes the re&uest and will give the response. or this application we

will design the unit, Integration and system test cases.

@eb based application

+est %ngineers can write testcases based on ,equiremnets or use casesH the use cases

are described as below

Use #ase

Each use case focuses on describing how to achieve a goal or task. or most software pro1ects this means that multiple, perhaps do


53/138


se cases should not be confused with the features of the system under consideration. #

use case may be related to one or more features, a feature may be related to one or more

use cases.# use case defines the interactions between e:ternal actors and the system under

consideration to accomplish a goal. #n actor is a role that a person or thing plays wheninteracting with the system. The same person using the system may be represented as two

different actors because they are playing different roles. or e'ample, QYoeQ could be

playing the role of a Customer when using an #utomated Teller Machine to @ithdraw

Cash, or playing the role of a Bank Teller when using the system to estock the Cash6rawer.

se cases treat the system as a black box, and the interactions with the system, including

system responses, are perceived as from outside the system. This is a deliberate policy, because it forces the author to focus on what the system must do, not how it is to be done,

and avoids the trap of making assumptions about how this functionality will be

accomplished.se cases may be described at the abstract level >business use case, sometimes called

essential use case?, or at the system level >system use case?. The difference between these

is the scope.The business use case is described in technology free terminology which treats the

business process as a black bo' and describes the business process that is used by its

business actors >people or systems? to achieve their goals >e.g., manual payment

processing, e'pense report approval, manage corporate real estate.? The business use casewill describe a process that provides value to the business actor, and it describes what the

process does.

The system use cases are normally described at the sub process level >for e'ample, createvoucher? and specify the data input and the e'pected data response. The system use case

will describe how the actor and the system interact. or this reason it is recommended

that a system use case specification begin with a verb >e.g., create voucher, select payments, exclude payment, cancel voucher.?

# use case should:

6escribe how the system shall be used by an actor to achieve a particular goal. 0ave no

implementation$specific language. Be at the appropriate level of detail. Jot include detailregarding user interfaces and screens. This is done in user$interface design.

Sample Use #ase Diagrams

# use case is a set of scenarios that describing an interaction between a user and a

system. # use case diagram displays the relationship among actors and use cases. The

two main components of a use case diagram are use cases and actors.

-*


54/138


#n actor represents a user or another system that will interact with the system you are

modeling. # use case is an e'ternal view of the system that represents some action the

user might perform in order to complete a task.

@hen to se: se Cases 6iagrams

se cases are used in almost every pro1ect. They are helpful in e'posing re&uirements

and planning the pro1ect. 6uring the initial stage of a pro1ect most use cases should bedefined, but as the pro1ect continues more might become visible.

0ow to 6raw: se Cases 6iagramsse cases are a relatively easy M; diagram to draw, but this is a very simplified

e'ample. This e'ample is only meant as an introduction to the M; and use cases.

"tart by listing a se&uence of steps a user might take in order to complete an action. or e'ample a user placing an order with a sales company might follow these steps.

(. Browse catalog and select items.

). Call sales representative.*. "upply shipping information.

+. "upply payment information.

-. eceive conformation number from salesperson.

These steps would generate this simple use case diagram:

-+


55/138

Manual

Manual Testing document

Documents

Transcript of Manual Testing document