7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 1/26

  Software Testing

Software

Testing

  1. Introduction to Software Testing

 

Software:

Software is a set of instructions to perform some task. Software is used in many applications

of the real world. Some of the examples are Application software, such as word processors

Firmware in a embedded system Middleware, which controls and co-ordinates distributed

systems  System software such as operating systems Video ames !ebsites All of these

applications need to run without any error and pro"ide a #uality ser"ice to the user of the

application. $n this regard the software has to be tested for its accurate and correct working.

Software Testing:

%esting can be defined in simple words as &'erforming Verification and Validation of the

Software 'roduct( for its correctness and accuracy of working. )ther definitions of Software

%esting*

Software testing is an in"estigation conducted to pro"ide stakeholders with information

about the #uality of the product or ser"ice under test. Software %esting also ensures whether 

the software program+application+product*

Meets the business and technical re#uirements that guided its design and de"elopment !orks

as expected and an be implemented with the same characteristics. %esting is done manuallyor using automated tools. %esting is done by a separate group of %esters. %esting is done

right from the beginning of the software de"elopment life cycle till the end it is

deli"ered to the customer.

Functional Vs non-functional testing: 

Functional testing refers to tests that "erify a specific action or function of the code. %hese are

usually found in the code re#uirements documentation, although some de"elopment

methodologies work from use cases or user stories. Functional tests tend to answer the

#uestion of can the user do this or does this particular feature work. /on-functional

testing refers to aspects of the software that may not be related to a specific function or user action, such as scalability or security.

 /on-functional testing tends to answer such #uestions as how man y people can log in at

once, or how easy is it to hack this software.

Page | 1

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 2/26

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 3/26

  Software Testing

Software

Testing

 Figure "1# to understand Error, Fault and Failure

Page | 3

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 4/26

  Software Testing

Software

Testing

Software Testing O$%ecti&es:

7. %esting is done to fulfill certain ob8ecti"es.

9. %o discuss the distinctions between "alidation testing and defect testing.

:. %o describe the principles of system and component testing.

;. %o describe strategies for generating system test cases.

<. %o understand the essential char acteristics of tool used for test automation.

=. %o find or pre"ent defects.

>. %o determine that software products satisfy specified re#uirements.

?. 1nsuring that a system is ready for use.

@. aining confidence that it works.

7. 'ro"iding information about the le"el of #uality.

77. Betermining user acceptability.

Software #uality measures how well software is designed 2#uality of design3, and how

well the software conforms to that design 2#uality of conformance3.

Page | 4

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 5/26

  Software Testing

Software

Testing

  '. Software (ualit) * Attri$utes:

1# +onforance to secification: 

Cuality that is defined as a matter of products and ser"ices whose measurable characteristics

satisfy a fixed specification D that is, conformance to an in beforehand defined specification.

2#eeting custoer needs:

Cuality that is identified independent of any measurable characteristics. %hat is, #uality is

defined as the products or ser"ices capability to meet customer expectations D explicit or not.

Software #uality is a multidimensional #uantity and is measurable. %o do this, we need to

di"ide and measure software #uality in terms of #uality attributes*

 

Static /ualit) Attri$utes

 

0)naic /ualit) Attri$utes

 

Te following figure sows te different (ualit) attri$utes:

 

Page | 5

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 6/26

  Software Testing

Software

Testing

  Software /ualit) Attri$utes: 

Software /ualit) Attri$utes:

- Static Attri$utes:

1. aintaina$ilit):

$n software engineering, the case with which a software product can be modified in order to*

correct defects. meet new re#uirements. make future maintenance easier, or cope with a

changed en"ironment. %hese acti"ities are known as software maintenance. A set of attributes

that bear on the effort needed to make specified modifications are*

1.1 Anal)a$ilit):

Attributes of software that bear on the effort needed for diagnosis of deficiencies or causes of 

failures, or for identification of parts to be modified

1.2 +angea$ilit):

Attributes of software that bear on the effort needed for modification, fault remo"al or for en"ironmental change.

1.' Sta$ilit):

Attributes of software that bear on the risk of unexpected effect of modifications

1.3 Testa$ilit):

Attributes of software that bear on the effort needed for "alidating the modified software. %he

degree to which a system or component facilitates the establishment of test criteria and the

 performance of tests to determine whether those criteria are met

Static %estability 1x* Software omplexity

Page | 6

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 7/26

  Software Testing

Software

Testing

Bynamic %estability 1x* %est o"erage riteria

- 0)naic Attri$utes:

1. +oleteness:

%he a"ailability of all the features listed in the re#uirements or in the user manual.

2. +onsistenc):

