QTP

Software Testing Guide

I) Introduction a) Software, Types of Software b) Software Project, Application and Product c) Software Business Process II) SDLC (Software Development Life Cycle) a) Requirements Gatherin b) Analysis ! Plannin c) Software "esi n d) #odin $%mplementation e) Testin f) Release ! &aintenance III) SDLC Models a) Sequential &odels ') (aterfall &odel )) *+, &odel b) %ncremental $ %terati-e &odels ') Prototype &odel )) Spiral &odel .) A ile &odel IV) Test Levels nit Testin $#omponent Testin $&odule Testin nte ration Testin ystem Testin cceptance Testin V) Software Environment a) %0Tier or Standalone Applications b) %%0Tier or #lient$Ser-er Applications c) %%%0Tier or (eb Applications d) 10Tier or "istributed Applications VI) Test Types a) 2unctional Testin b) 1on02unctional Testin c) Structural Testin d) Re ! Re ration Testin VII) Test Design Techniques a) Blac3 bo4 Techniques ') 5qui-alence Partitionin $ 5qui-alence #lasses 65P$5#) )) Boundary +alue Analysis 6B+A) .) "ecision Table Testin 7) State Transition Testin 8) /se #ase Testin b) (hite bo4 Techniques ') Statement Testin )) "ecision Testin .) #ondition$&ulti #ondition Testin

7) &utation Testin VIII) Testing rocess (STLC) a) Test Strategy b) Test Planning c) d) e) f) ) h) i) #onfi uration &ana ement Ris3 Analysis Test "esi n 6Test Scenarios, Test #ases and Test "ata) Test 54ecution "efect Reportin ! Trac3in Status Reportin Test #losure IX) Informal Testing a) 54ploratory Testin b) 5rror Guessin X) Quality Standards a) %S9 Standards b) %555 Standards c) #&&$#&& 6%) Process Guidelines

!I) Software "usiness Domains

a) b) c) d) e) f) B2S% 5RP :ealthcare Telecom 5commerce 9thers

Software #uality$ Software satisfies quality only when it meets to #ustomer Requirement $ #ustomer Satisfaction $ #ustomer 54pectations; &eets #ustomer Requirement refers to proper output ! #ustomer 54pectations refers to e4tra characteristics, ood interface, speed, pri-acy, security, easy to operate, ood functionality; 1on0technical reasons< #ost of product ! Time to mar3et Software #uality %ssurance$ S=A are the #oncepts to be followed by company to de-elop the software; An S=A team is responsible for &onitorin ! &easurin the stren th of de-elopin processes; Software ro&ect$ A set of problems assi ned by the client, who can be sol-ed by the software people throu h the process of software 5n ineer called Software project; %n short, the problem, the people, the process called project; Software related problem is sol-ed by software en ineers throu h software en ineer process is software project; Software Development Life Cycle ' Life Cycle Development$ Sta es in-ol-ed in software project de-elopment

') )) .) 7) 8) ?)

%nformation atherin > #ustomer requirement Analysis> #ustomer requirement -$s Solutions "esi n> "i-idin the project into modules ! couplin them #odin > Physical construction of project Testin &aintenance Information gat(ering stage$ %n this sta e, Business Analyst studies the requirement of the client $customer and they prepare Business Requirement Specification 6BRS) documents; %nalysis$ %n this sta e, Sr; Analyst prepares Software Requirement Specification 6S$w RS) document with respect to correspondin BRS document; This document consists of two sub0 documents System Requirement Specification 6SRS) ! 2unctional Requirement Specification 62RS); SRS contain details about software ! hardware requirement; 2RS contains details about the functionality to be used in project; Designing$ %n desi nin phase, "esi ners creates two documents :i h @e-el "ocument 6:@") ! @ow @e-el "ocument 6@@"); :@" consists of main modules of the project from root to leaf and multiple @@",s; @@" consists of sub0modules of main module alon with "ata flow dia rams, 5R0"ia rams, etc;, are prepared by technical support people or desi ners called %nternal desi ners; Blac3 bo4 tester should ha-e 3nowled e of customer requirement Blac3 bo4 testin tests BRS ! SRS Testin e4ternal interfacin is Blac3 bo4 testin Testin internal interfacin is (hite bo4 testin (hite bo4 testin is done w;r;t desi n documents Testing$

Testing Development
V )*DEL TESTI+G Port testing Test Software changes Test efficiency Functional system testing User acceptance testing Test documentation Design phase testing Programme phase testing

Assesment development plan Prepare Test plan Requirement phase testing &aintenance

Install uild Design ! "oding

%nformation A Test plan is de-eloped based on "e-elopment plan 2ormula for test efficiency< "R5 B A $ A C B "R5 B "efect Remo-al 5fficiency A 0D Bu s found at the testin side B 0D Bu s found at the client side "R5B E;F G E;H ood E;I G E;F requires impro-ement J E;I poor

,efinement -orm of V.)odel 2rom the abo-e refinement form of +0&odel, small ! medium scale or aniKations are maintainin separate testin team for 2unctional ! System testin sta e; /) ,eviews during %nalysis

%n eneral, Software de-elopment process starts with %nformation Gatherin ! Analysis; %n this sta e Business Analyst cate ory people are preparin BRS ! S$w RS documents and after completion documents preparation, they conduct re-iews on the documents for completeness ! correctness; This re-iew focuses on below factors< ') )) .) 7) 8) Are Are Are Are Are they they they they they complete met with ri ht requirements of client $ customer achie-able w;r;t technolo y reasonable w;r;t time ! cost testable

