You are on page 1of 36

[Company title and logo go here]

Test Plan for (Project name)

Confidential and Proprietary Information of Datacard Worldwide

Contents

1.0
1.1. 1.2. 1.3. 1.4.

INTRODUCTION
Objective Project Description Process Tailoring Referenced Documents

3
3 3 3 3

2.0 3.0 4.0 5.0 6.0 7.0 8.0

ASSUMPTIONS/DEPENDENCIES TEST REQUIREMENTS TEST TOOLS RESOURCE REQUIREMENTS TEST SCHEDULE RISKS/MITIGATION METRICS

3 3 4 4 4 4 4 5 6

APPENDIX A DETAILED RESOURCE REQUIREMENTS APPENDIX B DETAILED TEST SCHEDULE

1.0

Introduction
Objective
The Test Plan is an aggregation of information, which describes the entire test activity for this project. It covers the entire testing effort (unit, development test, system verification test, and Beta). It identifies the product requirements, schedules, resource requirements (people, effort and equipment), quality, assumptions, exclusions, and risks. A preliminary Test Plan is prepared for the Project Team during the System Phase of PEAQ Process. This Test Plan will be updated in the earliest possible time of the Implementation Phase, so that progress can be tracked during implementation.

1.1.

1.2.

Project Description
[A short product description]

1.3.