adherence to a common set of con"entions and assumptions.

2.1 +oliance:

Attributes of software that make the software adhere to  application related standards or 

con"entions or regulations in laws and similar   prescriptions.

2.2 +onforance :

Attributes of software that make the software adhere to standards or con"entions relating to

 portability.

'. !sa$ilit):

%he ease with which an application can be used. Esability testing also refers to testing

of a product by its potential users.

'.1 !nderstanda$ilit):

Attributes of software that bear on the users effort  for recogni4ing the logical concept and its

applicability.

'.2 earna$ilit):

Attributes of software that bear on the users effort for  learning its application.

'.' Oera$ilit) :

Attributes of software that bear on the users effort for  operation and operation control.

3. 4erforance:

%he time the application takes to perform a re#uested task. 'erformance is considered as a

non-functional re#uirement.

 3.1 Tie $ea&ior:

Attributes of software that bear on response and processing times and on throughput rates in

 performances its function.

3.2 Resource $ea&ior:

Page | 7

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 8/26

  Software Testing

Software

Testing

Attributes of software that bear on the amount of  resource used and the duration of such use

in performing its function

5. Relia$ilit):

Software Geliability is the probability of failure-free operation of  software o"er a gi"en time

inter"al and under gi"en conditions

5.1 aturit):

Attributes of software that bear on the fre#uency of failure by faults in the software.

5.2 Fault tolerance:

Attributes of software that bear on its ability to maintain a specified le"el of performance in

case of software faults or of  infringement of its specified interface.

5.' Reco&era$ilit):

Attributes of software that bear on the capability to re-establish its le"el of performance and

reco"er the data directly affected in case of a failure and on the time and effort needed for it.

6. +orrectness:

%he correct operation of an application

6.1 Accurateness*

Attributes of software that bear on the pro"ision of right or  agreed results or effects

6.2 Suita$ilit):

Attributes of software that bear on the presence and appropriateness of a set of functions for 

specified tasks

7. +orrectness:

$t attempts to establish that the program is error- free, testing attempts to find if there are

any errors in it.

Page | 8

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 9/26

  Software Testing

Software

Testing

3.Testing etods:

Static &s. d)naic testing *

%here are many approaches a"ailable in software testing. Ge"iews, walkthroughs, or 

inspections  are referred to as static testing, whereas actually executing programmed code

with a gi"en set of test cases is referred to as dynamic testing. Static testing is often implicit,

as proofreading, plus when programming tools+text editors check source code structure or 

compilers 2pre-compilers3 check syntax and data flow as static program analysis. Bynamic

testing takes place when the program itself is run. Bynamic testing may begin before the

 program is 7H complete in order to test particular sections of code and are applied to

discrete functions  or modules. %ypical techni#ues for this are either using stubs+dri"ers or 

execution from a debugger   en"ironment. Static testing in"ol"es "erification,   whereasdynamic testing in"ol"es "alidation. %ogether they help impro"e software #uality. Among the

techni#ues for static analysis, mutation testing can be used to ensure the test-cases will detect

errors which are introduced by mutating the source code.

Te $o8 aroac testing: 

Software testing methods are traditionally di"ided into white- and black-box testing. %hese

two approaches are used to describe the point of "iew that a test engineer takes when

designing test cases.

9ite-o8 testing:

!hite-box testing 2also known as clear box testing, glass box testing, transparent box testing

and structural testing3 tests internal structures or workings of a program, as opposed to the

functionality exposed to the end-user. $n white-box testing an internal perspecti"e of the

system, as well as programming skills, are used to design test cases. %he tester chooses inputs

to exercise paths through the code and determine the appropriate outputs. %his is analogous to

testing nodes in a circuit, e.g. in-circuit testing 2$%3. !hile white-box testing can be applied

at the unit, integration and system le"els of the software testing process, it is usually done at

the unit le"el. $t can test paths within a unit, paths between units during integration, and

 between subsystems during a systemDle"el test. %hough this method of test design can

unco"er many errors or problems, it might not detect unimplemented parts of the

specification or missing re#uirements.