0) ,eviews during Design After completion of Analysis phase ! their re-iews, our Project0le-el desi ners will start lo ical desi n of application in terms of 54ternal ! %nternal desi n 6:@",s ! @@",s); %n this sta e, they conduct re-iews for completeness ! correctness of desi ned documents; This re-iew focuses on below factors<

') )) .) 7) 8)

Are they understandable Are they met with ri ht requirements of client $ customer Are they complete Are they follow able "oes they handle errors 1) During 2nit Testing

After completeness of "esi n ! their re-iews, software pro rammers will starts codin the lo ical desi n to physical construction of software; "urin these codin sta e pro rammers is conductin /nit Testin throu h a set of (hite bo4 testin techniques, /nit Testin also 3nown as &odule $ #omponent $ Pro ram $ &icro testin 3(ite 4o5 Testing$ There are three possible (hite bo4 testin techniques ') 54ecution Testin Basic path co-era e G 54ecution of all possible bloc3s in a pro ram @oops co-era e G Termination of loop statements Pro rammer technique co-era e G less no of memory cycles ! #P/ cycles )) .) 9peration Testin G Runnin the application on #ustomer e4pected platforms &utation Testin

&utation means that a chan e pro ram; (hite bo4 testers are performin the chan e in the pro ram to estimate test co-era e on that pro ram; &utation testin can decide whether the test co-era e is correct or wron 7) %nte ration Testin After completion of dependent modules of de-elopment ! testin , Pro rammers combine them to form a System; %n this %nte ration, they are conductin %nte ration testin on the compiled modules w;r;t :@"; There are three approaches to conduct %nte ration testin a) Top0"own Approach

Top.Down %pproac( %n this approach, testin is conducted on &ain module without conductin testin to some of sub0modules; 2rom the abo-e dia ram, a Stub is a temporary pro ram instead of under constructi-e sub0module, it is 3nown as called pro ram;

b)

Bottom0/p Approach

"ottom.2p %pproac( %n this approach, testin is conducted on sub0modules without conductin testin on main modules; 2rom the abo-e dia ram, a "ri-er is a temporary pro ram instead of main module, it is 3nown as callin pro ram; c) Sandwic( or 6y4rid %pproac(

Sandwic( ' 6y4rid %pproac( %n this approach, testin is conducted ta3in both Top0"own ! Bottom Approaches; A Build< A finally inte rated all modules set A;e4e form file is called build; 7) -unctional 8 System testing (9 imp)

After completion of final inte ration of modules as a system, Testin 5n ineers are plannin to conduct 2unctional ! System testin throu h Blac3 bo4 testin techniques, these techniques classified into four cate ories; ') )) .) 7) /sability Testin 2unctional Testin Performance Testin Security Testin 2rom Abo-e ' ! ) are #ore le-el and . ! 7 are Ad-ance le-el "urin "urin "urin "urin /) /sability testin , Testin team -alidates /ser02riendliness of screens; 2unctional testin , TT -alidates the correctness of customer requirements Performance testin , TT estimates speed of processin Security testin , Testin team -alidates pri-acy to /ser operations

2sa4ility Testing

%n eneral, TT starts with test e4ecution with /sability testin ; "urin test, Testin team -alidates /ser02riendliness of screens of build; "urin /sability testin , TT applies two types of sub0test< a) /ser %nterface Test

5asy of use 6/nderstandable screens) @oo3 ! 2eel 6Attracti-eness ! Pleasantness) Speed in %nterface 6@ess no of e-ent to complete a test, easy short na-i ation) b) &anual Support Test

#onte4t sensiti-eness of user manuals &anual support test are conducted at the end of all testin ! before release

0)

-unctional Testing

The major part of Blac3 bo4 testin is 2unctional testin , durin this test, Testin team' concentrates on Lmeet customer requirementsM; This 2unctional Testin is classified into below sub0test;

a)

2unctional $ Requirement Testin

"urin this test, Test 5n ineers -alidates correctness of e-ery functionality in terms of below co-era e,s; Beha-ioral co-era e 6chan es in object properties) %nput domain co-era e 6siKe ! type of e-ery input ! output object) 5rror handlin co-era e 6pre-entin ne ati-e na-i ations) #alculations co-era e 6correctness of output) Bac30end co-era e 6impact of 2ront0end operation on bac30end tables contents) Ser-ice le-els co-era e 6order of functionalities) b) %nput "omain Testin

%t is a part of 2unctionality testin > Test 5n ineers are maintainin special structures to define siKe ! type of input object c) Reco-ery Testin

%t is also 3nown as Reliability testin ; "urin this test, Testin team -alidates whether the application is chan in from abnormal state to normal state or not; d) #ompatibility Testin %t is also 3nown as Portability testin ; "urin this test, Testin team -alidates whether application build run on customer e4pected platforms or not; "urin this test, Testin 5n ineers are findin Bac3ward compatibility at ma4imum; 2orward compatibility 0D application is ready to run but 9peratin system is not supportin ; Bac3ward compatibility 0D 9peratin system is supportin but the application has some internal codin problems to run on 9peratin system e) #onfi uration Testin

%t is also 3nown as :ardware compatibility testin ; "urin this test, Testin team -alidates whether application build supports different technolo y :ardware de-ices or not; f) %nter0Systems Testin

"urin this test, Testin team -alidates whether application build co0e4istence with other e4istin software,s or not and also test whether any "ead loc3 situation occurs or not;

%nstallation Testin

"urin this test, Testin team -alidates whether application build alon with supported software,s into customers site li3e confi ured systems; "urin this test, Testin team obser-es below factors; Setup pro ram e4ecution to start installation 5asy %nterface Amount of dis3 occupied after installation h) Parallel $ #omparati-e Testin

"urin this test, Testin team compares application build with competiti-e products in mar3et; i) Sanitation $ Garba e Testin

