0% found this document useful (0 votes)
132 views12 pages

Eplc Test Reports Template

This document provides a test report for a client database management system for an insurance agent. It includes sections on test types conducted, test results, variances found, resolved and unresolved incidents, and recommendations. Unit, module, system, user acceptance, ad hoc, regression, performance, and variable testing were performed. Issues included runtime errors and duplicate data. Recommendations included improving password retrieval and adding policy descriptions.

Uploaded by

Prasad Renukdas
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
132 views12 pages

Eplc Test Reports Template

This document provides a test report for a client database management system for an insurance agent. It includes sections on test types conducted, test results, variances found, resolved and unresolved incidents, and recommendations. Unit, module, system, user acceptance, ad hoc, regression, performance, and variable testing were performed. Issues included runtime errors and duplicate data. Recommendations included improving password retrieval and adding policy descriptions.

Uploaded by

Prasad Renukdas
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 12

CLIENT DATABASE MANAGEMENT FOR L.I.

C AGENT TEST REPORT


Version 1.0 <<mm/dd/yyyy>

VERSION HISTORY
Versio n# 1.0 Implemented By prasad vishal rohit yogesh Revision Date 10/19/2011 Approved By Prof.kondhe Prof.Wagh Approval Date <10/20/2011> Reason

Page 2 of 12

Table of Contents
1.0 INTRODUCTION.........................................................................................................4 1.1 Purpose.................................................................................................................4 2.0 TEST SUMMARY........................................................................................................4 2.1 Test Type (Function, unit, system, etc.)................................................................4 2.2 Test Type (Function, unit, system, etc.)................................................................4 2.3 Test Type (Function, unit, system, etc.)................................................................5 3.0 TEST ASSESSMENT..................................................................................................5 4.0 TEST RESULTS..........................................................................................................5 Unit/Module/System Testing.......................................................................................5 4.2 System Testing.....................................................................................................6 4.3User Acceptance Testing.......................................................................................6 4.4Ad Hoc Testing.......................................................................................................6 4.5Regression Testing................................................................................................7 4.6Performance Testing..............................................................................................7 4.7<VARIABLES AND THEIR VALUES>...................................................................8 5.0 VARIANCES................................................................................................................9 6.0 TEST INSTANCES......................................................................................................9 6.1Resolved Test Incidents.........................................................................................9 6.2Unresolved Test Incidents.....................................................................................9 7.0 RECOMMENDATIONS...............................................................................................9 APPENDIX A: TEST REPORT APPROVAL..................................................................10 11 APPENDIX C: KEY TERMS...........................................................................................12 12

Page 3 of 12

1.0

INTRODUCTION
1.1 PURPOSE This < Client Database Management For L.I.C agent > Test Report provides a summary of the results of test performed as outlined within this document.

2.0

TEST SUMMARY
Project Name: Client Database Management For L.I.C agent Version Number: [1.0]

2.1

TEST TYPE (FUNCTION, UNIT, SYSTEM, ETC.) Test Owner: [PRASAD RENUKDAS] Test Date: [10/12/2011] - [10/19/1991] Test Results: [log in screen provides a good protection against brute force hackers,run time errors handled at some places,GUI is avg] Additional Comments:

2.2

TEST TYPE (FUNCTION, UNIT, SYSTEM, ETC.)

Test Owner: Test Date: Test Results:

Additional Comments:

Page 4 of 12

2.3

TEST TYPE (FUNCTION, UNIT, SYSTEM, ETC.)

Test Owner: Test Date: Test Results:

Additional Comments:

3.0

TEST ASSESSMENT
1]customer detail form , policy details form were validated so that user is restricted from entering the wrong data in the datafield.2]use of primary key n foreign key has prevented the generation of multiple or duplicate copies in the databse.3]relation design concepts such as whether the given relation is in 1NF or 2NF OR 3NF etc wasnt taken into consideration because of which the system may show wrong results in some cases .

4.0

TEST RESULTS
1in some cases the cancel property of the button was said to false because of which the program was getting terminated abnormally .This bug was cleared as soon as it was noticed.2]If user enters wrong information he is informed about it by using run time error handling property such as on error goto label.3]project makes sure that databse donot contain duplicate customer codes hence the database is somewhat stable.3]description of policies isnt available which can be included in the next version of the project.

4.1