Tecni(ues used in wite-$o8 testing include:

• A'$ testing 2application programming interface3 testing of the application using

 public and pri"ate A'$s.

• ode co"erage D creating tests to satisfy some criteria of code co"erage 2e.g.,

the test designer can create tests to cause all statements in the program to be

executed at least once3.

Page | 9

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 10/26

  Software Testing

Software

Testing

• Fault in8ection methods D intentionally introducing faults to gauge the efficacy

of testing strategies.

• Mutation testing methods.

• Static testing methods.

ode co"erage tools can e"aluate the completeness of a test suite that was created with any

method, $ncluding black-box testing. %his allows the software team to examine parts of a

system that are rarely tested and ensures that the most important function points ha"e been

tested. ode co"erage as a software metric can be reported as a percentage for*

•  Function coverage, which reports on functions executed.

• Statement coverage, which reports on the number of lines executed to

complete the test.

100% statement coverage ensures that all code paths or branches !n terms o"

control #o$ are e&ecuted at least once' (h!s !s help"ul !n ensur!ng )orrect

"unct!onal!t*+ but not su,c!ent s!nce the same code ma* process d!-erent !nputs

correctl* or !ncorrectl*'

lac;-$o8 testing:

  Black box diagram 

5lack-box testing treats the software as a black box, examining functionality without any

knowledge )f internal implementation. %he testers are only aware of what the software issupposed to do, not how it does it. 5lack-box testing methods include* e#ui"alence

 partitioning, boundary "alue analysis, all-pairs testing, state transition tables, decision table 

testing, fu44 testing, model-based testing, use case testing, exploratory testing and

specification-based testing.

Specification-based testing aims to test the functionality of software according to the

applicable re#uirements. %his le"el of testing usually re#uires thorough test cases to be

 pro"ided to the tester, who then can simply "erify that for a gi"en input, the output "alue 2or

 beha"ior3, either is or is not the same as the expected "alue specified in the test case. %est

cases are built around specifications and re#uirements, i.e., what the application is supposed

to do. $t uses external descriptions of the software, including specifications, re#uirements, and

Page | 10

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 11/26

  Software Testing

Software

Testing

designs to deri"e test cases. %hese tests can be functional or non-functional, though usually

functional. Specification-based testing may be necessary to assure correct functionality, but it

is insufficient to guard against complex or high-risk situations. )ne ad"antage of the black

 box techni#ue is that no programming knowledge is re#uired. !hate"er biases the

 programmers may ha"e had, the tester likely has a different set and may emphasi4e different

areas of functionality.

)n the other hand, black-box testing has been said to be like a walk in a dark labyrinth

without a flashlight. 5ecause they do not examine the source code, there are situations when

a tester writes many test cases to check something that could ha"e been tested by only one

test case, or lea"es some parts of the program untested. %his method of test can be applied to

all le"els of software testing* unit, integration, system and acceptance. $t typically comprises

most if not all testing at higher le"els, but can also dominate unit testing as well.  

Visual testing:

%he aim of "isual testing is to pro"ide de"elopers with the ability to examine what was

happening at the point of software failure by presenting the data in such a way that the

de"eloper can easily find the information he or she re#uires, and the information is expressed

clearly.

At the core of "isual testing is the idea that showing someone a problem 2or a test failure3,

rather than 8ust describing it, greatly increases clarity and understanding. Visual testing

therefore re#uires the recording of the entire test process D capturing e"erything that occurs

on the test system in "ideo format. )utput "ideos are supplemented by real-time tester input

"ia picture-in-a-picture webcam and audio commentary from microphones.Visual testing

 pro"ides a number of ad"antages. %he #uality of communication is increased dramatically

 because testers can show the problem 2and the e"ents leading up to it3 to the de"eloper as

opposed to 8ust describing it and the need to replicate test failures will cease to exist in many

cases. %he de"eloper will ha"e all the e"idence he or she re#uires of a test failure and can

instead focus on the cause of the fault and how it should be fixed.  

Visual testing is particularly well-suited for en"ironments that deploy agile methods in their

de"elopment of software, since agile methods re#uire greater communication between testers

and de"elopers and collaboration within small teams. Ad hoc testing and exploratory testing 

are important methodologies for checking software integrity, because they re#uire less

 preparation time to implement, while the important bugs can be found #uickly. $n ad hoc

testing, where testing takes place in an impro"ised, impromptu way, the ability of a test tool

to "isually record e"erything that occurs on a system becomes "ery important.

Visual testing is gathering recognition in customer acceptance and usability testing, because

the test can be used by many indi"iduals in"ol"ed in the de"elopment process. For the

customer, it becomes easy to pro"ide detailed bug reports and feedback, and for program

Page | 11

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 12/26

  Software Testing

Software

Testing

users, "isual testing can record user actions on screen, as well as their "oice and image, to

 pro"ide a complete picture at the time of software failure for the de"elop.

<re)-$o8 testing:

rey-box testing 2American spelling* gray-box testing3 in"ol"es ha"ing knowledge of

internal data structures and algorithms for purposes of designing tests, while executing those

tests at the user, or black-box le"el.

%he tester is not re#uired to ha"e full access to the softwares source code..an!pulat!ng