"urin this test, Testin team tries to find e4tra features in application build w;r;t customer requirements; A "efects "urin this test, Testin team reports defects to de-elopers in terms of below cate ories '; &ismatches between e4pected ! actual ); &issin functionality .; 54tra functionality w;r;t customer requirement A &anual -$s Automation

A Tester conducts any test on application build without usin any testin tool is called &anual testin , if any testin tool is used then it is called Automation testin %n common testin process, Testin 5n ineers are usin test Automation w;r;t test impact ! criticality; %mpact 0D test repetition ! #riticality 0D comple4 to apply test manually; "ue to these two reasons testin people are usin test Automation; j) Re0testin

The re0e4ecution of a test with multiple test data to -alidate a function, e; ; To -alidate multiplication, Test 5n ineers use different combinations of input in terms of min, ma4, 0-e, C-e, Kero, int, float, etc; 3) Re ression Testin

The re0e4ecution of test on modified build to ensure bu fi4in wor3 ! occurrence of any side effects, Test 5n ineers conducts this test usin Automation l) 5rror, "efect ! Bu

A mista3e in code is 5rror, due to errors in codin , Test 5n ineers are ettin mismatches in application build are defects, if the defects are accepted by de-elopers to be sol-es then it is Bu ;

Testing Documents

Abo-e 2i ure, shows the -arious le-els of documents prepared at project testin ; Test Policy is documented by =uality #ontrol; Test Strate y ! Test &ethodolo y are documented by =uality Analyst or Project &ana er; Test Plan, Test #ases, Test Procedure, Test Script ! "efect Report are documented by =uality Assurance 5n ineers or Test 5n ineers; Test Policy ! Test Strate y are #ompany @e-el "ocuments; Test &ethodolo y, Test Plan, Test #ases, Test Procedure, Test Script, "efect Report ! 2inal Test Summary Report are Project @e-el "ocuments; /) TEST *LIC:$

This document de-eloped by =uality #ontrol people 6&ana ement); %n this document =uality #ontrol defines LTestin 9bjecti-eM; Test olicy Document

%ddress of t(e Company

Test Definition Testing rocess

$ $ $

+erification ! +alidation Proper plannin before starts testin 9ne defect per )8E lines of code or 'E 2P 62unctional points) =A&, TT&, P#&

Testing Standards

Testing )easurements $

AAAAAAA ) =A&< =uality Assurance &easurements, how much quality is e4pected TT&< Testin Team &easurements, how much testin is o-er ! is yet to complete

6#;5;9

P#&< Process #apability &easurements, depends on old project to the upcomin projects;

0)

TEST ST,%TEG:$

This is a #ompany le-el document ! de-eloped by =uality Analyst or Project &ana er #ate ory people, it defines LTestin ApproachM; Components a) b) c) d) e) f) Scope ! 9bjecti-e< "efinition ! purpose of testin in or aniKation Business %ssue< Bud et control for testin Test Approach< &appin between de-elopment sta es ! Testin %ssue; Test "eli-erables< Required testin documents to be prepared Roles ! Responsibilities< 1ames of the job in testin team ! their responsibilities #ommunication ! Status reportin < Required ne otiation between testin team ! de-elopin team durin test e4ecution ) Automation ! Testin Tools< Purpose of automation ! possibilities to o to test automation h) Testin &easurements ! &etrics< =A&, TT&, P#& i) Ris3s ! &iti ation< Possible problems will come in testin ! solutions to o-ercome j) #han e ! #onfi uration &ana ement< To handle chan e request durin testin 3) Trainin Plan< Required trainin sessions to testin team before start testin process Testing Issues '; ); .; 7; 8; ?; I; F; AuthoriKation< (hether user is -alid or not to connect to application Access #ontrol< (hether a -alid user ha-e permission to use specific ser-ice Audit Trail< &aintains metadata about user operation in our application #ontinuity of Processin < %nter0process communication #orrectness< &eet customer requirement in terms of functionality #ouplin < #o0e4istence with other e4istence software to share resources 5ase of /se< /ser 2riendliness of the screens 5ase of 9perator< %nstallation, /n0installations, "umpin , /ploadin , "ownloadin , etc;, H; 2ile %nte rity< #reation of bac3up 'E; Reliability< Reco-er from abnormal state ''; Performance< Speed of processin '); Portable< Run on different platforms '.; Ser-ice le-els< 9rder of functionalities '7; &aintainable< (hether our application build is lon term ser-iceable to our customer '8; &ethodolo y< (hether our tester are followin standards or not durin testin 1) TEST )ET6*D*L*G:$ %t is project le-el document; &ethodolo y pro-ides required testin approach to be followed for current project; %n this le-el =uality Analyst select possible approach for correspondin project testin ; et rocess$

Process in-ol-es e4perts, tools ! techniques; %t is a refinement form of +0&odel; %t defines mappin between de-elopment ! Testin sta es; 2rom this model, 9r aniKations are maintainin separate team for 2unctional ! System testin ! remainin sta es of

testin done by de-elopment people; This model is de-eloped in :#@ ! reco niKed by =A 2orum of %1"%A;

7)

TEST

L%++I+G$

