Professional Documents
Culture Documents
Contents
1.0
1.1. 1.2. 1.3. 1.4.
INTRODUCTION
Objective Project Description Process Tailoring Referenced Documents
3
3 3 3 3
ASSUMPTIONS/DEPENDENCIES TEST REQUIREMENTS TEST TOOLS RESOURCE REQUIREMENTS TEST SCHEDULE RISKS/MITIGATION METRICS
3 3 4 4 4 4 4 5 6
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
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
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
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
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
2-F
Z-order
3.4.1.8
2-G 2-H
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.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.12
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
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
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.
Page ii
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
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
Notes
Test Case ID
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
Date Complete
Page 2
Test Case ID
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
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.
Page 3
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.
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.
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
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
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
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
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.
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
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
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
2-F
Z-order
3.4.1.8
2-G 2-H
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.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.12
3.18.7
10
13-B
Help screens
10.1
Page 2
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
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
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.
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.
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.
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
4.3.
4.4.
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.
Rev Date
1.0
4-28-00
Change Description
Original distribution
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
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.
3.
#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.
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
Build 69
Build 90
4-24-00
22
4.3.
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.
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.
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.