TestCase Template

Test Requirements/Test Cases for<Project-Name>

<Revision> 1.0 <Date>xx-Aug-99

<Author Name> <Group Name>

Document Revision HistoryRev

Date Author Change Description

1.0 10xx -Aug- 99

Neil Bitzenhofer

Initial release of this document.

1.1 13 Aug 99

Neil Bitzenhofer

Review by Richard Cheng

1.2 3 Sep 99 Neil Bitzenhofer

Reviewed by the Test Council

2.0 10 Sep 99

Neil Bitzenhofer

Final review by Test Council

Test Requirements/Test Cases for <Project-Name>Revision 1.2.00 4/8/2023_____________________________________________________________________________________________________

Table of Contents

1. TEST REQUIREMENTS ............................................................................................................................................... 1

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

2. TEST CASES ................................................................................................................................................................ 4

2.1 DESCRIPTION ........................................................................................................................................................... 4 2.2 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

1. TEST REQUIREMENTS ...................................................................................................................................................

1.1 OBJECTIVE ...................................................................................................................................................................... 1.2 EXPLICIT REQUIREMENTS ................................................................................................................................................. 1.3 IMPLICIT REQUIREMENTS ................................................................................................................................................. 1.4 TRACEABILITY MATRIX ................................................................................................................................................... 1.5 REFERENCE DOCUMENTS ................................................................................................................................................. 1.6 DEFINITIONS AND ACRONYMS ..........................................................................................................................................

2. TEST PROCEDURES/TEST CASES ................................................................................................................................

2.1 DESCRIPTION ................................................................................................................................................................

2.2 TEST CASE TEMPLATE ................................................................................................................................................

3. APPENDIX A .....................................................................................................................................................................

3.1 SAMPLE TRACEABILITY MATRIX ............................................................................................................................

4. APPENDIX B .....................................................................................................................................................................

4.1 SAMPLE TEST PROCEDURES .....................................................................................................................................

Page ii


1. Test Requirements