After finaliKation of possible test for current project, Test @ead cate ory people concentration on test plan document preparation to define wor3 allocation in terms of (hat, (ho, (hen ! :ow to test; To prepare test plan document, test plan order follows below approach>

/;

Team -ormation$

%n eneral, Test plannin process starts with testin team formation; To define a testin team, test plan author depends on below factors> '; ); .; A-ailability of testers Test duration A-ailability of test en-ironment resource 0; Identify Tactical ,is<$

After Testin team formation Plan author analysis possible ! miti ation 6ad hoc testin ) N Ris3 '< @ac3 of 3nowled e of Test 5n ineer on that domain N Soln '< 54tra trainin to Test 5n ineers N Ris3 )< @ac3 of Resource

N Ris3 .< @ac3 of bud et Oless no of timeP N Soln .< %ncrease Team siKe N Ris3 7< @ac3 of Test data N Soln 7< #onduct test on past e4perience basis i;e;, ad hoc testin or contact client for data N Ris3 8< @ac3 of de-eloper process ri or N Soln 8< Report to Test @ead for further communication between test ! de-elopment P& N Ris3 ?< "elay of modified build deli-ery N Soln ?< 54tra hours of wor3 is needed N Ris3 I< @ac3 of communication in between Test 5n ineer 0 D Test team and Test team 0 D "e-elopment team L%+$

1;

,E %,E TEST

After completion of testin team formation ! Ris3 analysis, Test plan author concentrate on Test lan Document in %555 format; E') E)) E.) E7) E8) Test Plan %"< /nique 1o or 1ame e; ; STP0AT& %ntroduction< About Project description Test %tems< &odules $ 2unctions $ Ser-ices $ 2eatures $ etc; 2eatures to be tested< Responsible &odules for Test desi n 6preparin test cases for added modules) 2eatures not to be tested< (hich feature is not to be tested and (hyQ 6"ue to test cases a-ailable for the old modules, so for these modules no need to be tested $ no test case

!"o#e $%)& $') ( $)) decides *hich module to "e tested + , -hat to test. E?) EI) EF) EH) 'E) type '') Approach< @ist of selected testin techniques to be applied on abo-e specified modules in reference to the TR&6Test Responsible &atri4); 2eature pass or fail criteria< (hen a feature is pass or fail description 65n-ironment is ood) 6After testin conclusion) Suspension criteria< Possible abnormal situations rose durin abo-e features testin 65n-ironment is not ood) 6"urin testin conclusion) Test 5n-ironment< Required software ! :ardware to be tested on abo-e features Test "eli-erables< Required testin document to be prepared 6durin testin , the Testin Tas3< of documents are prepared by tester) 1ecessary tas3s to do before start e-ery feature testin

!"o#e $/) to $00) specifies 1, 2o* to test. ')) '.) '7) Staff ! Trainin < 1ames of selected Test 5n ineers ! trainin requirements to them Responsibilities< (or3 allocation to e-ery member in the team 6dependable modules are i-en to sin le Test 5n ineer) Schedule< "ates ! Times of testin modules

!"o#e $') specifies 1, -hen to test. '8) '?) 7) @ist ! &iti ation< Possible testin le-el ris3s ! solution to o-ercome them Appro-als< Si natures of Test plan authors ! Project &ana er $ =uality Analyst ,eview Test lan$

After completion of plan document preparation, Test plan author conducts a re-iew of completion ! correctness; %n this re-iew, Plan author follows below co-era e analysis BRS based co-era e 6(hat to testQ Re-iew) Ris3s based co-era e 6(hen ! (ho to testQ Re-iew) TR& based co-era e 6:ow to testQ Re-iew) =) TEST DESIG+I+G$

After completion of Test Plannin ! required trainin to testin team, correspondin testin team members will start preparin the list of test cases for their responsible

modules; There are three types of test cases desi n methods to co-er core le-el testin 6/sability ! 2unctionality testin ); a# $# c# Business @o ic based test case desi n 6S$w RS) %nput "omain based test case desi n 650R dia rams $ "ata &odels) /ser %nterface based test case desi n 6&S0(indows rules) a) "usiness Logic 4ased Test Case design (S'w ,S)

%n eneral, Test 5n ineers are preparin a set of Test #ases depends on /se #ases in 6S$w RS); 5-ery /se #ase describes a functionality in terms of inputs, process ! output, depends on this /se #ases Test 5n ineers are preparin Test #ases to -alidate the functionality

2rom the abo-e model, Test 5n ineers are preparin Test #ases depends on correspondin /se #ases ! e-ery test case defines a test condition to be applied; To prepare test cases, Test 5n ineers studies /se #ases in below approach< Steps< ') #ollect /se #ases of our responsible module )) Select a /se #ase ! their dependencies from the list );') %dentify entry condition 6Base state) );)) %dentify input required 6Test data) );.) %dentify e4it condition 65nd state) );7) %dentify output ! outcome 654pected) );8) %dentify normal flow 61a-i ation) );?) %dentify alternati-e flows ! e4ceptions .) 7) 8) (rite Test #ases depends on abo-e information Re-iew Test #ases for the completeness ! correctness Goto step 6)) until completion of all /se #ases completion

/se #ase %< A lo in process allows user id ! password to -alidate users; "urin these -alidations, lo in process allows user id in alpha0numeric from 7 to '? characters lon ! password in alphabets in lowercase from 7 to F characters lon ; #ase study< Test #ase ') B+A 6SiKe) Successful entry of user id

min min0' minC'

0D 7 chars BD 0D . chars BD 0D 8 chars BD

pass fail pass

ma40' ma4C' ma4

0D '8 chars 0D 'I chars 0D '? chars 5#P

BD BD BD

pass fail pass

+alid

%n-alid

a0K A0R E0H

special chars blan3

