R 1111-RIA-GUI-Test Plan 1.0 1. Test Plan Identifier: (Program)(Release No)Test Plan (Level of Test) LIA-R1-Test Plan-GUI 1. A Revision History:Revision HistoryVersion Date Change Description Au March1.0 05 Initial Creation Q Mar Changes required1.1 06 for Risks
2.0 Introduction: 2.1 A high level description of what this level of Test is covering must be provided 1. QA will validate field Type, Field Caption, Business Rules and field properties associated with Renters Projects
2.2 The description mustidentify the system underTest (Product, system, orsoftware being tested)
QA will validate RentersInsurance Project AgentModule from Customersfunctionality to submitfunctionality. This projectinvolves 3 sub modules.1. Customer 2. Quotation 3.submit modules
2.3 The description mustidentify high levelobjectives, Goals andpurpose of the Testingeffort.Renters Insurance TestingAgent module objective isvalidating the defectsassociated with field leveli.e before going to testsystem functionalities, in
GUI we will validate all theBusiness rules associatedwith Agent Module.The purpose is to testFunctionality, Regressionsmoke and adhoc testingto send the error (Bug)free code to the Next level
2.4 If a high leveldocument exist link to thedocument must beprovidedLink to the Test Strategy:
2. Testing scope: 3.1 In scope (Features to be tested) 3.1.1 A description of the items to be tested must be provided. Depending on the level of test this may include specific components, Modules, Interfaces, Functional Requirements, Non
functionalRequirements3.2 Out of scope(Features not to betested)Renters Insurance:
Functional Requirementsassociated with 1. Customers 2. Property Details 3. Loss history 4. Coverages 5. Quotation 6. Billing 7. Attachments 8. Submit
3.2.1 A description ofanything provided by theproject but that has beenspecifically excluded fromtesting effort must beprovided.1. Navigation from Agent Login to customer screen2. Validations associated with third party
databases such as(Dependencies)1. Customer database2. Loss history database3. Billing database4. After successful submission of the policy other products (Marketing) screen will be displayed
4. Test Approach: 4.1 For each type of test create Type of Testing and objectives of Testing. 4.1 (Type of Test): For each type of Test a description of the Test, subject of the test, and the reason
for the test must beprovided4.1.2 Foe each type of test the objectives for the test must be identified4.1.3 For each objective identified ,the approach that will be used to
meet theobjectivesmust bedefined. Theapproach mustbe how thetesting will beperformed tovalidate theobjectives hasbeen met.
Functional Testing: 1. We will validate all functional requirements 2. To find the defects associated with functional requirements 3. Objective of test is to find the defects associated with field name, field type, Business Rules associated.
Smoke Testing:Smoke Testing purpose is tofind the defects associatedwith Environment stabilityand build stability.In this project daily morningand evening we will performsmoke testing to find thestability.Adhoc Testing:
To find the uncovered defects during normal testing we will do adhoc testing Regression Testing:To find the new/injecteddefects associated with buildchanges/requirement changeswe will do Regression Testing.
5. Test planadministration:5.1 Defect ManagementPlan:Responsibilities:1. All the defects should be raised in defect tracking tool called QC2. All the defects which come into pending
validation should be Retested immediately3. All the defect reports should be sent to management.5.2 Test Managementplan5.3 EnvironmentManagement5.4 Estimations5.5 Status reportmanagemen
5.6 ConfigurationManagement6. Entry criteria and Exitcriteria
Entry criteria for Test casedesign:When to start Test Casedesign1. All the requirements and design documents are analyzed by QA and all the Queries resolved.2. Required supporting documents, Test data should be available.
3. Test case design (Excl/Tool) should be available. Exit criteria for Test case design:(How many Test Cases are enough)1. Requirement – Test Case Tractability.2. Requirement Breakdown3. Known Trouble spots
4. Risk Based analysis Determining the highest risk portions of the product (Impact of failure) can guide where more test coverage needs to be emphasized When to stop Test case design
When to start Test Caseexecution1. Latest Code base should be available in QA env2. Smoke Testing should be successfully completed3. Reviewed Test cases should be available.4. Test executioner should be available5. Test Execution tool should be ready
6. Automation scripts should be available for regression.Exit criteria for Test CaseExecution:1. No high and critical defects2. Medium and low defects should be reviewed by TL.3. Regression Testing should be successfully completed
When to stop test caseexecution 7. Test Resource Needs 1. Environment Needs 2. Training needs 3. Tool needs
8. Testing Mile stones: 1. Test plan 2. Test Approach 3. Requirement analysis 4. Test case design 5. Test Case Review 6. Test Case execution 7. Defects 8. Defect Reports 9. Project closure documents