!nput data and "ormatt!ng output do not /ual!"* as gre*bo&+ because the !nput

and output are clearl* outs!de o" the blac bo& that $e are call!ng the s*stem

under test' (h!s d!st!nct!on !s part!cularl* !mportant $hen conduct!ng !ntegrat!on

test!ng bet$een t$o modules o" code $r!tten b* t$o d!-erent developers+ $here

onl* the !nter"aces are e&posed "or test'

0owe"er, tests that re#uire modifying a back-end data repository such as a database or a log

file does #ualify as grey-box, as the user would not normally be able to change the data

repository in normal production operations. rey-box testing may also include re"erse

engineering to determine, for instance, boundary "alues or error messages.

* no$!ng the underl*!ng concepts o" ho$ the so"t$are $ors+ the tester maes

better!n"ormed test!ng cho!ces $h!le test!ng the so"t$are "rom outs!de' (*p!call*+

a gre*bo& tester $!ll be perm!tted to set up an !solated test!ng env!ronment $!th

act!v!t!es such as seed!ng a database'

 (he tester can observe the state o" the product be!ng tested a"ter per"orm!ng

certa!n act!ons such as e&ecut!ng  statements aga!nst the database and then

e&ecut!ng /uer!es to ensure that the e&pected changes have been re#ected'

re*bo& test!ng !mplements !ntell!gent test scenar!os+ based on l!m!ted

!n"ormat!on' (h!s $!ll part!cularl* appl* to data t*pe handl!ng+ e&cept!on

handl!ng+ and so on'

Page | 12

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 13/26

  Software Testing

Software

Testing

5. Testing le&els: 

%here are generally four recogni4ed le"els of tests* unit testing, integration testing, system

testing, and acceptance testing. %ests are fre#uently grouped by where they are added in the

software de"elopment process, or by the le"el of specificity of the test.

 %he main le"els during the de"elopment process as defined by the S!15)I  guide are unit-,integration-, and system testing that are distinguished by the test target without implying a

specific process model. )ther test le"els are classified by the testing ob8ecti"e.

!nit testing:

Enit testing, also known as component testing, refers to tests that "erify the functionality of a

specific section of code, usually at the function le"el.

$n an ob8ect-oriented en"ironment, this is usually at the class le"el, and the minimal unit tests

include the constructors and destructors. %hese types of tests are usually written byde"elopers as they work on code 2white-box style3,to ensure that the specific function is

working as expected.

)ne function might ha"e multiple tests, to catch corner cases or other branches in the code.

Enit testing alone cannot "erify the functionality of piece of software, but rather is used to

ensure that the building blocks of the software work independently from each other.

Enit testing is a software de"elopment process that in"ol"es synchroni4ed application of a

 broad spectrum of defect pre"ention and detection strategies in order to reduce software

de"elopment risks, time, and costs. $t is performed by the software de"eloper or engineer

during the construction phase of the software de"elopment lifecycle. Gather than replace

Page | 13

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 14/26

  Software Testing

Software

Testing

traditional CA focuses, it augments it. Enit testing aims to eliminate construction errors

 before code is promoted to CA this strategy is intended to increase the #uality of the

resulting software as well as the efficiency of the o"erall de"elopment and CA process.

Bepending on the organi4ations expectations for software de"elopment, unit testing might

include static code analysis, data flow analysis, metrics analysis, peer code re"iews, code

co"erage analysis and other software "erification practices.

 

Integration testing:

$ntegration testing is any type of software testing that seeks to "erify the interfaces between

components against a software design. Software components may be integrated in an iterati"e

way or all together 2big bang3. /ormally the former is considered a better practice since it

allows interface issues to be located more #uickly and fixed. $ntegration testing works to

expose defects in the interfaces and interaction between integrated components 2modules3.

'rogressi"ely larger groups of tested software components corresponding to elements of the

architectural design are integrated and tested until the software works as a system.

+oonent interface testing:

%he practice of component interface testing can be used to check the handling of data passed

 between "arious units, or subsystem components, beyond 

full integration testing between

those units. %he data being passed can be considered as message packets and the range or

data types can be checked, for data generated from one unit, and tested for "alidity before

 being passed into another unit.

 )ne option for interface testing is to keep a separate log file of data items being passed, often

with a timestamp logged to allow analysis of thousands of cases of data passed between units

for days or weeks.

%ests can include checking the handling of some extreme data "alues while other interface

"ariables are passed as normal "alues. Enusual data "alues in an interface can help explain

unexpected performance in the next unit.

omponent interface testing is a "ariation of black-box testing, with the focus on the data