Test #ase 2ormat< "urin Test desi n Test 5n ineers are writin list of Test #ases in %555 format; E') E)) E.) E7) E8) Test #ase %"< /nique no or name Test #ase 1ame< 1ame of test condition to be tested 2eature to be tested< &odule $ 2unction $ 2eature Test suit %"< Batch %", in which this case is member Priority< %mportance of Test #ase O@ow, &ed, :i hP PE 0D Basic functionality P' 0D General functionality 6%$P domain, 5rror handlin , #ompatibility etc,) P) 0D #osmetic testin 6/%T) E?) EI) EF) EH) 'E) Test Test Test Test Test 5n-ironment< Required Software ! :ardware to e4ecute afford 6person $ hr)< Time to e4ecute this Test #ase e; ; )E minutes duration< "ate ! Time Setup< Required testin tas3 to do before starts case e4ecution 6pre0requisites) Procedure< Step by step procedure to e4ecute Test #ase

Test Procedure 2ormat<

))

') Step 1o< Action<

0D Test "esi n

.) 7)

%nput required< 54pected< 8) Actual<

?) I)

Result< #omments<

0D Test 54ecution

'')

Test #ase passes or fails criteria< (hen this case is pass or fail Test 5n ineers follows list of Test #ases alon with step by step procedures only

1ote<

54ample '< Prepare Test Procedure for below test cases LSuccessful file sa-e operation in 1otepad L; Ste p +o ' ) . 7 %ction Input ,e>uired E5pected

9pen 1otepad 2ill with te4t #lic3 Sa-e %con or clic3 2ile menu 9ption ! select sa-e option 5nter 2ile name ! #lic3 Sa-e

/nique 2ile name

5mpty 5ditor Sa-e %con enabled Sa-e "ialo bo4 appears with "efault file name 2ocus to 1otepad ! 2ile name Appears in title bar of 1otepad

+ote$ -or more e5amples refer to notes 4) Input Domain 4ased Test Case design (E., diagrams ' Data )odels)

%n eneral, Test 5n ineers are preparin ma4imum Test #ases depends on /se #ases or functional requirements in S$wRS; These functional specifications pro-ide functional descriptions with input, output ! process, but they are not responsible to pro-ide information about siKe ! type of input objects; To correct this type of information, Test 5n ineers study "ata model of responsible modules 50R dia ram; "urin "ata model study, Test 5n ineer follows below approach< Steps< ') )) .) 7) 8) #ollect "ata model of responsible modules Study e-ery input attribute in terms of siKe, type ! constraint %dentify critical attributes in the test, which is participated in manipulation ! retri-als %dentify non0critical attributes such as input ! output type Prepare B+A ! 5#P for e-ery input object

Input %ttri4ute S444 L L L

EC Valid

"V%(Si?e ' ,ange) Invalid )inimum )a5imum 4444 L L L 4444 L L L

4444 4444 L L L L L L D%T% )%T,I!

1ote< %n eneral, Test 5n ineers are preparin step by step procedure based Test #ases for functionality testin ; Test 5n ineers prepare -alid $ in-alid table based Test #ases for input domain of object testin O"ata &atri4 P +ote$-ore5amplereferto notes c) 2ser Interface 4ased test case design ()S.3indows rules) To conduct /sability Testin , Test 5n ineers are preparin list of Test #ases depends on our or aniKation /ser %nterface standards or con-entions, Global /ser %nterface rules ! interest of customer site people; 54ample< Test #ases ') )) .) 7) 8) in Spellin chec3 Graphics chec3 6Screen le-el Ali n, 2ont style, #olor, SiKe ! &icrosoft si4 rules) &eanin of error messa es Accuracy of data displayed Accuracy of data in the database are result of user inputs, if de-eloper restrict the data database le-el by roundin $ truncatin then the de-eloper must also restrict the data in

front0end as well ?) Accuracy of data in the database as the result of e4ternal factors; 54; 2ile attachments I) &eanin ful help messa es 6&anual support testin ) Re-iew Test #ases< After completion of all possible Test #ases preparation for responsible modules, Testin team concentrates on re-iew of Test #ases for completeness ! correctness; %n this re-iew, Testin team applies co-era e analysis; Test #ase Re-iew ') )) .) 7) 8) BR based co-era e /se #ases based co-era e "ata model based co-era e /ser %nterface based co-era e TR& based co-era e

At the end of this re-iew, Test @ead prepare Requirement Traceability &atri4 or Requirement +alidation &atri4 6RT& $ R+&)

Business Requirement Source 6/se #ases, "ata model) Test #ases 2rom RT& $ R+& model, it defines mappin between customer requirement ! prepared Test #ases to -alidate the requirement; @) TEST E!EC2TI*+$

After completion of Test #ases selections ! their re-iew, Testin team concentrate on Build release from de-elopment side ! Test e4ecution on that build; a) Test E5ecution Levels or (ases$ See fi ure in ne4t pa e for clear understandability of this le-els 4) Test E5ecution Levels v's Test Cases$ @e-el G E 0D PE @e-el G ' 0D All PE, P' @e-el G ) 0D Selected @e-el G . 0D Selected Test #ases ! P) Test #ases as batches PE, P', ! P) w;r;t modification PE, P', ! P) w;r;t critical areas in the master build

%) Test E5ecution Levels or

(ases$

Defect Report %evel & ) "omprehensive

%evel & ' Final Regression

%evel & ( Regression

Defect Fi+ing

c) "uild Version Control$ %n eneral, Testin 5n ineers are recei-in build from de-elopment in below model

Testers
uild

Testing Environment

FTP *file transport Protocol#

Server

"urin Test e4ecution Test 5n ineer are recei-in modified build from software; To distin uish old ! new builds, de-elopment team maintains unique -ersion in system, which is understandable to Tester $ Testin team; 2or this -ersion controllin de-elopers are usin -ersion control tools 6+isual Source Safe)

d)

