Manual Testing Process : Process is a roadmap to develop the project is consists a number of sequential steps.

Software Testing Life Cycle: Test Plan Test Development Test Execution Analyse Results Defect Trac in! "ummarise Report Test Plan : #t is a document $hich describes the testin! environment% purpose% scope% objectives% test strate!y% schedules% mile stones% testin! tool% roles and responsibilities% ris s% trainin!% staffin! and $ho is !oin! to test the application% $hat type of tests should be performed and ho$ it $ill trac the defects. Test Development : Preparin! test cases Preparin! test data Preparin! test procedure Preparin! test scenario &ritin! test script Test Execution : #n this phase $e execute the documents those are prepared in test development phase. Analyse result : 'nce executed documents $ill !et results either pass or fail. $e need to analyse the results durin! this phase. Defect Tracking : &hen ever $e !et defect on the application $e need to prepare the bu! report file and for$ards to Test Team (ead and Dev Team. The Dev Team $ill fix the bu!. A!ain $e have to test the application. This cycle repeats till $e !et the soft$are $ith our defects.

Summarise eports : Test Reports )u! Reports Test Documentation ********************* *** ************** ********************* **** ******************************** Test Plan : Test Plan Template: +,ame of the ProductPrepare! "y: +,ames of Preparers+DateTA#LE $% C$&TE&TS ../ #,TR'D01T#', 2./ ')3E1T#4E" A,D TA"5" 2.. 'bjectives 2.2 Tas s 6./ "1'PE 7./ Testin! "trate!y 7.. Alpha Testin! +0nit Testin!7.2 "ystem and #nte!ration Testin! 7.6 Performance and "tress Testin! 7.7 0ser Acceptance Testin! 7.8 )atch Testin! 7.9 Automated Re!ression Testin! 7.: )eta Testin! 8./ ;ard$are Requirements 9./ Environment Requirements 9.. <ain =rame 9.2 &or station :./ Test "chedule >./ 1ontrol Procedures ?./ =eatures to )e Tested ././ =eatures ,ot to )e Tested .../ Resources@Roles A Responsibilities .2./ "chedules .6./ "i!nificantly #mpacted Departments +"#Ds.7./ Dependencies .8./ Ris s@Assumptions .9./ Tools .:./ Approvals '() *&T $D+CT*$& A brief summary of the product bein! tested. 'utline all the functions at a hi!h level.

,() $#-ECT*.ES A&D TAS/S ,(' $"0ectives Describe the objectives supported by the <aster Test Plan% e!.% definin! tas s and responsibilities% vehicle for communication% document to be used as a service level a!reement% etc. ,(, Tasks (ist all tas s identified by this Test Plan% i.e.% testin!% post*testin!% problem reportin!% etc. 1() SC$PE 2eneral This section describes $hat is bein! tested% such as all the functions of a specific product% its existin! interfaces% inte!ration of all functions. Tactics (ist here ho$ you $ill accomplish the items that you have listed in the B"copeB section. =or example% if you have mentioned that you $ill be testin! the existin! interfaces% $hat $ould be the procedures you $ould follo$ to notify the ey people to represent their respective areas% as $ell as allottin! time in their schedule for assistin! you in accomplishin! your activityC 3() TEST*&2 ST ATE24 Describe the overall approach to testin!. =or each major !roup of features or feature combinations% specify the approach $hich $ill ensure that these feature !roups are adequately tested. "pecify the major activities% techniques% and tools $hich are used to test the desi!nated !roups of features. The approach should be described in sufficient detail to permit identification of the major testin! tas s and estimation of the time required to do each one. 3(' +nit Testing Definition: "pecify the minimum de!ree of comprehensiveness desired. #dentify the techniques $hich $ill be used to jud!e the comprehensiveness of the testin! effort +for example% determinin! $hich statements have been executed at least once-. "pecify any additional completion criteria +for example% error frequency-. The techniques to be used to trace requirements should be specified. Participants: (ist the names of individuals@departments $ho $ould be responsible for 0nit Testin!. Met5o!ology: Describe ho$ unit testin! $ill be conducted. &ho $ill $rite the test scripts for the unit testin!% $hat $ould be the sequence of events of 0nit Testin! and ho$ $ill the testin! activity ta e placeC 3(, System an! *ntegration Testing Definition: (ist $hat is your understandin! of "ystem and #nte!ration Testin! for your project. Participants: &ho $ill be conductin! "ystem and #nte!ration Testin! on your projectC (ist the individuals that $ill be responsible for this activity. Met5o!ology: Describe ho$ "ystem A #nte!ration testin! $ill be conducted. &ho $ill $rite the test scripts for the unit testin!% $hat $ould be sequence of events of "ystem A #nte!ration