"alues beyond 8ust the related actions of a subsystem component.

S)ste testing:

*stem test!ng+ or endtoend test!ng+ tests a completel* !ntegrated s*stem tover!"* that !t meets !ts re/u!rements' or e&ample+ a s*stem test m!ght !nvolve

Page | 14

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 15/26

  Software Testing

Software

Testing

test!ng a logon !nter"ace+ then creat!ng and editing an entry, plus sending or printing

results, followed by summary processing or deletion 2or archi"ing3 of entries, then logoff.

n add!t!on+ the so"t$are test!ng should ensure that the program+ as $ell as$or!ng as e&pected+ does not also destro* or part!all* corrupt !ts operat!ng

env!ronment or cause other processes $!th!n that env!ronment to become

!noperat!ve th!s !ncludes not corrupt!ng shared memor*+ not consum!ng or

loc!ng up e&cess!ve resources and leav!ng an* parallel processes unharmed b*

!ts presence'

Accetance testing:

:t last the s*stem !s del!vered to the user "or :cceptance test!ng'

Page | 15

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 16/26

  Software Testing

Software

Testing

6. Testing T)es:

Installation testing:

:n !nstallat!on test assures that the s*stem !s !nstalled correctl* and $or!ng at

actual customer;s hard$are

+oati$ilit) testing:

: common cause o" so"t$are "a!lure real or perce!ved !s a lac o" !ts

compat!b!l!t* $!th other appl!cat!on so"t$are+ operat!ng s*stems or operat!ng

s*stem vers!ons+ old or ne$+ or target env!ronments that d!-er greatl* "rom the

or!g!nal such as a term!nal or < appl!cat!on !ntended to be run on the destop 

no$ be!ng re/u!red to become a $eb appl!cat!on+ $h!ch must render !n a $eb

bro$ser' or e&ample+ !n the case o" a lac o" bac$ard compat!b!l!t*+ th!s can

occur because the programmers develop and test so"t$are onl* on the latest

vers!on o" the target env!ronment+ $h!ch not all users ma* be runn!ng' (h!s

results !n the un!ntended conse/uence that the latest $or ma* not "unct!on on

earl!er vers!ons o" the target env!ronment+ or on older hard$are that earl!er

vers!ons o" the target env!ronment $as capable o" us!ng' omet!mes such !ssues

can be =&ed b* proact!vel* abstract!ng operat!ng s*stem "unct!onal!t* !nto a

separate program module or l!brar*' 

Regression testing: 

Gegression testing focuses on finding defects after a ma8or code change has occurred.

Specifically, it seeks to unco"er software regressions, as degraded or lost features, including

old bugs that ha"e come back. Such regressions occur whene"er software functionality that

was pre"iously working,

correctly, stops working as intended. %ypically, regressions occur as an unintended

conse#uence of program changes, when the newly de"eloped part of the software collides

with the pre"iously existing code. ommon methods of regression testing include re-running

 pre"ious sets of test-cases and checking whether pre"iously fixed faults ha"e re-emerged. %he

depth of testing depends on the phase in the release process and the risk  of the added features.

%hey can either be complete, for changes added late in the release or deemed to be risky, or

 be "ery shallow, consisting of positi"e tests on each feature, if the changes are early in the

release or deemed to be of low risk. Gegression testing is typically the largest test effort in

commercial software de"elopment, due to checking numerous details in prior software

features, and e"en new software can be de"eloped while using some old test-cases to test

 parts of the new design to ensure prior functionality is still supported. 

Accetance testing: 

Page | 16

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 17/26

  Software Testing

Software

Testing

Acceptance testing can mean one of two things*

7. A smoke test is used as an acceptance test prior to introducing a new build to the main

testing process, i.e. before integration or regression.

9. Acceptance testing performed by the customer, often in their lab en"ironment on their own

hardware, is known as user acceptance testing 2EA%3. Acceptance testing may be performed

as part of the hand-off process between any two phases of de"elopment. 

Ala testing: 

Alpha testing is simulated or actual operational testing by potential users+customers or an

independent test team at the de"elopers site. Alpha testing is often employed for off-the-shelf 

software as a form of internal acceptance testing, before the software goes to beta testing.

eta testing: 

eta test!ng comes a"ter alpha test!ng and can be cons!dered a "orm o" e&ternal

user acceptance test!ng' >ers!ons o" the so"t$are+ no$n as beta vers!ons+ are

released to a l!m!ted aud!ence outs!de o" the programm!ng team' (he so"t$are !s

released to groups o" people so that "urther test!ng can ensure the product has

"e$ "aults or bugs' omet!mes+ beta vers!ons are made ava!lable to the open