Level A B (Sanity ' Test %cceptance ' "uild verification test)$

After recei-in initial build, Testin 5n ineers concentrate on basic functionality of that build to estimate stability for complete testin ; %n this Sanity testin , Testin 5n ineers tries to e4ecute all PE Test #ases to co-er basis functionality; %f functionality is not wor3in $ functionality missin , Testin team rejects that build; %f Tester decided stability then they concentrate on Test e4ecution of all Test #ases to detect defects; "urin this Sanity testin , Testin 5n ineer obser-es below factors on that build ') )) .) 7) 8) ?) I) F) /nderstandable 9peratable 9bser-able #onsistency #ontrollable Simplicity &aintainable Automation 2rom the abo-e LFM testable issues, Sanity test is also 3nown as Testability testin $ 9#T an le testin ; e) Test %utomation$

%f test automation is possible than Testin team concentrate on Test script creation usin correspondin testin tools; 5-ery Test script consists of na-i ation statement alon with required chec3 points; Stable Build

Test Automation 6Select Automation)

6All PE ! #arefully selected P' Test #ases) f) Level A / (Compre(ensive testing)

After completion of Sanity testin ! possible test automation, Testin team concentrates on test batches formation with depended Test #ases; Test batches are also 3nown as Test suits $ sets; "urin these Test batches e4ecution, Test 5n ineers prepare test lo document, this document consist of three types of entries; ') )) .) Passed 654pected B Actual) 2ailed 6Any one 54pected TB Actual, Any one 54pected -ariants from Actual) Bloc3ed 6#orrespondin parent functionality failed)

g)

Level A 0 (,egression testing)

"urin #omprehensi-e test e4ecution, Test 5n ineers are reportin mismatches as defects to de-elopers; After recei-in modified build from de-elopers, Test 5n ineers concentrate on Re ression testin to ensure bu 0fi4in wor3 ! occurrences of side effects; #ase %< %f de-elopment team resol-e bu s se-erity which is hi h, Test 5n ineers re0e4ecute all PE, P' ! carefully selected P) Test #ases on modified build #ase %%< Bu s se-erity is medium, then all PE, carefully selected P' ! some of P) Test #ases #ase %%%< Bu s se-erity is low, then some PE, P' ! P) #ase %+< %f de-elopment team released modified build due to sudden chan es in project requirement then Test 5n ineers re0e4ecute all PE, P' ! carefully selected P) Test #ases w;r;t that requirement modification; () Level A 1 (-inal ,egression ' C) TEST ,E *,TI+G$ re.%cceptance testing)

"urin comprehensi-e testin , Test 5n ineer are reportin mismatches as defects to de-elopers throu h %555 format; ') )) .) 7) 8) ?) I) F) H) 'E) '') ')) '.) '7) '8) "efect %"< /nique 1o or 1ame "escription< Summary of the defect 2eature< &odule $ 2unction $ Ser-ice , in these module T5 found the defect Test #ase 1ame< #orrespondin failin test condition Reproducible 6Ues $ 1o)< Ues 0D 5-ery time defect appears durin test e4ecution 1o 0D Rarely defect appears %f Ues, attach test procedure< %f 1o, attach snapshot ! stron reasons< Status< 1ew $ Reopen Se-erity< Seriousness of defect w;r;t functionality 6hi h $ medium $ low) Priority< %mportance of the defect w;r;t customers 6hi h $ medium $ low) Reported bu < 1ame of Test 5n ineer Reported on< "ate of submission Assi n to< 1ame of the responsible person in de-elopment team 0D P& Build +ersion %"< %n which build, Test 5n ineer fount the defect Su ested fi4 69ptional)< Tester tries to produce su estion to sol-e this defect

'? 2i4ed by< P& or Team @ead 'I) Resol-ed by< "e-eloper name

'F) Resol-ed on< "ate of sol-in 'H) Resolution type< chec3 out in ne4t pa e )E) Appro-ed by< Si nature of Project &ana er 6P&) "efect A e< The time ap between Lreported onM ! Lresol-ed onM "efect submission process< "efect Status #ycle< 1ew 9pen $ rejected $ deferred close reopen

"y Developers

deferred BD Accepted but not interested to resol-e in this -ersion "efect Resolution< After recei-in defect report from Testers, de-elopers re-iew the defect ! they send resolution type to Tester as a reply E') E)) E.) E7) E8) E?) EI) EF) EH) 'E) '') ')) "uplicate, rejected due to the defect is same as pre-iously reported defect 5nhancement, rejected due to the defect is related future requirement of customer :$w limitation, rejected due to the defect raised w;r;t limitation of :$w de-ices S$w limitations, rejected due to the defect raised w;r;t limitation of S$w Techno 1ot applicable, rejected due to the defect has no proper meanin 2unctions as desi ned, rejected due to codin is correct w;r;t to desi ned doc,s 1eed more information, not 6accepted $ rejected) but de-elopers requires e4tra information to understand the defect 1ot reproducible, not 6accepted $ rejected) but de-elopers require correct procedure to reproduce the defect 1o plan to fi4 it, not 6accepted $ rejected) but de-elopers want e4tra time to fi4 2i4ed, de-elopers accepted to resol-e 2i4ed indirectly, accepted but not interested to resol-e in this -ersion 6default) /ser misunderstandin , need e4tra ne otiation between testin ! de-elopment team; Types of defects< E') /ser %nterface bu s 6low se-erity)< ') Spellin mista3es 6hi h priority) )) %mproper ali nment 6low priority) E)) Boundary related bu s 6medium se-erity) ') "oesn,t allows -alid type 6hi h priority) )) Allows in-alid type also 6low priority) E.) 5rror handlin bu s 6medium se-erity) ') "oesn,t pro-idin error messa e window 6hi h priority) )) %mproper meanin of error messa e 6low priority) E7) #alculations bu s 6hi h se-erity) ') 2inal output is wron 6low priority)

)) "ependent results are wron 6hi h priority) E8) Race condition bu s 6hi h se-erity) ') "ead loc3 6hi h priority) )) %mproper order of ser-ices 6low priority) E?) @oad conditions bu s 6hi h se-erity) ') "oesn,t allow multiple users to access $ operate 6hi h priority) )) "oesn,t allow customers accepted load 6low priority) EI) :ardware bu s 6hi h se-erity) ') "oesn,t handle de-ice 6hi h priority) )) (ron output from de-ice 6low priority) EF) %" control bu s 6medium se-erity) ') @o o missin , wron lo o, +ersion 1o mista3e, #opyri ht window missin , "e-elopers 1ame missin , Tester 1ame missin EH) +ersion control bu s 6medium se-erity) ') "ifferences between two consecuti-e build -ersions 'E) Source bu s 6medium se-erity) ') &ista3e in help documents G &anual support D) TEST CL*S2,E$