1.1 ObjectiveeThe purpose of the Test Requirements section is to list ALL hardware and software test requirements, whether explicitly as determined from any relevant documents or implicitly determined from experience and product knowledge. For most projects, the documents referred to will may be the Product Definition Document, Software/Hardware Requirements Specification and perhaps the Software/Hardware Design Specification; . tThe format used to list the requirements will be that of a Requirements Matrix and associated Traceability Matricesx (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 RequirementsExplicit 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. Even if the requirement is vague, or if no method of testing the requirement comes to mind, the requirement should still be listed in the Test Requirements Matrix for several reasons: by listing it you are saying (a) I haven’t overlooked this requirement, and (b) note that I have no idea how to verify the requirement and hence it may not get tested. Frequently, the developer may be able to suggest a method of testing such requirements, or the requirement may get rephrased so as to be testable.

All explicit requirements should be listed in the Requirements Mmatrix 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. In addition, those requirements that are deemed untestable could also be listed here with an explanation as to why they are untestable.

1.3 Implicit RequirementsImplicit, 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. An example of an implicit requirement that can be overdone is, say, User Friendliness; in the absence of very specific guidelines for such requirements, it is probably best to ignore them.

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 RequirementsTraceability MatrixThis section contains the Requirements Matrix; a template for such a matrix is shown below. The columns of the RequirementsTraceability Matrix have the following meanings:

Page 1


Requirement number: : Some sort of identifier for the requirement – use whatever makes sense in the context.

Requirement name: : A description of the requirement.Relevant section: The section of the specified document where the requirement is described.

If more than one document is used to specify 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.

Notes: Indications of added or removed comments could be listed here, along with any other comments relevant to this requirement.the Test Case identifiers that actually test this requirement. Untestable requirements would also be designated here.

An example of an actual Requirements Matrix along with the associated Traceability Matrices is shown in Appendix A.

Requirement number

Requirement name Relevant section(s) of SRS

Notes

1 Group or Area #11-A Requirement 1 x.x.x or “Imp”1-B Requirement 2 x.x.x or “Imp”1-C Requirement 3 x.x.x or “Imp”

2 Group or Area #22-A Requirement 1 x.x.x or “Imp”2-B Requirement 2 x.x.x or “Imp”2-C Requirement 3 x.x.x or “Imp”

etc.

1.5 Test Case MatrixThis 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:

Test Case ID: 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

Page 2


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 description S

PE C

F U N C TIO N

C O M P A T

D O C UMENT

NETWORK

U S E R

Date last attempted / PTR #

Date Complete

Test Module ID #1

Test Module name

Test case ID #1Test case ID #2Test case ID #3

Test Module ID #2

Test Module name

Test case ID #1Test 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 MatrixThe 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 Test Case ID 1

Test Case ID 2

Test Case ID 3

Test Case ID 4

Requirement 1 X Requirement 2 X X Requirement 3 X

1.7 Reference DocumentsDescribe in full all documents used for determining requirements.

Page 3


1.8 Reference DocumentsDescribe in full all documents used for determining requirements.

1.9 Definitions and AcronymsList any technical terms or acronyms used in the document, along with their meanings.Examples for this document: HRS Hardware Requirements Specification

SRS Software Requirements SpecificationTM Traceability Matrix

Page 4


2. Test Procedures/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.A Test Procedure is developed for each of the principal groups or test areas specified in the TM. Within each Test Procedure, test cases are designed and written to test or verify the various requirements in that Test Procedure’s group or area.

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. I; identifiers should follow a consistent pattern within a Test CasesProcedure, and a similar consistency should apply across Test ModulesProcedures written for the same project. See Appendix B for an example.

Purpose: The purpose of the Test Case, usually to verify a specific requirement.

Owner: The person(s) or department responsible for keeping the Test Cases accurate.

Expected Results: 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.

Test Data: Any required data input for the Test Case.

Test Tools: Any specific or unusual tools or utilities required for the execution of this Test Case.

Dependencies: 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.

Initialization: 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.

Description: 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,e. further narrative, or whatever is most appropriate to the type of testing taking place.

Expected Results: Describe the expected results and outputs from this Test Case.

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 5


3. Appendix A

4.

[5.] Sample Traceability Matrix

5.[6.]

[7.] The following matrix is a portion of the Requirements Traceability Matrix used in the Advanced Color Module project.

6.[8.] Requirement number


Notes

1 Hardware Setup selections ACM-05, PART I1-A SSC-VerX Module Emulation File 3.3.1 ACM-05-1 through -181-B HSC Module Emulation File 3.3.1 ACM-05-19 and -201-C AC Module Emulation File 3.3.2, 3.3.3 ACM-05-21 and -22

2 Extended UltraGraphics Command Language ACM-01, PART II2-A Horizontal and vertical positioning 3.4.1.12-B Flip 3.4.1.22-C Units of measure 3.4.1.32-D Rotation 3.4.1.42-E Scaling 3.4.1.52-F Color types: RGB, Lab(d50), Lab(d65) 3.4.1.62-G Border Color and Type Imp2-H Color specification (Command CST) 3.4.1.62-I Sharpening 3.4.1.72-J Half-toning 3.4.1.82-K Horizontal and vertical scaling 3.4.1.92-L Background color 3.4.1.102-M Foreground color 3.4.1.112-N Opacity 3.4.1.122-O Z-order 3.4.1.132-P Image profile 3.4.1.142-Q Color filter specification 3.4.1.152-R Security text Imp

3 ColorPrint card setup overrides3-A Overrides 3.5 All card setup overrides are being

tested by the UltraGraphics/CIG test cases.

4 Version A and B Header compatibility ACM-01, PART I4-A Version A, embedded 3.6 ACM-01-16 through -304-B Version A, file name 3.6 ACM-01-1 through -15

Page 6


Requirement number


Notes

4-C Version B, embedded 3.6 ACM-01-47 through -624-D Version B, file name 3.6 ACM-01-31 through -46

Notes: i. ACM-01 and ACM-05 are the names of Test Procedures. ii. ACM-01-16, for example, is one Test Case identifier in Test Procedure ACM-01. iii. The Security text UltraGraphics Command is an example of an implicit requirement. It is, perhaps mistakenly, not mentioned in the SRS, yet we know that color photos can have Security text around them.

7.[9.] Appendix B

Page 7


7.1[9.1] Sample Test Procedures

7.2[9.2]

[9.3] Test Procedures ACM-01 and ACM-05 are from Advanced Color Module testing; Test Procedure CSMLIB-02 is from the CSM Test Library.

7.3[9.4]

7.4[9.5]

[9.6] Test Procedure ACM-01 Card Production

7.5[9.7]

7.6[9.8] PART I: Version A and B Compatibility

7.7[9.9]

7.8[9.10] Test Case ACM-01-01 Version A and B Compatibility

7.9[9.11] through

7.10[9.12] Test Case ACM-01-62

7.11[9.13]

7.12[9.14] Purpose: Verify that the Advanced Color Module, using the Common Image Generator, can still process previous data formats, viz. those that use Version A or Version B headers, whether of Type C or N.

7.13[9.15]

7.14[9.16] Owner: Test/Tools Group

7.15[9.17]

7.16[9.18] Test Data: Datafile fruit.dat, Data Setup color.dsu, Device Setup uf062.dis (see WG3\VOL1 : \bodmer\data)

7.17[9.19]

7.18[9.20] Test Tools: None

Page 8


7.19[9.21]

7.20[9.22] Dependencies: None

7.21[9.23]

7.22[9.24] Initialization: None

7.23[9.25]

7.24[9.26] Description: The specified datafile is inserted on the 9000 using the designated setups; this will result in 4 jobs, designated below as 2.Ann (15 cards total), 2.Bnn (15 cards total), 2.Cnn (16 cards total) and 2.Dnn (16 cards total). The 4 jobs are then produced.

7.25[9.27]

7.26[9.28] Expected Results: 62 cards are produced with correct image characteristics.

7.27[9.29]

7.28[9.30] The characteristics of each of the 62 images is as follows:

7.29[9.31]

7.30[9.32] Test Type Ver Border/ID String ID Rotation Units Offsets (x,y) Text Scale Scale

Type Rad, Fade Red, Grn, Blu in 0.00001 inches

Type Type (x,y)

2.A1 N A A 001, 001 196, 000, 038 (Red) N/A 0-no flip in 100, 100 0 N/A N/A2.A2 N A A 100, 100 000, 135, 064 (Grn) N/A 90-no flip in 1000, 100 1 N/A N/A2.A3 N A A 200, 200 028, 011, 090 (Blu) N/A 180-no flip in 5000, 100 2 N/A N/A2.A4 N A A 300, 300 230, 127, 020 (Org) N/A 270-no flip in 10000, 100 3 N/A N/A2.A5 N A B 001, N/A 255, 235, 000 (Yel) N/A 0-flip in 15000, 100 4 N/A N/A2.A6 N A B 100, N/A 150, 095, 150 (Vio) N/A 90-flip in 20000, 100 1 N/A N/A2.A7 N A B 200, N/A 000, 000, 000 (Blk) N/A 180-flip in max-100,

1002 N/A N/A

2.A8 N A B 300, N/A 255, 255, 255 (Wht) N/A 270-flip in 100, 1000 3 N/A N/A2.A9 N A B 050, N/A 196, 000, 038 (Red) N/A 0-no flip in 100, 3000 4 N/A N/A2.AA N A B 050, N/A 255, 235, 000 (Yel) N/A 0-flip in 100, 6000 1 N/A N/A2.AB N A B 050, N/A 197, 000, 103 (Mag) N/A 0-no flip in 100, 9000 2 N/A N/A2.AC N A B 050, N/A 000, 160, 221 (Cyn) N/A 0-flip in 100, max-

1003 N/A N/A

(This is only part of the table — there are 50 more entries)

Test Procedure ACM-05 Hardware

Abbreviations used in this Test Procedure: HSCM (Existing) High Speed Module

Page 9


SSCM (Existing) Standard Speed Module HSACM High Speed Advanced Color Module

SSACM Standard Speed Advanced Color Module

PART I: Hardware Setups

Test Case ACM-05-1 Hardware Setup for SSACM: SSC-VerX Module Emulation File — Less Blue

Purpose: Verify operation of the Standard Speed Module Emulation file on an SSACM. Use Color Table “Less_Blue”.

Owner: Test/Tools Group

Test Data: Datafile <TBD> plus a set of cards produced using the same datafile on an SSCM.

Test Tools: None

Dependencies: None

Initialization: None

Description: Color Table “Less_Blue” is selected along with Module Emulation file SSC-VerX. Datafile <TBD> is then produced on the SSACM and the output compared with the same output from an

SSCM.

Expected Results: The card(s) produced in this test case have noticeably less blue color than the baseline set of images.

Test Case ACM-05-2 Hardware Setup for HSACM: SSC-VerX Module Emulation File — Less Blue

Purpose: Verify operation of the Standard Speed Module Emulation file on an HSACM. Use Color Table “Less_Blue”.

Owner: Test/Tools Group

Test Data: Datafile <TBD> plus a set of cards produced using the same datafile on an SSCM.

Test Tools: None

Dependencies: None

Initialization: None

Description: Color Table “Less_Blue” is selected along with Module Emulation file SSC-VerX. Datafile <TBD> is then produced on the HSACM and compared with the same output from an SSCM.

Expected Results: The card(s) produced in this test case have noticeably less blue color than the baseline set of images.

Test Procedure CSMLIB-02 Operation of Utilities | Security

Test Case CSMLIB-02-1 Privileges for User ‘SYSTEM’

Page 10


Purpose: Verify that user ‘SYSTEM’ has all access privileges, including submenu selections and button availability on main menu windows.

Owner: CSM Test Group

Test Data: None

Test Tools: None

Dependencies: All CSM Options and Specials have been installed.

Initialization: The CSM is at the main menu screen.

Description: After logging on to the CSM as user SYSTEM/MANAGER, the availability of each main menu item, each submenu item, and each main window button is verified.

Expected Results: When logged on as user SYSTEM, all menus and submenus are selectable.

CSMLIB-02-1 CSMStep 1: Select 6. Utilities and 4. LogoffExpected result The Logon window appears.Step 2: Type in <User Name> ‘SYSTEM’ and <Password> ‘MANAGER’ and press the Enter keyExpected result The CSM main menu window appears and is empty. All main menu selections are

available.Step 3: Click on 1. Production Expected result The Options, Exit, Create, Message and Help buttons are available for selection.Step 4: Click on the Exit buttonExpected result Control returns to the blank CSM main menu screen.Step 5: Click on 2. Data In, then select ‘DISKIN’ in the <Input Devices> list box Expected result The Begin, Exit and Help buttons are available for selection.Step 6: Press ALT + x (Exit) on the keyboardExpected result Control returns to the CSM main menu screen.Step 7: Press ALT + 3 (Status) on the keyboardExpected result The Device Status window appears with the Exit and Help buttons available for selection.Step 8: Press ALT + x (Exit) on the keyboardExpected result Control returns to the CSM main menu screen.Step 9: Click on 4. Reports, and select Data Input Summary in the <Report Templates> list boxExpected result The Generate, Generate and Print, Setup, Exit and Help buttons are available for selection.Step 10: If a file is listed in the <Report Files> list box, click on it Expected result The View, Print, and Erase buttons become available for selection.Step 11: Click on the Exit buttonExpected result Control returns to the CSM main menu screen.Step 12: Click on 5. Setup Expected result All submenu selections are available.Step 13: Press ESC on the keyboardExpected result Control returns to the CSM main menu screen, though main menu selection 5. Setup still

has the focus.Step 14: Click on 6. Utilities Expected result All five submenu selections are available.Step 15: Press ESC on the keyboardExpected result Control returns to the CSM main menu screen, though main menu selection 6. Utilities still

has the focus.

Page 11


CSMLIB-02-1 CSMStep 16: Click on 7. Options Expected result All three submenu selections are available.Step 17: Press ALT + F4 on the keyboardExpected result Control returns to the CSM main menu screen.

Page 12