publ!c to !ncrease the "eedbac =eld to a ma&!mal number o" "uture users'

Functional &s non-functional testing: 

Functional testing refers to acti"ities that "erify a specific action or function of the code.

%hese are usually found in the code re#uirements documentation, although some

de"elopment methodologies work from use cases or user stories. Functional tests tend to

answer the #uestion of can the user do this or does this particular feature work. /on-

functional testing refers to aspects of the software that may not be related to a specific

function or user action, such as scalability or other performance, beha"ior under certain

constraints, or security. %esting will determine the breaking point, the point at which

extremes of scalability or performance leads to unstable execution.

 /on-functional re#uirements tend to be those that reflect the #uality of the product,

 particularly in the context of the suitability perspecti"e of its users. 

Securit) testing:

Security testing is essential for software that processes confidential data to pre"ent system

intrusion by hackers.

Page | 17

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 18/26

  Software Testing

Software

Testing

Testing rocess:

To-down and $otto-u:

5ottom Ep %esting is an approach to integrated testing where the lowest le"el components

2modules, procedures, and functions3 are tested first, then integrated and used to facilitate the

testing of higher le"el components. After the !ntegrat!on test!ng o" lo$er le"el

integrated modules, the next le"el of modules will be formed and can be used for integration

testing. %he process is repeated until the components at the top of the hierarchy are  tested.

%his approach is helpful only when all or most of the modules of the same de"elopment le"el

are ready.

%his method also helps to determine the le"els of software de"eloped and makes it easier toreport testing progress in the form of a percentage. %op Bown %esting is an approach to

integrated testing where the top integrated modules are tested and the branch of the module is

tested step by step until the end of the related module. $n both, method stubs and dri"ers are

used to stand-in for missing components and are replaced as the le"els are completed.  

A sale testing c)cle:

Although "ariations exist between organi4ations, there is a typical cycle for testing. %he

sample below is common among organi4ations employing the 

!aterfall de"elopment model.

%he same practices are commonly found in other de"elopment models, but might not be as

clear or explicit.

Ge#uirements analysis* %esting should begin in the re#uirements phase of the software

de"elopment life cycle. Buring the design phase, testers work to determine what aspects of a

design are testable and with what parameters those tests work.

%est planning* %est strategy, test plan, testbed creation. Since many acti"ities will be carried

out during testing, a plan is needed.

%est de"elopment* %est procedures, test scenarios, test cases, test datasets, test scripts to use

in %esting software.

%est execution* %esters execute the software based on the plans and test documents then

report any errors found to the de"elopment team.

%est reporting* )nce testing is completed, testers generate metrics and make final reports on

their test effort and whether or not the software tested is ready for release.

%est result analysis* )r Befect Analysis, is done by the de"elopment team usually along with

the client, in order to decide what defects should be assigned, fixed, re8ected 2i.e. found

software working properly3 or deferred to be dealt with later.

Page | 18

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 19/26

  Software Testing

Software

Testing

Befect Getesting* )nce a defect has been dealt with by the de"elopment team, it is retested

the testing team. AIA Gesolution testing.

Gegression testing* $t is common to ha"e a small test program built of a subset of tests,foreach integration of new, modified,or fixed software, in order to ensure that the latest deli"ery

has not ruined anything, and that the software product as a whole is still working correctly.

%est losure* )nce the test meets the exit criteria, the acti"ities such as capturing the key

outputs, lessons learned, results, logs, documents related to the pro8ect are archi"ed and used

as a reference for future pro8ects.

Autoated testing:

 

Many programming groups are relying more and more on automated testing, especially

groups that use test-dri"en de"elopment. %here are many frameworks to write tests in, and

continuous integration software will run tests automatically e"ery time code is checked into a

"ersion control system.

?h!le automat!on cannot reproduce ever*th!ng that a human can do and all the

$a*s the* th!n o" do!ng !t+ !t can be ver* use"ul "or regress!on test!ng' @o$ever+

!t does re/u!re a $elldeveloped test su!te o" test!ng scr!pts !n order to be trul*

use"ul' 

Testing Artifacts:

 (he so"t$are test!ng process can produce several art!"acts' 

Test lan

A test specification is called a test plan. %he de"elopers are well aware what test plans will be

executed and this information is made a"ailable to management and the de"elopers. %he idea

is to make them more cautious when de"eloping their code or making additional changes.

Some companies ha"e a higher-le"el document called a test strategy. 

Tracea$ilit) atri8A traceability matrix is a table that correlates re#uirements or design documents to test

documents. $t is used to change tests when related source documents are changed, to select