After completion of all possible test cycle e4ecution, Test @ead conducts a re-iew to estimate the completeness ! correctness of testin ; %n this re-iew, Test @ead follows below factors with Test 5n ineers ') #o-era e Analysis a) b) c) d) e) BR based co-era e /se #ases based co-era e "ata model based co-era e /ser %nterface based co-era e TR& based co-era e )) Bu density a) b) c) d) &odule A has )EV percentile bu &odule B has )EV percentile bu &odule # has 7EV percentile bu &odule " has )EV percentile bu .) Analysis of deferred bu s (hether deferred bu s are deferrable or not At the end of this re-iew, Testin team concentrate on hi h bu density modules or all modules if time is a-ailable; s found s found s found s found

E)

2ser %cceptance Testing (2%T)

9r aniKation mana ement concentrate on /AT to collect feedbac3, there are two approaches to conduct testin ; '; Alpha 6W) test ); Beta 6X) test /B) Sign *ff After completion of /ser Acceptance testin ! their modifications, Test @ead concentrates on final test summary report creation; %t is a part of Software Release 1ode 6S$w R1); This final test summary report consist of below documents ') )) .) 7) 8) Test Strate y $ &ethodolo y 6TR&) System Test Plan Requirement Traceability &atri4 6RT&) Automated Test Scripts Bu s Summary Reports The below, has to be in horiKontal direction Bu "escription 2eature 2ound By Status 6closed $ deferred) #omments C%SE ST2D: *+ % ,*FECT TESTI+G ,*CESS

The L S M is a client$ser-er product; %t is runnin in sin le computer with windows )EEE as 9S this product pro-ides a facility to search matched records in e4istin database; w;r;t has i-en search 3eys; @ocal host

This product maintains a default administrator to create new users and e-ery -alid user search data in database; Acti-ity flow dia ram< 0

Admin

Admin %n-alid

69r) +alid user

user

Search 3eys

54istin "B

2/1#T%91A@ P9%1TS< 0 @o in is ta3in user id and password /ser id and password allows alphabets in lower case from 7 to F characters lon ; 1ew user id,s created by administrators only 1ew user creation windows allows unique user id and password with create and cancel buttons LSearch recordsM opened for -alid users only LSearch records windowM maintains below search 3eys #ustomer id< ? di its number 6collected from desi n document 2irst name< one character in upper or lower @ast name< one to ei ht characters in lower case characters "ate of birth< ddYmmYyy in numeric A e< LfromM and LtoM in numeric Search records windows allows below combination of fields to search records; @ast name @ast with first name @ast name with first name and d0o0b @ast name with first name and a e #ustomer id only

LSearch recordsM window consists of Lstart searchM and Lstop searchM buttons; Allows last name as full or partial

Allows customer id as full or partial with A or wild card #ustomer id

(,-.//// /
) F ? A 000000

Refresh search records window usin AltCctrl "isplay matched records in a pop0up window with o3 button after search completion; Returns messa e li3e Ltoo many matches to display when matched records D'EEE Test methodolo y<0 6by P&) Testin sta e Testin 2actors AuthoriKation Access #ontrol Audit trail #ontinuity to #orrectness #ouplin "ata inte rity 5ase of use 5ase of operate Reliability 2ortable Performance Ser-ice le-els &aintainable &ethodolo y 1ote< Test responsibility matri4 for %%S% 6'' by ') System testin Z Z [ Z Z [ Z Z Z Z [ [ Z Z Z

LSM product is maintainin metadata so it is not sharin resources of other application This application went to run on windows )EEE %t is a stand alone application 6at time one user can operate) So need net to test load and stress testin ) System test plan by test lead<0 '; Test plan %"< STP\S ); %ntroduction< LSM is a product and it pro-ides a facility to connect to e4istin data base and search matchin records to retrie-e; '0 Test items user creation @o in by user Search records

10 2eatures to be tested< user creation @o in by user Search records 8; 2eatures not to be tested<0 ?; Approach< To apply P& selected ' factors from TR&, below blac3 bo4 testin techniques are suitable to follow depends on test lead; /ser interface testin &anual support testin 2unctionality testin i$p domain testin Reco-ery testin Sanitation testin %nstallation testin Security testin #omplaints testin I; 5ntry criteria< 0 Are the necessary documents a-ailableQ %s the LSM product is ready for release from de-elopersQ %s the supportin database a-ailable to search required recordsQ %s the test en-ironment readyQ

F; Suspension criteria< "ata base disconnect may require suspension of testin Suspension of testin is mandatory when searchin records process went to infinite; Admin is failed to new user creation, a decision can be mad to continue testin on Lsearchin recordsM module usin admin or other e4istin -alid users; H; 54it #riteria< 0 5nsure that the LSM product pro-ides the required ser-ices 5nsure that all test documents has been completed up to date; All hi h se-erity bu s resol-ed;