UNIT/MODULE/SYSTEM TESTING Unit, module, and system integration testing activities were performed during the development of the system build or release.
Page 5 of 12

4.2

SYSTEM TESTING The table below summarizes the results of system testing:

Test Case ID

Date Tested

Tester

Pass/Fail

Severity of Defect

Summar Closed Comments y of prior to Defect Production Release? <Yes> <No> or

1.01

10/19/2011

Prasad

pass

minimum

4.3

USER ACCEPTANCE TESTING The table below summarizes the test cases employed for user acceptance testing and the test results obtained for each test case: Test Case ID Date Tested Tester Pass/Fail Severity of Defect Summar Closed Comments y of prior to Defect Production Release? <Yes> <No> or

1.023

10/19/2011

4.4

AD HOC TESTING The table below summarizes the test cases employed for ad hoc testing and the test results obtained for each test case:
Page 6 of 12

Test Case ID

Date Tested

Tester

Pass/Fail

Severity of Defect

Summar Closed Comments y of prior to Defect Production Release? <Yes> <No> or

1.01

10/19/2011

prasad

pass

none

4.5

REGRESSION TESTING The table below summarizes the test cases employed for regression testing and the test results obtained for each test case:

Test Case ID

Date Tested

Tester

Pass/Fail

Severity of Defect

Summary of Defect

Closed Comments prior to Production Release? <Yes> <No> or 1.02

1.02

10/19/2011

prasad

fail

average

Run time erro r

4.6

PERFORMANCE TESTING The table below summarizes the test cases employed for performance testing and the test results obtained for each test case:

Test Case ID

Date Tested

Tester

Pass/Fail

Severity of Defect

Summar Closed y of prior to

Comments

Page 7 of 12

Defect 1.03 10/19/2011 prasad pass

Production Release? <Yes> <No> or

4.7

<VARIABLES AND THEIR VALUES> The table below summarizes the test cases employed for VARIABLES AND THEIR VALUES and the test results obtained for each test case: Test Case ID Date Tested Tester Pass/Fail Severity of Defect Summar y of Defect Closed Comments prior to Production Release? <Yes> <No> or

1.04

10/19/2011

prasad

pass

minimum

Page 8 of 12

5.0

VARIANCES

6.0

TEST INSTANCES

6.1

RESOLVED TEST INCIDENTS 1]If user goes to enter different data values for the existing customer id while adding a new entry in database;he is restricted to do so my displaying a message about the error and the information.2]character entries are not allowed in the fields containing the number] 6.2 UNRESOLVED TEST INCIDENTS 1]if user enters the value out of the given range which is assigned for the particular variable the projects ends abnormally. 2]Any user who is logged in may alter the accounts of the remaining users ]

7.0

RECOMMENDATIONS
1]If the user of the software fails to remember the password then he will be required to directly contact the administrator.2]Use of relational design in the database is recommended for getting most appropriate results.3]same code is repeated at most of the places ;so it will be a great idea to wreite functions n procedures for them.4]policy description can be added which can make the project(software ) more useful for the user.

Page 9 of 12

APPENDIX A: Test Report Approval


The undersigned acknowledge they have reviewed the < Client Database Management For L.I.C agent > Test Report and agree with the approach it presents. Changes to this Test Report will be coordinated with and approved by the undersigned or their designated representatives. Signature: Print Name: Title: Role: Project Manager Date:

Page 10 of 12

Page 11 of 12

APPENDIX C: KEY TERMS


The following table provides definitions for terms relevant to this document. Term Relational design Definition A relational database is a collection of data items organized as a set of formallydescribed tables from which data can be accessed or reassembled in many different ways without having to reorganize the database tables. The relational database was invented by E. F. Codd at IBM in 1970.
According to Date's definition of 1NF, a table is in 1NF if and only if it is "isomorphic to some relation", which means, specifically, that it satisfies the following five conditions: 1. 2. 3. 4. There's no top-to-bottom ordering to the rows. There's no left-to-right ordering to the columns. There are no duplicate rows. Every row-and-column intersection contains

1NF

exactly one value from the applicable domain (and nothing else). 5. All columns are regular [i.e. rows have no hidden

components such as row IDs, object IDs, or hidden timestamps].

2NF

1NF table is in 2NF if and only if, given any candidate key, K, and any attribute, A, that is not a constituent of a candidate key, A depends upon the whole of K rather than just a part of it

Page 12 of 12

You might also like