test cases for execution when planning for regression tests by considering re#uirement

co"erage. 

Test case

A test case normally consists of a uni#ue identifier, re#uirement references from a design

specification, preconditions, e"ents, a series of steps 2also known as actions3 to follow, input,

Page | 19

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 20/26

  Software Testing

Software

Testing

output, expected result,and actual result. linically defined a test case is an input and an

expected result.

%his can be as pragmatic as for condition x your deri"ed result is y, whereas other test casesdescribed in more detail the input scenario and what results might be expected. $t can

occasionally be a series of steps 2but often steps are contained in a separate test procedure

that can be exercised against multiple test cases, as a matter of economy3 but with one

expected result or expected outcome. %he optional fields are a test case $B, test step, or order

of execution number, related re#uirement2s3, depth, test category, author, and check boxes for 

whether the test is automatable and has been automated. Jarger test cases may also contain

 prere#uisite states or steps, and descriptions.

A test case should also contain a place for the actual result. %hese steps can be stored in a

word processor document, spreadsheet, database, or other common repository. $n a databasesystem, you may also be able to see past test results, who generated the results, and what

system configuration was used to generate those results. %hese past results would usually be

stored in a separate table. 

+orrectness Vs Relia$ilit):

 %he correctness will be established "ia re#uirement specification and the program text to

 pro"e that software is beha"ing as expected. %he reliability is the probability of the successful

execution of program on randomly selected elements from its input domain. %hough

correctness of a program is desirable, it is almost ne"er the ob8ecti"e of testing. %o establishcorrectness "ia testing would imply testing a program on all elements in the input domain. $n

most cases that are encountered in practice, this is impossible to accomplish. %hus correctness

is established "ia mathematical proofs of programs. !hile correctness attempts to establish

that the program is error free, testing attempts to find if there are any errors in it. %hus

completeness of testing does not necessarily demonstrate that a program is error Free.

Testing Vs 0e$ugging:

%esting is the process of determining if a program has any errors. !hen testing re"eals an

error, the process used to determine the cause of this error and to  remo"e it, is known as

debugging.K %esting catches and reports bugs.

K %esting reduces the probability of undisco"ered bugs remaining in the software

K %esting is not a proof of correctness 

K %esting can be planned with allocation of effort and schedule, resources, also,

ha"ing criteria on when to stop testing.

K %esting starts with known conditions like what to test, test input, expected output and

uses test procedures.

Page | 20

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 21/26

  Software Testing

Software

Testing

K %esting shows that bugs are present in a pro gram, but cannot pro"e that there are no

 bugs

K %here is no need to know design to carry-out testing

K ood testing is done by an outsider that is other than the team who de"elops the code

K %est automation in order to store and execute test cases can be done

K Bebugging is the process of analy4ing causes behind the bugs and remo"ing them

K Bebugging starts with a list of reported bugs with unknown initial conditions.

K $n debugging it is not possible to plan and estimate schedule and effort for  debugging

K Bebugging is a problem sol"ing in"ol"ing deduction

 

K Betailed design knowledge is of great help in good debugging

K Bebugging is done by the de"elopment team and hence is an insiders work

K Automation of debugging is not in place

%he figure shows a test+debug cycle*

K 1xecute the program on an empty input se#uence.

K %est the program for robustness against erroneous inputs such as &G66typed in as the re#uest

character.

K All failures of the test program should be recorded in a suitable file using the ompany

Failure Geport Form..

Page | 21

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 22/26

  Software Testing

Software

Testing

 

7. Software Testing ife +)cle:

Software testing life cycle identifies what test acti"ities to carry out and when 2what is  %he best time3to accomplish those test acti"ities. 1"en though testing differs between

organi4ations, there is a testing life cycle.

Software %esting Jife ycle consists of six 2generic3 phases*

Test 4lanning,

Test Anal)sis,

Test 0esign,

+onstruction and &erification,

Page | 22

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 23/26

  Software Testing

Software

Testing

 

Testing +)cles,

 Final %esting and $mplementation and 'ost $mplementation. Software testing has its own lifecycle that intersects with e"ery stage of the SBJ.

%he  basic re#uirements in software testing life cycle is to control+deal with software testing

 D  Manual, Automated and 'erformance.

Test 4lanning

%his is the phase where 'ro8ect Manager has to decide what things need to be tested, do $

ha"e the appropriate budget etc. /aturally proper planning at this stage would greatly  reduce

the risk of low #uality software. %his planning will be an ongoing process with no end point.

Acti"ities at this stage would include preparation of high le"el test plan-2according to $111

test plan template %he Software %est 'lan 2S%'3 is designed to prescribe the scope, approach,