'E; Test deli-erables<0 Test cases Test procedures Automated Test scripts Test lo "efect Report

Test 5n

;;

''; Test en-ironment<0 #lient pc or local host 9S< (in)EEE "B ser-er< 9RA#@5$ S=@ S5R+5R$ &S0A##5SS #onnecti-ity< "S1$ Thin "ri-ers '); Testin Tas3s<0 A-ailability of admin with password "atabase consists of records +alid users are able to database to search records

'.; Staff and Trainin needs<0 Test 5n ;; $ =A 5n < ]uru onda Srinaiah '7; Responsibilities< "ocument $ Report

Responsibility ];Srinaiah ] Srinaiah Test @ead with ] Srinaiah

') hours

5ffort

'; Tst cases with procedures "efect Report Test completion reports

e-ery day durin Testin At the end of the Testin

'8; Schedule< Tas3 date Test desi n %mplement test and Re-iew 54ecute test 5-aluate test

5ffort

Start date

5nd

') hours 7 hours )7 hours F hours

)F0')0)EE8 )H0')0)EE8 .E0')0)EE8 E)0E'0)EE?

)H0')0)EE8 )H0')0)EE8 E'0E'0)EE? E)0E'0)EE?

'?; Ris3s and miti ations<0 '; @ac3 of documentation< #ontact business analyst Ad0hoc testin #ontact customer site people if possible ); @ac3 of time 9-er0time .; "elays and deli-ery< 9-er time 7; @ac3 of de-elopment process re ur< #ontact test lead to moti-ate de-elopers 9-er time to complete tas3 is ri ht time 'I; APPR9+A@S< 0 Test case '< Si nature of P& and si nature of test lead; Test case )< Successful entry of user id

B+A 6siKe) &in B 7 chars pass &a4 B F chars pass &in0' B. chars fail &in C' B 8 chars pass &a4 G' B I chars pass &a4 C' B H chars fail Test case .< successful entry of password B+A 6siKe) &in B 7 chars pass &a4 B F chars pass &in G' B . chars fail &in C' B 8 chars pass &a4 C B I chars pass &a4 B H chars fail Test case 7< successful lo in operation /ser id Admin Admin 9ther -alid 9ther -alid 9ther in-alid Blan3 +alid Password -alid in-alid -alid in-alid in-alid -alue blan3 #riteria pass fail pass fail fail fail fail

Test case 8< Successful selection of new user creation option Test case ?< /n successful selection of this option due to current user is not admin; Test case I successful entry of user id in create user window

1ote< 6li3e as Test case)) Test case F< Successful entry of userid in create user window

1ote< 600000000000test case .) Test caseH< Successful creation of new user by admin Test case'E< unsuccessful new user creation due to i-en user id is not unique; Test case ''< successful closin of new user creation window usin cancel 6After enter user id and offer enter passes)

Test case ')< Successful selection of search records option Test case '.< successful entry of customer id B+A 6siKe) &in B ma4 B ? 5#P 6TUP5) -alid in-alid 00000000000000000000000000 E G H a0K, A0R, special characters 54pect A , blan3 space Start with A 54p< '). GH 901IH /A).S

Test case '7< successful entry of first name &in B ma4 B ' pass o Z fail a0 K A0R o0H, special characters 5cp 000000000000000000000000000 -alid in-alid 0000000000000000000000000000

Test case '8< successful entry of last name< &in B ' and ma4 B F pass

0000000000000000 -alid in-alid 00000000000000000

a0 K A0R, o0H, Special characters Test case '?< successful entry of "9B B+A 6ran e) 5cp 6type) 00000000000000000 -alid in-alid 00000000000000000 special characters

"ay< min E' min .' E0 H a0K, A0R &onth< min E' ma4 ') Uear< min EE ma4 HH #ase 'I< success entry of a e from

min E' ma4 ))

5cp6type) 00000000000000000 -alid in-alid

E0 H

a0K, A0R

00000000000000000

Special characters Test case 'F< successful entry of a e to 1ote< li3e as abo-e Test case 'H< successful display of matched records with full last name and all other fields are Blan3 Test case )E< successful display of matched records with full last name and first name Test case)'< successful display of matched records with full last name first name and dob Test case))< successful display of matched records with full last name first name a e Test case ).< on successful search operation due to in-alid combination of filled fields; Test case )7< unsuccessful search operation due to in-alid "ob Test case )8< unsuccessful search operation due to a e from reater than a e *To, Test case)?< successful display of records with search 3ey as partial last name and other fields as blan3 Test case )I<successful display of records with search 3ey a partial last name and first name Test case )F< successful display of records with search 3ey as partial last name, first name and "ob Test case )H< successful display of records with search 3ey as partial last name, first name Test case .E< successful display of records with search 3ey as customer id Test case .'< successful display of records with search 3ey as partial customer id with A as wild card Test case .)< /nsuccessful display of records due to no matchin records in database w;r;to i-en search 3eys Test case ..< unsuccessful display of records due to Ltoo manyM records to display when no of matched records reater than 'EEE Test case .7 < successful refresh search window with Alt C#trl

Test case .8< Successful termination of search operation when clic3 Lstop searchM button; Test case .?< successful closin of records window throu h clic3 o;3 after searchin ; Test case .I< spellin chec3 in e-ery screen Test case .F< Graphics chec3 in e-ery screen 54< 6ali nment, font, siKe, label, raphical, colour, etc) /sability Testin Test case.H< Accuracy of data displayed 54<"ob ddYmmYyy Test case 7E< &eaninful help messa es and error messa es