Testin!% and ho$ $ill the testin! activity ta e placeC 3(1 Performance an! Stress Testing Definition: (ist $hat is your understandin! of "tress Testin! for your project. Participants: &ho $ill be conductin! "tress Testin! on your projectC (ist the individuals that $ill be responsible for this activity. Met5o!ology: Describe ho$ Performance A "tress testin! $ill be conducted. &ho $ill $rite the test scripts for the testin!% $hat $ould be sequence of events of Performance A "tress Testin!% and ho$ $ill the testin! activity ta e placeC 3(3 +ser Acceptance Testing Definition: The purpose of acceptance test is to confirm that the system is ready for operational use. Durin! acceptance test% end*users +customers- of the system compare the system to its initial requirements. Participants: &ho $ill be responsible for 0ser Acceptance Testin!C (ist the individualsD names and responsibility. Met5o!ology: Describe ho$ the 0ser Acceptance testin! $ill be conducted. &ho $ill $rite the test scripts for the testin!% $hat $ould be sequence of events of 0ser Acceptance Testin!% and ho$ $ill the testin! activity ta e placeC 3(6 #atc5 Testing 3(7 Automate! egression Testing Definition: Re!ression testin! is the selective retestin! of a system or component to verify that modifications have not caused unintended effects and that the system or component still $or s as specified in the requirements. Participants: Met5o!ology: 3(8 #eta Testing Participants: Met5o!ology: 6() 9A D:A E E;+* EME&TS 1omputers <odems 7() E&.* $&ME&T E;+* EME&TS 7(' Main %rame "pecify both the necessary and desired properties of the test environment. The specification should contain the physical characteristics of the facilities% includin! the hard$are% the communications and system soft$are% the mode of usa!e +for example% stand*alone-% and any other soft$are or supplies needed to support the test. Also specify the level of security $hich must be provided for the test facility% system soft$are% and proprietary components such as soft$are% data% and hard$are. #dentify special test tools needed. #dentify any other testin! needs +for example%

publications or office space-. #dentify the source of all needs $hich are not currently available to your !roup. 7(, :orkstation 8() TEST SC9ED+LE #nclude test milestones identified in the "oft$are Project "chedule as $ell as all item transmittal events. Define any additional test milestones needed. Estimate the time required to do each testin! tas . "pecify the schedule for each testin! tas and test milestone. =or each testin! resource +that is% facilities% tools% and staff-% specify its periods of use. <() C$&T $L P $CED+ ES Pro"lem eporting Document the procedures to follo$ $hen an incident is encountered durin! the testin! process. #f a standard form is !oin! to be used% attach a blan copy as an BAppendixB to the Test Plan. #n the event you are usin! an automated incident lo!!in! system% $rite those procedures in this section. C5ange e=uests Document the process of modifications to the soft$are. #dentify $ho $ill si!n off on the chan!es and $hat $ould be the criteria for includin! the chan!es to the current product. #f the chan!es $ill affect existin! pro!rams% these modules need to be identified. >() %EAT+ ES T$ #E TESTED #dentify all soft$are features and combinations of soft$are features that $ill be tested. ')() %EAT+ ES &$T T$ #E TESTED #dentify all features and si!nificant combinations of features $hich $ill not be tested and the reasons. ''() ES$+ CES? $LES @ ESP$&S*#*L*T*ES "pecify the staff members $ho are involved in the test project and $hat their roles are !oin! to be +for example% <ary )ro$n +0ser- compile Test 1ases for Acceptance Testin!-. #dentify !roups responsible for mana!in!% desi!nin!% preparin!% executin!% and resolvin! the test activities as $ell as related issues. Also identify !roups responsible for providin! the test environment. These !roups may include developers% testers% operations staff% testin! services% etc. ',() SC9ED+LES Ma0or Delivera"les #dentify the deliverable documents. Eou can list the follo$in! documentsF * Test Plan * Test 1ases * Test #ncident Reports * Test "ummary Reports '1() S*2&*%*CA&TL4 *MPACTED DEPA TME&TS AS*DsB Department@)usiness Area )us. <ana!er Tester+s'3() DEPE&DE&C*ES #dentify si!nificant constraints on testin!% such as test*item availability% testin!*resource availability% and deadlines. '6() *S/S?ASS+MPT*$&S #dentify the hi!h*ris assumptions of the test plan. "pecify contin!ency plans for each +for example% delay in delivery of test items mi!ht require increased ni!ht shift

schedulin! to meet the delivery date-. '7() T$$LS (ist the Automation tools you are !oin! to use. (ist also the )u! trac in! tool here. '8() APP $.ALS "pecify the names and titles of all persons $ho must approve this plan. Provide space for the si!natures and dates. ,ame +#n 1apital (etters- "i!nature Date .. 2. 6. 7. End.