R 1111-RIA-GUI-Test Plan 1.0 1. Test Plan Identifier:     (Program)(Release No)Test    Plan (Level of Test)    LIA-R1-Test...
2.0 Introduction:     2.1 A high level     description of what this     level of Test is covering     must be provided    ...
2.2 The description mustidentify the system underTest (Product, system, orsoftware being tested)
QA will validate RentersInsurance Project AgentModule from Customersfunctionality to submitfunctionality. This projectinvo...
2.3 The description mustidentify high levelobjectives, Goals andpurpose of the Testingeffort.Renters Insurance TestingAgen...
GUI we will validate all theBusiness rules associatedwith Agent Module.The purpose is to testFunctionality, Regressionsmok...
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 pro...
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. Billi...
LIA: 1. Customers 2. Policy selection 3. Coverage selection 4. Beneficiaries 5. Underwriting 6. Agent Statement 7. Quotati...
3.2.1 A description ofanything provided by theproject but that has beenspecifically excluded fromtesting effort must bepro...
databases such as(Dependencies)1. Customer database2. Loss history database3. Billing database4. After successful   submis...
4. Test Approach:         4.1 For each type of         test create Type of         Testing and         objectives of Testi...
for the test must beprovided4.1.2 Foe each type      of test the      objectives for      the test must      be identified...
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    functi...
Smoke Testing:Smoke Testing purpose is tofind the defects associatedwith Environment stabilityand build stability.In this ...
To find the uncovered  defects during normal  testing we will do adhoc  testing  Regression Testing:To find the new/inject...
5. Test planadministration:5.1 Defect ManagementPlan:Responsibilities:1. All the defects should   be raised in defect   tr...
validation should be   Retested immediately3. All the defect reports   should be sent to   management.5.2 Test Managementp...
5.6 ConfigurationManagement6. Entry criteria and Exitcriteria
Entry criteria for Test casedesign:When to start Test Casedesign1. All the requirements and   design documents are   analy...
3. Test case design    (Excl/Tool) should be    available. Exit criteria for Test case design:(How many Test Cases are eno...
4. Risk Based analysis     Determining the highest   risk portions of the product   (Impact of failure) can   guide where ...
Entry criteria for Test caseexecution:
When to start Test Caseexecution1. Latest Code base should   be available in QA env2. Smoke Testing should be   successful...
6. Automation scripts should   be available for   regression.Exit criteria for Test CaseExecution:1. No high and critical ...
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 ...
9.Risks, dependencies       Unexpected eventRisk Log:Dependencies Log:   10. Authorizations:      TL:      OSC:      BA:
Upcoming SlideShare
Loading in …5
×

R!!! ria-gui-test plan 1.0

532 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
532
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

R!!! ria-gui-test plan 1.0

  1. 1. 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. 2. 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
  3. 3. 2.2 The description mustidentify the system underTest (Product, system, orsoftware being tested)
  4. 4. QA will validate RentersInsurance Project AgentModule from Customersfunctionality to submitfunctionality. This projectinvolves 3 sub modules.1. Customer 2. Quotation 3.submit modules
  5. 5. 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
  6. 6. 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
  7. 7. 2.4 If a high leveldocument exist link to thedocument must beprovidedLink to the Test Strategy:
  8. 8. 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
  9. 9. functionalRequirements3.2 Out of scope(Features not to betested)Renters Insurance:
  10. 10. Functional Requirementsassociated with 1. Customers 2. Property Details 3. Loss history 4. Coverages 5. Quotation 6. Billing 7. Attachments 8. Submit
  11. 11. LIA: 1. Customers 2. Policy selection 3. Coverage selection 4. Beneficiaries 5. Underwriting 6. Agent Statement 7. Quotation 8. Billing 9. Documents 10. Submit
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. meet theobjectivesmust bedefined. Theapproach mustbe how thetesting will beperformed tovalidate theobjectives hasbeen met.
  17. 17. 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.
  18. 18. 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:
  19. 19. 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.
  20. 20. 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
  21. 21. 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
  22. 22. 5.6 ConfigurationManagement6. Entry criteria and Exitcriteria
  23. 23. 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.
  24. 24. 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
  25. 25. 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
  26. 26. Entry criteria for Test caseexecution:
  27. 27. 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
  28. 28. 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
  29. 29. When to stop test caseexecution 7. Test Resource Needs 1. Environment Needs 2. Training needs 3. Tool needs
  30. 30. 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
  31. 31. 9.Risks, dependencies Unexpected eventRisk Log:Dependencies Log: 10. Authorizations: TL: OSC: BA:

×