Process Tailoring
[This project will use software development and management processes as a guideline. Some tailoring of the process based upon the unique project requirements will be discussed here. Rationale for eliminating certain process steps will be given. Specify also what types of tests are planned for the project. Types of testing include specification, functional, limits, stress, destructive, compatibility, performance, documentation, network and system. Referenced Documents [All references used to produce this document should be listed here. Examples are Software Requirements Specification, Product Definition Document, Software Development Plan. These references should be listed with part numbers.]

2.0

Assumptions/Dependencies
[All assumptions for carrying out this test effort successfully are listed here. Some requirements assumptions might be necessary in order to scope the test activities. Also, assumption of responsibility to conduct unit, integration, SVT, regression, and beta tests. Also listed here are the external dependencies, such as code completion by a certain date in order to meet the test schedule. Other dependencies might include prototype available and functional by a certain date.]

3.0

Test Requirements
[Itemize a list of system test requirements as extracted from Software Requirements Spec, Product Definition Document, and possibly Software Design Document. Every requirement should be listed as an item. This list will be used to trace test cases and procedures that verify/validate the requirements.

4.0

Test Tools
[Itemize a list of test tools needed to conduct the test activities. Identify existing tools as well as any to-bedeveloped or purchased tools. If some software tools need to be developed, describe the process to be used. The schedule and resource requirements must be identified and included in the sections that follow.]

5.0

Resource Requirements
[Based upon the test requirements identified in Section 3.0 and the tools development identified in Section 4.0, an estimate of resource required to accomplish the tests are performed. See Appendix A for details.]

6.0

Test Schedule
[Based upon the resource requirements identified in Section 5.0, a test schedule can be planned. The test schedule must be compatible with the project overall schedule. Coordination with the Project Manager and Development Lead Engineers is essential in planning a realistic and workable schedule. See Appendix B for details. ]

7.0

Risks/Mitigation
[List all potential risks in this section. There still might be risks even in a good plan. These should be identified and a mitigation plan developed.]

8.0

Metrics
The following metrics data will be collected. Some will be collected prior to, and some after product shipment.

Prior to shipment: Effort expended during DVT, SVT and Regression # of defects uncovered during DVT, SVT and Regression, and development phase each defect is attributable to Test tracking S-Curve PTR S-Curve

After shipment: # of defects uncovered and development phase each defect is attributable to Size of software

Appendix A Detailed Resource Requirements


[To estimate the resource, all test activities must be identified and resources needed to accomplish the activities estimated. Detailed estimates will be shown here. This consists of identifying all project test activities by the Test Group and the number of hours estimated to accomplish these activities. Be specific. Show specific responsible test engineers names, if possible. A grand total of the effort must be shown here, as well as in Section 5.0.]

Appendix B Detailed Test Schedule


[Attach two charts, viz. Gantt and PERT. In Gantt, main activities are shown as a list on the Y-column with bars parallel to the X-axis, showing the timeframe to perform activities. In PERT, dependencies of each activity must be identified.]

System Verification Test Plan for Advanced Color Module

Rev 2.0

2/22/00

Contents
1. 2. Objectives of the Test Test Description 2.1 Description 2.2 References Schedule Resources Required Dependencies Entry Criteria Exit Criteria Test Tools Owner Metrics Test Plan Requirements Matrix Document History Definitions and Acronyms

3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

Appendix A - Test Plan Requirements Matrix Appendix B B.1 B.2 B.3 B.4 B.5 Test Cases Configuration/Install Test Entrance Test Main Test Regression Test Test Case Procedures

Advanced Color Module Test Plan Revision 2.0 9/12/2010 ___________________________________________________________________________________________________________

1.

Objectives of the Test This document describes the test plan for the 9000 Advanced Color Module and includes information on what is to be tested, and how the testing is to be accomplished (test methodology). Specifically, this document describes the tests to be performed, the testing schedule, resources required, entry criteria, exit criteria, dependencies, test tools, metrics and the Test Plan Requirements Matrix. This is a living test plan and must be changed to reflect Core Team needs and requirements as they arise. The main purpose of this test is to verify the requirements for the 9000 Advanced Color Module as set forth in References 2 and 3 (Advanced Color Module SRS and Common Image Generator SRS).

2. 2.1

Test Description Description Much of the functionality that was handled by the module firmware and DLL has been relegated to the Common Image Generator, and much of what is in the CIG is being tested by the UltraGraphics Module tests. Thus every attempt will be made not to overlap too much with what is being covered by UltraGraphics. For example, all the image positioning commands are handled by the CIG and will be tested by UltraGraphics, making it unnecessary to stress this aspect of color photo printing here. System Verification Test will be broken into three phases: Entrance Testing will verify that the new Advanced Color Module can process a standard set of color images that use the 4 hybrids of Version A and B headers. See Appendix B.2 for a description of the Entrance Test cases. Main Test will thoroughly verify the operation of the Advanced Color Module software and hardware. Main Test determines that all the requirements in the SRS have been satisfied. The Main Tests will consist of both new tests written for this SVT effort as well as tests selected from the current 9000 Library of test cases. The following types of testing, as specified in Reference 4, will be included: Specification testing Functional testing Compatibility testing Documentation review See Appendix B.3 for a description of the Main Testing test cases. Regression Test will be performed as a subset of Main Test to verify the integrity of the Advanced Color Module after all problems found during Main Testing have been attended to. This means that all Severity 1 and 2 defects have been fixed and verified and that the product is ready for release. See Appendix B.4 for a description of the Regression Test cases.

2.2

References 1. 2. 3. 4. Software Development Process Handbook (no revision, no date) Software Requirements Specification for the Advanced Color Module, May 13, 1999 Software Requirements Specification for the Common Image Generator, May 28, 1999 Structured Software Test Planning at DataCard, participant manual from Benchmark Laboratories Incorporated, August 1996

3.

Schedule
Page 3

Advanced Color Module Test Plan Revision 2.0 9/12/2010 ___________________________________________________________________________________________________________ The testing defined in this document shall be completed according to the following schedule Test Sequence 1. Test Development 2. Module Availability 3. SVT Entrance Testing 4. SVT Main Testing 5. SVT Regression Testing Start 7-6-99 9-20-99 9-22-99 9-29-99 10-27-99 Finish 9-21-99 --9-28-99 10-26-99 11-2-99

The testing defined in this document was completed as follows: Test Sequence 1. Test Development 2. Module Availability 3. SVT Entrance Testing 4. SVT Main Testing 5. SVT Regression Testing Start 7-6-99* 1-10-00 1-17-00 2-15-00 Finish 12-17-99 1-14-00 2-22-00 3-15-00

* Finalized Test Plan began on this date. A preliminary Test Plan (in lieu of a Test Strategy) had been used for scheduling purposes.

4.

Resources Required System Verification Test will require the following resources: a High Speed Advanced Color Module a Standard Speed Advanced Color Module a 9000 System dedicated to Advanced Color Module testing the latest version of the CIG DLL and the Advanced Color DLL a fully-loaded 9000, with a High Speed Advanced Color Module, for Endurance and Performance testing two SVT test personnel with at least 80% of his/her time available for this effort. The following consumables are required in order to complete testing:

Item
1. Ribbons 2. Ribbon 3. Cards

Description
Tonal, black Color Blank / White MagStripe

Quantity
1 ribbon 5 ribbons 1 case (4000 Cards)

5.

Dependencies In order to begin testing of the Advanced Color Module, the following needs to happen: an Advanced Color Module is available and is installed in a lab 9000 the Common Image Generator DLL is available and is loaded on the 9000 Controller the CIG Entrance Test has been run a good portion (to be identified) of the UltraGraphics SVT has been run the required Image and Module Profiles have been created and are available

6.

Entry Criteria

Page 4

Advanced Color Module Test Plan Revision 2.0 9/12/2010 ___________________________________________________________________________________________________________ All entry criteria defined in Reference 1 (PEAQ) must be satisfied for entry into this test to occur. In addition, it is expected that a good portion of the UltraGraphics SVT test cases will have been run, since they are being used to check out the Common Image Generator.

7.

Exit Criteria All exit criteria defined in Reference 1 (PEAQ) must be satisfied for the completion of this test.

8.

Test Tools Various hardware and software test tools apart from the deliverable product are used to assist in the testing process. These include: defect control reporting and tracking software (PVCS Tracker) hardware monitors

9.

Owner This test plan is owned and maintained by the Test/Tools Group.

10.

Metrics The status and progress of SVT will be recorded through the collection of various sets of data, and the Test Case Matrices in Appendix B will regularly be updated with the status of each test case. Thus, at any time one can see how many test cases have been attempted and, of those, how many have passed. In addition, effort, size and defect data will be collected prior to and after product shipment. Once data from enough projects has been collected, estimates of testing progress and duration will become more meaningful.

11.

Test Plan Requirements Matrix The Test Plan Requirements Matrix lists all the testable requirements for the Advanced Color Module, as determined from Reference 2, and indicates which test cases verify those requirements. The complete test plan requirements matrix is in Appendix A; the associated Test Case Matrix is in Appendix B.3.

12.

Document History Rev. P1 - 07/08/99 Initial Draft Rev. 1.0 - 07/30/99 Color Management requirements were pared down per a conversation with Colleen. The entire Appendix B was filled in. Entries in Appendix A were clarified. Rev. 1.1 - 12/7/99 Updated the Main Test matrix in Section B.3 Rev. 1.2 - 12/16/99 Updated the schedule in Section 3. Rev. 2.0 - 2/22/00
Page 5

Advanced Color Module Test Plan Revision 2.0 9/12/2010 ___________________________________________________________________________________________________________ Updated the Test Cases in Appendix As Test Plan Requirements Matrix. Removed most of the matrices from Appendix B and substituted references to the appropriate documents.

13.

Definitions and Acronyms 9000 ACM CIG DLL PEAQ SRS SVT DataCard Series 9000 Card Personalization System (or, an embosser) Advanced Color Module Common Image Generator Dynamically Linked Library Product Excellence and Quality Software Requirements Specification System Verification Test

Page 6

Advanced Color Module Test Plan Revision 2.0 9/12/2010 ___________________________________________________________________________________________________________ Appendix A Test Plan Requirements Matrix

Requirement Requirement name number 1 1-A 1-B 1-C 2 2-A 2-B 2-C 2-D 2-E Hardware Setup selections SSC-VerX Module Emulation File HSC Module Emulation File AC Module Emulation File Extended UltraGraphics Command Language Color specification (Command CST) Horizontal and Vertical scaling Background Color specification Foreground Color specification Opacity

Relevant section(s) of SRS 3.3.1 3.3.1 3.3.2, 3.3.3

Notes

ACM-05, Section I ACM-05-3 through -12 ACM-05-2 ACM-05-1 and -3 ACM-01, Section II ACM-01-108 ACM-01-82, -83, -92, -93, -102, 103 ACM-01-114, -118, -122; ACM03-193 ACM-01-115, -119, -123; ACM03-193 ACM-01-85, -86, -95, -96; ACM03-182, -184, -185, -186, -188, 189, -192 ACM-01-87, -97, -107; ACM-03183, -184, -185, -187, -188, -189, 192 ACM-01-113, -117, -121, plus ACM-02, Section II ACM-01-112, -116, -120 plus ACM-02, Section II ACM-03, Section I ACM-03-19 through -180 ACM-01, Section I ACM-01-31 through -45 ACM-01-1 through -30 ACM-01-62 through -77 ACM-01-46 through -61 ACM-02, Section I ACM-02 -1 through -14 ACM-02-15 and -16

3.4.1.1 3.4.1.4 3.4.1.5 3.4.1.6 3.4.1.7

2-F

Z-order

3.4.1.8

2-G 2-H

Image Color Profile Color Filter specification

3.4.1.9 3.4.1.10

3 3-A 4 4-A 4-B 4-C 4-D 5 5-A 5-B 6 6-A 6-B 6-C 6-D 6-E 6-F 6-G

ColorPrint card setup overrides Overrides Version A and B Header compatibility Version A, embedded Version A, file name Version B, embedded Version B, file name Print Quality Increased number of shades Reduced tiling Color Management Color Filter specified: Both Image profile and Module profile No Color Filter specified: No profiles No Color Filter specified: Both Image profile and Module profile Default Image profile (sRGB) Default Image profile (CG1) Default Image profile (HSC2) Default Module profile
Page 7

3.5

3.6 3.6 3.6 3.6

3.8.1 3.8.2

ACM-02, Section II 3.9, 3.9.1, 3.9.2, ACM-02-18 through -29 3.9.3 3.9 ACM-01, for example 3.9, 3.9.1, 3.9.3 ACM-02-17 3.9.1 3.9.1 3.9.1 3.9.3 Requirement is obsolete (2-11-00) Part of the Manufacturing process

Advanced Color Module Test Plan Revision 2.0 9/12/2010 ___________________________________________________________________________________________________________ Requirement Requirement name number 6-H 6-I 6-J 6-K 6-L 7 7-A 8 8-A 8-B 8-C 8-D 8-E 8-F 8-G 8-H 8-I 9 9-A 10 10-A 10-B 10-C 10-D 11 11-A 12 12-A 13 13-A Ability to import an Image color profile Ability to import a color filter Ability to import a Module color profile Specify Image color profile directory Specify color filter directory Test Card generation Generate run-time image data records File Types DPG: Datacard proprietary DPC: Datacard UltraGraphics proprietary DIB: Device Independent Bitmap GIF: Graphic Interchange Format JPEG: Joint Photographic Experts Group TIF: Tagged Image File TGA: Targa BMP: Bitmap PCX: Paintbrush Multiple Images Multiple images Image distribution One Advanced Color module, no multi-image option One Advanced Color module, multi-image option Two Advanced Color modules, no multi-image option Two Advanced Color modules, multi-image option Error Tests Consistent error handling Performance Performance requirements Documentation Advanced Color Module documentation Relevant section(s) of SRS 3.14.1 3.14.2 3.14.3 3.15.1 3.15.2 Notes

See File Management test cases See File Management test cases See File Management test cases ACM-02-30 ACM-02-31 ACM-06, Section I ACM-06-1 through -4 ACM-03, Section I ACM-03-1, ACM-03-10, etc. ACM-03-2, ACM-02-11, etc. ACM-03-3, ACM-03-12, etc. ACM-03-4, ACM-04-13, etc. ACM-03-5, ACM-05-14, etc. ACM-03-6, ACM-03-15, etc. ACM-03-7, ACM-03-16, etc. ACM-03-8, ACM-03-17, etc. ACM-03-9, ACM-03-18, etc. ACM-03, Section II ACM-03-182 through -191 ACM-03, Section III Various ACM-03-193 ACM-03-193 ACM-04, Section I ACM-04 ACM-06, Section II ACM-06-6 through -9 ACM-06, Section IV The documents affected are not listed anywhere that I can tell ACM-06-11 through -13 ACM-06-14

3.10

3.11 3.11 3.11 3.11 3.11 3.11 3.11 3.11 3.11

3.12

3.18.6 3.18.6 3.18.6 3.18.6

3.18.7

13-B

Help screens

9.1

Page 8

Advanced Color Module Test Plan Revision 2.0 9/12/2010 ___________________________________________________________________________________________________________ Appendix B.1 Configuration/Installation Test

Requirement Requirement name number Inst Inst-A Inst-B Inst-C Inst-D Inst-E Inst-F Inst-G Installation Error message verification Installation of Multi-image Option alone Installation of Color Management Option alone Installation of both options together De-installation of both options Re-installation of both options Installing a 9000 Build removes both options

Relevant section(s) of SRS None None None None None None None

Notes

ACM-06, Section V ACM-06-15 ACM-06-16 ACM-06-17 ACM-06-18 ACM-06-19 ACM-06-20 ACM-06-21

Appendix B.2 Entrance Test The Entrance Test Case Matrix for the Advanced Color Module SVT is in a separate document titled acmentr.doc. There are a total of 72 test cases defined.

Appendix B.3 Main Test The Main Test Case Matrix for this SVT is in a separate document titled acmsvt.doc. There are a total of 508 test cases defined.

Appendix B.4 Regression Test Regression Testing will consist of a subset of Main Testing based on those areas where problems were found. The Test Case Matrix for ACM Regression Test is in a separate element titled acmreg.doc; a total of 132 test cases are defined.

Appendix B.5 Test Case Procedures The Test Case Procedures for Entrance Testing and Main Testing are in ACM-nn.DOC where nn is 01, 02, 03, 04, 05 or 06, depending on the requirement.

Page 9

Test Requirements/Test Cases for


<Project-Name> <Revision> <Date> <Author Name> <Group Name>

Test Requirements/Test Cases for <Project-Name> Revision 2.0 9/12/2010 _____________________________________________________________________________________________________

Table of Contents
1. TEST REQUIREMENTS .................................................................................................................................................... 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 2. OBJECTIVE ...................................................................................................................................................................... 1 EXPLICIT REQUIREMENTS................................................................................................................................................ 1 IMPLICIT REQUIREMENTS ................................................................................................................................................ 1 REQUIREMENTS MATRIX ................................................................................................................................................. 1 TEST CASE MATRIX ........................................................................................................................................................ 2 TRACEABILITY MATRIX................................................................................................................................................... 3 REFERENCE DOCUMENTS ................................................................................................................................................ 3 DEFINITIONS AND ACRONYMS ......................................................................................................................................... 3

TEST CASES ........................................................................................................................................................................ 4 2.1 2.2 DESCRIPTION ................................................................................................................................................................... 4 TEST CASE TEMPLATE .................................................................................................................................................... 4

3.

APPENDIX A ....................................................................................................................................................................... 4 3.1 SAMPLE REQUIREMENTS, TEST CASE AND TRACEABILITY MATRICES............................................................................. 4

4.

APPENDIX B ....................................................................................................................................................................... 4 4.1 SAMPLE TEST CASES ....................................................................................................................................................... 4

Page ii

Test Requirements/Test Cases for <Project-Name> Revision 2.0 9/12/2010 _____________________________________________________________________________________________________

1. Test Requirements 1.1 Objective


The purpose of the Test Requirements section is to list ALL hardware and software test requirements, whether explicitly determined from any relevant documents or implicitly determined from experience and product knowledge. For most projects, the documents referred to may be the Product Definition Document, Software/Hardware Requirements Specification and perhaps the Software/Hardware Design Specification. The format used to list the requirements will be that of a Requirements Matrix and associated Traceability Matrices (TM). The Requirements Matrix shows which section of the requirements document the requirement may be found in, and the Traceability Matrix shows which test case(s) verify the various requirements. In addition, a Test Case Matrix is provided that simply lists all the test cases by title or description, and includes a method of tracking when the test case was run and whether it passed or not.

1.2 Explicit Requirements


Explicit requirements for the product can usually be recognized by the use of such helping verbs as will/will not, should/should not, must/must not, etc. All explicit requirements should be listed in the Requirements Matrix along with the section(s) of the document where the requirement is specified. Once listed, a requirement should not be deleted from the matrix. If the requirement is removed from the SRS, for example, change the section designation to read Removed in Ver. xx.x of the SRS, where xx.x denotes the relevant version of the document. Similarly, added requirements could be annotated as Added in Ver. xx.x of the SRS along with the section number. This particular section of the Test Requirements/Test Cases document may be used to indicate how the explicit requirements were determined.

1.3 Implicit Requirements


Implicit, or implied, requirements are generally determined by experience. Typical implicit requirements are performing Endurance Testing and verifying Documentation updates. While not specifically mentioned in the SRS, they are nevertheless important parts of product completeness. Implicit requirements should be listed in the matrix with a notation of Imp to indicate that there is no specific section of the document that specifies this requirement. This section of the Test Requirements/Test Cases document may be used to indicate how the implicit requirements were determined.

1.4 Requirements Matrix


This section contains the Requirements Matrix; a template for such a matrix is shown below. The columns of the Requirements Matrix have the following meanings: Requirement number: Requirement name: Relevant section: Some sort of identifier for the requirement use whatever makes sense in the context. A description of the requirement. The section of the specified document where the requirement is described. If more than one document is used to determine requirements, the column heading could specify something like All references are from the SRS unless otherwise specified, or the appropriate document could be listed with each section designation. Indications of added or removed comments could be listed here, along with any other comments relevant to this requirement.

Notes:

An example of an actual Requirements Matrix along with the associated Traceability Matrices is shown in Appendix A. Requirement Requirement name number Page 1 Relevant section(s) of SRS Notes

Test Requirements/Test Cases for <Project-Name> Revision 2.0 9/12/2010 _____________________________________________________________________________________________________

Requirement Requirement name number 1 1-A 1-B 1-C 2 2-A 2-B 2-C etc. Group or Area #1 Requirement 1 Requirement 2 Requirement 3 Group or Area #2 Requirement 1 Requirement 2 Requirement 3

Relevant section(s) of SRS x.x.x or Imp x.x.x or Imp x.x.x or Imp

Notes

x.x.x or Imp x.x.x or Imp x.x.x or Imp

1.5 Test Case Matrix


This section contains the Test Case Matrix for the project. The purpose of the Test Case Matrix is to list all test cases defined for this project, including Entrance Test Cases, Main Test Cases and Regression Test Cases. A separate matrix may be used for each phase of SVT. The columns of the Test Case Matrix have the following meanings: Some sort of identifier for the Test Case if this test case is part of a Test Module (see Sec. 2.1), the module ID should be incorporated in the Test Case ID. Test Case description: A description of the test case, or its title. Test Case types: Various Test Case types may be specified, with an X in the appropriate columns for each test case of that type. Some Test Case types are: SPEC Specification Testing FUNCTION Functional Testing COMPAT Compatibility Testing DOCUMENT Documentation Testing NETWORK Network Testing USER User Testing Other examples may be found in the Structured Software Test Planning at DataCard, participant manual from Benchmark Laboratories Incorporated, August 1996 Date last attempted / PTR#: The date that this test case was last attempted, along with the relevant PTR number if the test case failed. Date Complete: The date the Test Case first passed. The template for each Test Case Matrix is as follows: Test Case ID:

Test Case ID

Test Case description

S P E C

F U N C T I O N

C O M P A T

D O C U M E N T

N E T W O R K

U Date last S attempted / E PTR # R

Date Complete

Page 2

Test Requirements/Test Cases for <Project-Name> Revision 2.0 9/12/2010 _____________________________________________________________________________________________________

Test Case ID

Test Case description

S P E C

F U N C T I O N

C O M P A T

D O C U M E N T

N E T W O R K

U Date last S attempted / E PTR # R

Date Complete

Test Module ID Test Module name #1 Test case ID #1 Test case ID #2 Test case ID #3 Test Module ID Test Module name #2 Test case ID #1 Test case ID #2

The order in which test cases are listed in the matrix is not intended to indicate the order in which they must be run. An example of an actual Test Case Matrix is shown in Appendix A.

1.6 Traceability Matrix


The purpose of a Traceability Matrix is to show which test cases verify which requirements. A possible format for a Traceability Matrix is as follows: Requirement \ Test Case Requirement 1 Requirement 2 Requirement 3 Test Case ID 1 X Test Case ID 2 X Test Case ID 3 X X Test Case ID 4

1.7 Reference Documents


Describe in full all documents used for determining requirements.

1.8 Definitions and Acronyms


List any technical terms or acronyms used in the document, along with their meanings. Examples for this document: HRS Hardware Requirements Specification SRS Software Requirements Specification TM Traceability Matrix

Page 3

Test Requirements/Test Cases for <Project-Name> Revision 2.0 9/12/2010 _____________________________________________________________________________________________________

2. Test Cases
2.1 Description
Test Cases are developed to verify the various requirements listed in the Requirements Matrix. Various Traceability Matrices are then constructed to show the correspondence between Requirements and Test Cases. For convenience, test cases may be logically grouped together in what are called Test Modules, based on areas of testing. The use of Test Modules helps make the Traceability Matrices and archiving Test Cases more manageable.

2.2 Test Case Template


Test Case ID Test Case Title

The underlined Test Case ID may be any convenient identifier, as decided upon by the tester. Identifiers should follow a consistent pattern within Test Cases, and a similar consistency should apply across Test Modules written for the same project. See Appendix B for an example. Purpose: Owner: Expected Results: The purpose of the Test Case, usually to verify a specific requirement. The person(s) or department responsible for keeping the Test Cases accurate. Describe the expected results and outputs from this Test Case. It is also desirable to include some method of recording whether or not the expected results actually occurred, i.e. if the test case, or even individual steps of the test case, passed. Any required data input for the Test Case. Any specific or unusual tools or utilities required for the execution of this Test Case. If correct execution of this Test Case depends on being preceded by any other Test Cases, that fact should be mentioned here. Similarly, any dependency on factors outside the immediate test environment should also be mentioned. If the system software or hardware has to be initialized in a particular manner in order for this Test Case to succeed, such initialization should be mentioned here. Describe what will take place during the Test Case. The description should take the form of a narrative description of the test case, along with a Test Procedure, which in turn can be specified by test case steps, tables of values or configurations, further narrative, or whatever is most appropriate to the type of testing taking place.

Test Data: Test Tools: Dependencies:

Initialization:

Description:

At this point, the actual Test Case steps may be listed, or relevant data tables, or any other information that will help in executing the Test Case successfully. See Appendix B for examples. Note that Appendix B gives examples of various ways of specifying the test procedure associated with a test case.

Page 4

Test Procedure CSMLIB-04

Data Insertion and the Data In Window

Test Case CSMLIB-04-1 Purpose: Owner:

Load 9000-compatible data via host simulation

Load data from a host via unattended operation. The data loaded will be 9000 compatible. Test/Tools Group

Expected Results: The data will be loaded without errors, and will be stored correctly. Test Data: Test Tools: Dependencies: Initialization: Description: Datafile HTEST.01 Host simulator HOSTPOLL.EXE HOSTPOLL must be on the test system and running. The command to start HOSTPOLL is as follows: START /n HOSTPOLL -s10 The CSM is at the main menu screen. HOSTPOLL is running. Data is loaded via host simulation and then verified to be on the CSM.

CSMLIB-04-1 CSM Step 1: Click on 2. Data In on the main CSM menu bar Expected result The Data In window appears. Step 2: Select an <Input Devices> of HOSTIN Select a <Data Setup> of DEFAULT Press ALT + V on the keyboard, then press the Up and Down Arrow keys until HOST appears in the <Device Setup> drop-down list Click on the Exit button Expected result Control returns to the CSM main menu screen. Step 3: Switch to an OS/2 window Copy drive:<directory>\htest.01 to C:\csm\datain\host\htest.01 Type exit and press Enter Expected result Control returns to the CSM main menu screen Step 4: Click on 3. Status on the main CSM menu Expected result The Device Status window appears. The HOSTIN entry shows that data is being loaded into the CSM. Step 5: Click on the Exit button Expected result Control returns to the CSM main menu screen. Step 6: After the data has loaded, click on 1. Production Expected result The Production window appears. Step 7: Click on HOST in the <Production Groups> list box Expected result The job loaded from the host simulator will be listed in the <Jobs> list box with a sequence number beginning with H. Step 8: Click on the Exit button Expected result Control returns to the CSM main menu screen. Step 9: Switch to an OS/2 window Do a DIR of directory C:\csm\datain\host Expected result The directory is empty. Step 10: Type exit and press Enter Expected result Control returns to the CSM main menu screen

Test Cases ACM-01-108 through ACM-01-123 Purpose: Owner: Verify that the color-related UltraGraphics Language commands work as designed. Test/Tools Group

Expected Results: Vary by command. In each case, the command will respond as expected, and all parameter values will be honored. Test Data: Data directory: WG3\VOL1 : udd4\mcc\ACMTest\ACM-01\UGcommands Datafile: colorcmd.dat Card Setup: 2image Data Setup: 2image Device Setup: dada [On test platform Continuation 2, Job Setup 2image takes care of the above Card and Data Setups, along with Machine Setup 2image-a.] None None

Test Tools: Dependencies: Initialization:

In the Machine Setup, Color Management must be turned On and a Module Profile selected. On Continuation 2, the Machine Setup is 2image-a and the appropriate Module Profile is hs01-07-00.ocp.

Description: The specified datafile is inserted on the 9000 using the designated setups; this will result in 1 job of 16 cards each as shown in Table 3 below. The jobs are then produced on the 9000. Table 3 Test Case ACM-01-108 ACM-01-109 ACM-01-110 ACM-01-111 ACM-01-112 ACM-01-113 ACM-01-114 ACM-01-115 ACM-01-116 ACM-01-117 ACM-01-118 ACM-01-119 ACM-01-120 ACM-01-121 ACM-01-122 ACM-01-123

CST: LB: LST: FLP: LCF: LCP: LBC: LFC: TCF: TCP: TBC: TFC: BCF: BCP: BBC: BFC:

Command being tested Color Specification Type Border for a logo Security Text for a logo Flip for a logo Color Filter for a logo Color Profile for a logo Background Color for a logo Foreground Color for a logo Color Filter for text Color Profile for text Background Color for text Foreground Color for text Color Filter for a Barcode Color Profile for a Barcode Background Color for a Barcode Foreground Color for a Barcode

Findings while investigating the CSM Help screens. NOTE 1: Some Help screens have green links to other topics. The links should be verified, as well as the topics themselves.

Window Title Bar Adding/Changing Split Jobs Add Jobs to Queue(s) Add Tape Setup Citibank Queue Detail Close Queue(s) Copy Tape Setup Create Queue Data Input

Test Case(s) CSMLIB-11-8 CSMLIB-07-32 CSMLIB-17-4 CSMLIB-07-30 CSMLIB-17-4 CSMLIB-07-28 CSMLIB-04-17

Findings None None

In the paragraph with the Reports link: a report will generated a report will be generated. None Read Bytes should be Read Count Insert Recs should be Insert Count Under the Begin button description, if you are denied access via security, the Button isnt even present.

Data Input Summary Delete Tape Setup Device Information Device Status Device Utilization by Shift End-Of-File Parameters End-Of-Tape Parameters File Identification Filter Builder Overview

CSMLIB-17-4 CSMLIB-13-10 CSMLIB-17-4 CSMLIB-17-4 CSMLIB-17-4 CSMLIB-06-11

First sentence: met meet Under RECORDS AND FIELDS: have a separate fields have separate fields None, but see PTR #xxx

FIR Item Descriptions FIR View Global Processing Exceptions Global Tagged and Held HCS Embossing by Product HCS Stock Numbers HCS Total Page/STAG/Batch Sum Job Content Job Control/View Job Processing Exceptions Job Splitting

CSMLIB-09-5

CSMLIB-09-5 CSMLIB-11-5

None 2nd sentence of 2nd paragraph: missing a with. Item 4 under DELETING SPLIT JOBS: Actually, its the OK button that gets pressed more than once.

Job Status Job Tagged and Held

Test Case Matrix for Advanced Color SVT Regression Test Start date: 2-15-00 with Build 74
Test Cases ACM-01, Section I: Version A and B Header Compatibility Part B: Color Header data on an HSACM ACM-01-31 Image setup 2.B1 ACM-01-32 Image setup 2.B2 ACM-01-33 Image setup 2.B3 ACM-01-34 Image setup 2.B4 ACM-01-35 Image setup 2.B5 ACM-01-36 Image setup 2.B6 ACM-01-37 Image setup 2.B7 ACM-01-38 Image setup 2.B8 ACM-01-39 Image setup 2.B9 ACM-01-40 Image setup 2.BA ACM-01-41 Image setup 2.BB ACM-01-42 Image setup 2.BC ACM-01-43 Image setup 2.BD ACM-01-44 Image setup 2.BE ACM-01-45 Image setup 2.BF

132 test cases End date:


Date last run P (pass) or F (fail) 15 test cases P P P P P P P P P P P P P P P 10 test cases 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 P P P P P P P P P P 16 test cases 2-23-00 2-23-00 2-23-00 2-23-00 2-23-00 2-23-00 2-23-00 2-23-00 2-23-00 2-23-00 2-23-00 2-23-00 P P P P P P P P P P P P

2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00 2-21-00

ACM-01, Section II: Extended UltraGraphics Command Language Part A: UltraGraphics Language commands on the Advanced Color Module ACM-01-98 BH Horizontal Offset for a barcode ACM-01-99 BV Vertical Offset for a barcode ACM-01-100 BO Orientation for a barcode ACM-01-101 BR Rotation for a barcode ACM-01-102 BSH Scaled Height for a barcode ACM-01-103 BSW Scaled Width for a barcode ACM-01-104 BF Font type for a barcode ACM-01-105 BI Interpretation for a barcode ACM-01-106 BL Length for a barcode ACM-01-107 BZO Z-order for barcodes ACM-01, Section II: Extended UltraGraphics Command Language Part B: UltraGraphics Language Color commands ACM-01-108 CST: Color Specification Type ACM-01-109 LB: Border for a logo ACM-01-110 LST: Security Text for a logo ACM-01-111 FLP: Flip for a logo ACM-01-112 LCF: Color Filter for a logo ACM-01-113 LCP: Color Profile for a logo ACM-01-114 LBC: Background Color for a logo ACM-01-115 LFC: Foreground Color for a logo ACM-01-116 TCF: Color Filter for text ACM-01-117 TCP: Color Profile for text ACM-01-118 TBC: Background Color for text ACM-01-119 TFC: Foreground Color for text

Advanced Color Module Test Plan Revision 1.1 9/12/2010 ___________________________________________________________________________________________________________ Appendix A Test Plan Requirements Matrix

Requirement Requirement description number 1 1-A 1-B 1-C 2 2-A 2-B 2-C 2-D 2-E Hardware Setup selections SSC-VerX Module Emulation File HSC Module Emulation File AC Module Emulation File Extended UltraGraphics Command Language Color specification (Command CST) Horizontal and Vertical scaling Background Color specification Foreground Color specification Opacity

Relevant section(s) of SRS 3.3.1 3.3.1 3.3.2, 3.3.3

Test Cases

ACM-05, Section I ACM-05-3 through -12 ACM-05-2 ACM-05-1 and -3 ACM-01, Section II ACM-01-108 ACM-01-82, -83, -92, -93, -102, 103 ACM-01-114, -118, -122; ACM03-193 ACM-01-115, -119, -123; ACM03-193 ACM-01-85, -86, -95, -96; ACM03-127 through -144, 182, -184, 185, -186, -188, -189, -192 ACM-01-87, -97, -107; ACM-03183, -184, -185, -187, -188, -189, 192 ACM-01-113, -117, -121, plus ACM-02, Section II ACM-01-112, -116, -120 plus ACM-02, Section II ACM-03, Section I ACM-03-19 through -180 ACM-01, Section I ACM-01-31 through -45 ACM-01-1 through -30 ACM-01-62 through -77 ACM-01-46 through -61 ACM-02, Section I ACM-02 -1 through -14 ACM-02-15 and -16

3.4.1.1 3.4.1.4 3.4.1.5 3.4.1.6 3.4.1.7

2-F

Z-order

3.4.1.8

2-G 2-H

Image Color Profile Color Filter specification

3.4.1.9 3.4.1.10

3 3-A 4 4-A 4-B 4-C 4-D 5 5-A 5-B 6 6-A 6-B 6-C 6-D 6-E 6-F 6-G 6-H

ColorPrint card setup overrides Overrides Version A and B Header compatibility Version A, embedded Version A, file name Version B, embedded Version B, file name Print Quality Increased number of shades Reduced tiling Color Management Color Filter specified: Both Image profile and Module profile No Color Filter specified: No profiles No Color Filter specified: Both Image profile and Module profile Default Image profile (RGB) Default Image profile (CG1) Default Image profile (HSC2) Default Module profile Ability to import an Image color profile

3.5

3.6 3.6 3.6 3.6

3.8.1 3.8.2

ACM-02, Section II 3.9, 3.9.1, 3.9.2, ACM-02-18 through -29 3.9.3 3.9 ACM-01, for example 3.9, 3.9.1, 3.9.3 ACM-02-17 3.9.1 3.9.1 3.9.1 3.9.3 3.14.1 ACM-02-30 ACM-02-31 See File Management test cases

Advanced Color Module Test Plan Revision 1.1 9/12/2010 ___________________________________________________________________________________________________________ Requirement Requirement description number 6-I 6-J 6-K 6-L 7 7-A 8 8-A 8-B 8-C 8-D 8-E 8-F 8-G 8-H 8-I 9 9-A 10 10-A 10-B 10-C 10-D 11 11-A 12 12-A 13 13-A Ability to import a color filter Ability to import a Module color profile Specify Image color profile directory Specify color filter directory Test Card generation Generate run-time image data records File Types DPG: Datacard proprietary DPC: Datacard UltraGraphics proprietary DIB: Device Independent Bitmap GIF: Graphic Interchange Format JPEG: Joint Photographic Experts Group TIF: Tagged Image File TGA: Targa BMP: Bitmap PCX: Paintbrush Multiple Images Multiple images Image distribution One Advanced Color module, no multi-image option One Advanced Color module, multi-image option Two Advanced Color modules, no multi-image option Two Advanced Color modules, multi-image option Error Tests Consistent error handling Performance Performance requirements Documentation Advanced Color Module documentation Relevant section(s) of SRS 3.14.2 3.14.3 3.15.1 3.15.2 Test Cases

See File Management test cases See File Management test cases ACM-02-32 ACM-02-33 ACM-06, Section I ACM-06-1 through -4 ACM-03, Section I ACM-03-1, ACM-03-10 ACM-03-2, ACM-02-11 ACM-03-3, ACM-03-12 ACM-03-4, ACM-04-13 ACM-03-5, ACM-05-14 ACM-03-6, ACM-03-15 ACM-03-7, ACM-03-16 ACM-03-8, ACM-03-17 ACM-03-9, ACM-03-18 ACM-03, Section II ACM-03-182 through -191 ACM-03, Section III Various ACM-03-193 ACM-03-193 ACM-04, Section I ACM-04-1 through -110 ACM-06, Section II ACM-06-6 through -9 ACM-06, Section IV The documents affected are not listed anywhere that I can tell ACM-06-11 through -13 ACM-06-14

3.10

3.11 3.11 3.11 3.11 3.11 3.11 3.11 3.11 3.11

3.12

3.18.6 3.18.6 3.18.6 3.18.6

3.18.7

10

13-B

Help screens

10.1

Page 2

<<Project Name & Version Here>>


Test Report
<<Date of Last Revision Here (Should match last entry below)>>

<<Authors Name Here>> <<Company/Business Unit Name Here>> Test Group

When printing this document, the Comments checkbox (via Tools-Options-Print tab) is checked so that youll get the instructions that the comments contain. You should disable this option when doing the version of the Test Report the is made publicly available. Of course, you will also remove this text.

Template Revision History (Note: to be cleared out when issue a Test Report as dont need readers seeing the history for this Template version)
Rev Date
1.0 1.1 1.2 1.3 1.4 1.5
?? Feb 1998 Oct 14, 1998 Nov. 2, 1998 Nov 3, 1998 99-Sep-03 Author Dan Gawarecki Dan G. Dan G. Dan G Lyn B Dan G.

Change Description
Original distribution Incorporate suggestions by others, & misc. additions and corrections. Added Section 1.1 Size Measurements, Title Page, & Table of Contents. Section 4.3, item 2 changed to report Actual as well as Estimate test hours. Section 3- changed Opened to Total Opened and added new Still Open, break by severity item, Made table out of information asked for in Section 4.2 Builds Changed Header Title text from Test Plan to Test Report Implemented Test Council Recommendations: 1.1, Remove item 1 as no one using PEAQ category sizes anymore 2, added more details to original items- they are now # 1-4, and 6, added item that is now #5 3, added at the time to item 6. 4.1, made into table adding Planned and Actual for Column Names. 4.3, for item #2, modified to be a table so Planned and Actual are easy to read. Added italic instructions to title page Revised 5 1st paragraph, added 2nd paragraph.

Document Location
T:\TSTGROUP\DOCS\TEMPLATES\TEST_REPORT_95_REV1-5.DOC

Test Report for <<Project Name Here>> _____________________________________________________________________________________

Table of Contents
1. OVERVIEW
1.1. Size Measurements

1
1

2. SYSTEM VERIFICATION TEST (SVT) TEST CASES 3. PROBLEM TRACKING REPORT (PTR) SUMMARY 4. OTHER METRICS
4.1. Dates 4.2. Software Builds 4.3. People & Time 4.4. Beta Test results / summary

1 1 2
2 2 2 2

5. GENERAL COMMENTS

_____________________________________________________________________________________ Page ii of 4 Nov. 4, 1998

Test Report for <<Project Name Here>> _____________________________________________________________________________________

1.

Overview

A short paragraph telling what project, including version number, this report is for, the project number and a general comment about the testing status (passed with little difficulty, had lots of problems, etc.) Hopefully the entire report, excluding any attached charts (e.g., from Section 3) is only 1-2 pages long.

1.1.

Size Measurements
Software Size Estimates vs. Actual (identify units of measure- Thousand Source Lines of Code- KSLOC, number of classes, objects, Function Points, etc).

2.

System Verification Test (SVT) Test Cases

This section records the status of Test Cases for System Verification Test. This provides some sizing of the project and helps future estimates. Feel free to record any comments about Test Cases or related issues here. Ideally, youd have an S-curve to embed in the document! 1. # Test Cases Planned (i.e., written up in plan) 2. # Test Cases Executed (i.e., attempted to run) 3. # Test Cases Passed on 1st execution attempt 4. # Test Cases Failed on 1st execution attempt 5. # Executions of Test Cases (i.e., summation of the number of times executed each test casedo this because may execute a test case more than once. This metric needed to show effort and explain why a test cycle may be longer than planned. This item could be considered optional as it is something that a mature process would provide- which Im not sure we have entirely. The other 5 items should be done first and done well before attempting to provide this metric). 6. What test cases were planned but *NOT* executed (perhaps explain why?)

3.

Problem Tracking Report (PTR) Summary

Similar to the previous Test Case section, this area records the status of PTRs. Again, feel free to record any comments about the PTRs you wish. You should be able to get charts for items #1, 2 and the data for items #3 & 4 from Tracker. 1. PTR Trendline2. Severity breakdown/distribution 3. #PTRs Total Opened 4. #PTRs Closed 5. #PTRs Still Open (breakdown by severity) 6. Any open issues still remaining at the time of release (e.g., explain why you might be shipping with an open Severity 2 PTR). Important to reference the actual PTR number(s) here.

_____________________________________________________________________________________ Page 1 of 4 Nov. 4, 1998

Test Report for <<Project Name Here>> _____________________________________________________________________________________

4.
4.1.

Other Metrics
Dates
DATE DESCRIPTION 1. 2. Date testing Started: this is the first day of Entrance Testing Date Testing Ended: this is the last day of Regression Testing. PLANNED ACTUAL

4.2.

Software Builds
VERSION 1. 2. 3. First Build done Last Build done # Builds done during testing period DATE DONE

Please fill in the 5 cells in the following table:

4.3.

People & Time


1. 2. List all those people involved in testing the product during this project. Record Estimated and Actual number of hours spent testing (this is time executing test cases, not playing around with the product or testing by exploration PLANNED Actual Hours Spent Test ACTUAL

4.4.

Beta Test results / summary


Note if there was or was not a Beta test and if so, any results (good or bad). Refer to separate Beta Test Report if available. If there is none, mention any testing customers performed.

5.

General Comments
This is a catch-all section for you to add any comments you feel important. You might reemphasize any open issues listed in section 3, major stumbling blocks in the testing process, any areas NOT tested, unique situations, etc. Mention what documents, manuals, specifications etc. that were not tested This is also your opportunity to comment on what improvements should be made (back it up with data, or at least a rationalization) that will improve product quality in future versions of this product or other products.

_____________________________________________________________________________________ Page 2 of 4 Nov. 4, 1998

9000 Ver. 7.0 Advanced Color Module


Test Report
4-28-00

Neil Bitzenhofer Datacard Worldwide Test Group

Rev Date
1.0
4-28-00

Author Neil Bitzenhofer

Change Description
Original distribution

Test Report for <<Project Name Here>> _____________________________________________________________________________________

Table of Contents
1. OVERVIEW
1.1. Size Measurements

1
1

2. SYSTEM VERIFICATION TEST (SVT) TEST CASES 3. PROBLEM TRACKING REPORT (PTR) SUMMARY 4. OTHER METRICS
4.1. Dates 4.2. Software Builds 4.3. People & Time 4.4. Beta Test results / summary

1 1 2
2 2 2 2

5. GENERAL COMMENTS

_____________________________________________________________________________________ Page ii of 5 Nov. 4, 1998

Test Report for <<Project Name Here>> _____________________________________________________________________________________

1.

Overview

This Test Report concerns the SVT Phase of testing for 9000 Version 7.0 Advanced Color Module, and includes testing performed for Color Management, even though Color Management was not released with 9000 Ver. 7.0.

1.1.

Size Measurements
The size of the software involved is unknown at the time of this writing.

2.

System Verification Test (SVT) Test Cases


1. 2. Advanced Color SVT consists of 508 test cases. 499 of those test cases have been run, and have passed. The 9 test cases that have not been run are as follows: ACM-03-193 through -196: Image Distribution test cases. No system has been set up with more than one front or more than one back Advanced Color Module. ACM-05-13: Blind Spot testing. Since the hardware is not significantly different from what it was for a High Speed Color Module, this testing has not been performed. ACM-06-10: High Speed Advanced Color Module endurance testing. The endurance of a single standalone Advanced Color Module did not seem worth testing. It is anticipated that this type of testing will be performed in a much larger system, e.g. the System Integration test system. ACM-06-11, -12, -13: These refer to 3 document reviews. Although the tester has not reviewed these documents, it is expected that various development personnel have done so.

3.

Problem Tracking Report (PTR) Summary


1. 2. 3. 4. 5. 6. 7. 8. 9. PTR Trendline- See the attachment Severity breakdown/distribution: P1 P2 P3 P4 <None> 12 49 24 1 1

#PTRs Total Opened: 87 #PTRs Closed: 86 #PTRs Still Open: #8897 (a firmware problem involving noise detected at the Card Registration sensor), of severity P3. 10. The major open issue remaining at the time of release was Color Management. This feature is no longer tied to the Advanced Color Module release, but must nevertheless be tested and is still on-going at the time of this report.

_____________________________________________________________________________________ Page 1 of 5 Nov. 4, 1998

Test Report for <<Project Name Here>> _____________________________________________________________________________________

4.
4.1.

Other Metrics
Dates
DATE DESCRIPTION 1 . 2 . Date testing Started: this is the first day of Entrance Testing Date Testing Ended: this is the last day of Regression Testing. PLANNED 9-22-99 11-2-99 ACTUAL 1-10-00 3-15-00

4.2.

Software Builds
VERSION 1 First Build done DATE DONE

Please fill in the 5 cells in the following table:

Build 69

Last Build done

Build 90

4-24-00

# Builds done during testing period

22

4.3.

People & Time


1. 2. Personnel involved in testing the Advanced Color Module were Robert Ang, Neil Bitzenhofer, Mike Hazzard and Colleen Lanhart. Actual time spent testing , based solely on number of days used, times 8 hrs. per day, times 80% load: PLANNED ACTUAL Actual Hours Spent Test 192 288

No attempt was made to add together the test hours for all 4 test personnel. This information may be available to management via time card data.

4.4.

Beta Test results / summary


There were no Beta Test sites for the Advanced Color Module.

5.

General Comments
1. One very big hindrance to this testing effort was that, on the Friday before SVT was to start, the new Print On Image Generation Error was successfully built. This feature was not included in any of the currently-existing test cases, and hence caused a complete overhaul of the associated test cases (mainly all the error test cases) and associated requirements and test case matrices. Under no circumstances should extensive new features (or perhaps features of any kind) be introduced at the very end of DVT. The color system I tested on, Continuation 2, also contained an UltraGraphix module in it that, as it turned out, never did get used for testing. Having that module there caused some holdups: - Everytime we initialized, the UltraGraphics ribbon would advance, so that several times we could not continue testing until the ribbon were replaced (since it had run out, even though never used).

2.

_____________________________________________________________________________________ Page 2 of 5 Nov. 4, 1998

Test Report for <<Project Name Here>> _____________________________________________________________________________________ - Many times cards would stick at the entrance to the UG Module due to the rollers getting dirty. 3. On the plus side, the project was tracked very well, and there seemed to be sufficient time for testing.

_____________________________________________________________________________________ Page 3 of 5 Nov. 4, 1998