resources, and schedule of all testing acti"ities. %he plan must identify the items to be tested,

the features to be tested, the types of testing to be performed, the  personnel responsible for 

testing, the resources and schedule re#uired to complete testing, and the risks associated with

the plan.3. Almost all of the acti"ities done during this stage  are included in this software test

 plan and re"ol"e around a test plan.

Test Anal)sis

)nce test plan is made and decided upon, next step is to del"e little more into the pro8ect

and decide what types of testing should be carried out at different stages of SBJ, do we

need or plan to automate, if yes then when the appropriate time to automate is, what type  of 

specific documentation $ need for testing.

'roper and regular meetings should be held between testing teams, pro8ect managers, and

de"elopment teams, 5usiness Analysts to check the progress of things which will gi"e a fair 

idea of the mo"ement of the pro8ect and ensure the completeness of the test plan created in

the planning phase, which will further help in enhancing the right testing strategy created

earlier. !e will start creating test case formats and test cases itself. $n this stage we need to

de"elop Functional "alidation matrix based on 5usiness  Ge#uirements to ensure that all

system re#uirements are co"ered by one or more test cases, identify which test cases to

automate, begin re"iew of documentation, i.e.  Functional Besign, 5usiness Ge#uirements,

'roduct Specifications, 'roduct 1xternals  etc. !e also ha"e to define areas for Stress and

'erformance testing.

Test 0esign

%est plans and cases which were de"eloped in the analysis phase are re"ised. Functional "alidation matrix is also re"ised and finali4ed. $n this stage risk assessment criteria is de"eloped. $f you ha"e thought of automation then you ha"e to select which test cases to automate and begin writing scripts for them. %est data is prepared. Standards for unit testing

and pass + fail criteria are defined here. Schedule for testing is re"ised 2if necessary3 Lfinali4ed and test en"ironment is prepared.

Page | 23

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 24/26

  Software Testing

Software

Testing

+onstruction and &erification

$n this phase we ha"e to complete all the test plans, test cases, complete the scripting

of  the automated test cases, Stress and 'erformance testing plans needs to be completed. !eha"e to support the de"elopment team in their unit testing phase. And ob"iously bug

reporting would be done as when the bugs are found. $ntegration tests are performed and

errors 2if any3 are reported. 

Testing +)cles

$n this phase we ha"e to complete testing cycles until test cases are executed without errors or 

a predefined condition is reached. Gun test cases -- Geport 5ugs -- re"ise test cases 2if 

needed3 -- add new test cases 2if needed3 -- bug fixing -- retesting 2test cycle 9, test

cycle :N.3.

Final %esting and $mplementation $n this we ha"e to execute remaining stress and

 performance test cases, documentation for testing is completed + updated, pro"ide and

complete different matrices for testing .Acceptance, load and reco"ery testing will also be

conducted and the application needs to  be "erified under production conditions.

'ost $mplementation

$n this phase, the testing process is e"aluated and lessons learnt from that testing process are

documented. Jine of attack to pre"ent similar problems in future pro8ects is  identified.

reate plans to impro"e the processes. %he recording of new errors and enhancements is an

ongoing process. leaning up of test en"ironment is done and test machines are restored to

 base lines in this stage.

1xample for %est plan

A test cycle is often guided by a test plan

Page | 24

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 25/26

  Software Testing

Software

Testing

+O=+!SIO=

Software %esting can be defined in simple words as &'erforming Verification and Validation

of the Software 'roduct( for its correctness and accuracy of working.

Software #uality is a multidimensional #uantity and is measurable.

%o do this, we need to di"ide and measure software #uality in terms of #uality attributes*

• Static Cuality Attributes.

• Bynamic Cuality Attributes.

%esting Methods*

Static "s nonstatic.

5ox approach2white box, grey box3.

%esting le"el*

Enit %esting, $ntegrated testing, component interface testing, system testing, acceptance

testing.

%esting types*

$nstallation testing, compatibility testing, regression testing, alpha testing, beta testing,security.

Software testing life cycle*

%est 'lanning,

%est Analysis,

%est Besign,

onstruction and "erification,

%esting ycles,

Thus ,we have studied aspects of “Software Testing>

 In detail as deccribed in this report.

Page | 25

7/25/2019 $sotware testing

http://slidepdf.com/reader/full/sotware-testing 26/26

  Software Testing

Software

Testing

  REFERA=+E

 

9e$site

 

www.9i;iedia.co

 

www.Softwarero%ects.co

 

www.1???ro%ects.co

 

www.Testingro$le.co

 

oo;s

 

Viul ra;es

 

Tec-a8 u$lication