Module 30 - T321
T321: Applying Your Test Plan to TMDD Standard
HTML of the Student Supplement
(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)
(Extended Text Description: Large graphic cover page with dark blue background with the title in white letters "T321: Applying Your Test Plan to TMDD Standard." At the middle left is the "Standards ITS Training" logo with a white box and letters in blue and green. The words "Student Supplement" and "RITA Intelligent Transportation Systems Joint Program Office" in white lettering are directly underneath the logo. Three light blue lines move diagonally across the middle of the blue background.)
T321: Applying Your Test Plan to TMDD Standard
Table of Contents
Introduction/Purpose - 2
Samples/Examples - 2
Reference to Other Standards - 8
Glossary - 8
References - 9
Study Questions - 10
Module Description
The module includes a brief description of the TMDD Standard with materials and examples that describe how to develop test documentation for the purposes of performing system interface validation and verification. This module covers the role of testing including: compliance, manufacturing and acceptance tests, and verification and validation as part of the testing and quality life cycle expressed in the systems engineering “Vee” model. The “Vee” model is depicted in Figure 1.
(Extended Text Description: This is a figure depicting the life cycle of a system and the relationships between each process (or step) of a system life cycle. The figure is laid like the letter "V", thus it is called the "VEE" diagram. Time progresses as we move from the left side of the "VEE" to the right side of the "VEE". Starting from the upper left hand corner of the "VEE" and moving right and down, the processes are Regional Architecture(s), Feasibility Study / Concept Exploration, Concept of Operations, System Requirements, High-Level Design, and Detailed Design. These processes on the left side of the "VEE" is part of the Decomposition and Definition step. At the bottom of the "VEE" is the Software / Hardware Development Field Installation Implementation process, which is called the Development Process step. Moving up the right side of the "VEE", the processes are the Unit/Device Testing, Subsystem Verification, System Verification and Deployment, System Validation, Operations and Maintenance, Changes and Upgrades, and finally Retirement/Replacement. These processes on the right side of the "VEE" is called the Integration and Recomposition step. For the completion of each process, starting with the Concept of Operations to the completion of the System Verification and Deployment process, a document is produced or some type of formal approval is expected before continuing onto the next process. Verification or validation is expected between the processes on the left side of the "VEE" and the right side "VEE", and are indicated by dotted lines with arrows on the end between them. There is a dotted line between the Concept of Operations on the left and the System Validation on the right, labeled System Validation Plan. This indicates that testing of the Concept of Operations is performed in the System Validation Plan during the System Validation process. The next dotted line is between the Systems Requirements on the left and System Verification & Deployment on the right, and the line is labeled System Verification Plan, or in parentheses, System Acceptance. The next dotted line is between the High-Level Plan and the Subsystem Verification and it is labeled Subsystem Verification Plan, or in parentheses, Subsystem Acceptance. The last dotted line is between the Detailed Design and the Unit/Device Testing, and it is labeled Unit/Device Test Plan.)
Figure 1. Systems Engineering "Vee" Diagram
Introduction/Purpose
This module assists user agencies to create a test plan specific to their TMDD v3 Standard based system interface. Prior to developing such a test plan, the user is expected to be knowledgeable of the TMDD v3 Standard and testing methodologies. This module covers material related to elements of the TMDD Standard required to apply test plans to verify that an agency’s product or system meets design specifications and other requirements of the TMDD Standard, while following standard testing methodologies discussed in the plan and in IEEE Std 829 IEEE Standard for Software Test Documentation.
The focus of this course is on development of test documentation to test for TMDD system interface compliance. During the test phase, the system interface implementation is tested against the requirements that were developed for the project. A Requirements to Test Case Traceability Matrix (RTCTM) will be used to verify that the software being implemented fulfills all of the system interface requirements. To conduct the system interface test phase, the interface must be isolated from the hardware and central system software. TMDD testing focuses on the compliance with the requirements and system interface specification and not the software implementation. The test documentation developed is used to guide and document the processes used to verify compliance with the requirements and specification to ensure that the dialogs and data content of message exchanges are implemented correctly.
1. Samples/Examples
This section contains an example that traces a specific user need, Need to Share DMS Inventory, to the requirements that satisfies that user need, then to the (standard) design that will fulfill those requirements. An example Requirements to Test Case Matrix is then created, along with portions of an example test design specification, test case specifications and test procedure specifications.
From TMDD v3.03 Volume I, the example, completed NRTM in Table 1 depicts the following for User Need 2.3.5.4.1, Need to Share DMS Inventory:
Table 1. Example NRTM
| Requirement ID | Requirement | Conformance | Support | Other Requirements |
|---|---|---|---|---|
| Dialogs | ||||
| 3.3.5.5.1.1 | Send DMS Inventory Information Upon Request | M | Yes* | The owner center shall respond within ___ (100 ms – 1 hour; Default = 1 minute) after receiving the request. See Section 3.4.2. |
| 3.3.5.5.1.2 | Publish DMS Inventory Information | Subscription:O | Yes / No* / NA | The owner center shall begin sending the updated response message within ___ (100 ms – 24 hours; Default = 15 minutes) after the information is updated in the owner center. See Section 3.4.1. |
| 3.3.5.5.1.3 | Subscribe to DMS Inventory Information | Subscription:O | Yes / No* / NA | |
| Request Message | ||||
| 3.3.5.1.1.1 | Contents of Device Information Request | M | Yes* | |
| 3.3.5.1.1.1.1 | Required Device Information Request Content | M | Yes* | |
| 3.3.5.1.1.1.2.1 | Authentication - Device Information (DeviceAuth) | O | Yes / No* | |
| 3.3.5.1.1.1.2.1.1 | Operator Identifier - Device Information | DeviceAuth:O | Yes / No* / NA | |
| 3.3.5.1.1.1.2.2 | External Center Organization - Device Information | O | Yes / No* | |
| 3.3.5.1.1.1.3.1 | Device Identifier Filter | O | Yes / No* | |
| 3.3.5.1.1.1.3.2 | Roadway Network Identifier Filter | O | Yes / No* | |
| 3.3.5.1.1.1.3.3 | Link Identifier Filter | O | Yes / No* | |
| 3.3.5.1.1.1.3.4 | Route Designator Filter | O | Yes / No* | |
| 3.3.5.1.1.1.3.5 | Linear Reference Filter | O | Yes / No* | |
| 3.3.5.5.1.4 | Contents of the DMS Inventory Request | M | Yes* | |
| Response Message | ||||
| 3.3.5.1.2.1 | Contents of the Device Inventory Header | M | Yes* | |
| 3.3.5.1.2.1.1 | Required Device Inventory Content | M | Yes* | |
| 3.3.5.1.2.1.2.1 | Restrictions - Device Inventory | O | Yes / No* | |
| 3.3.5.1.2.1.2.2 | Device Description | O | Yes* / No | |
| 3.3.5.1.2.1.2.3 | Device Control Type | O | Yes / No* | |
| 3.3.5.1.2.1.2.4 | Controller Description | O | Yes / No* | |
| 3.3.5.1.2.1.2.5 | Roadway Network Identifier - Device Inventory | O | Yes / No* | |
| 3.3.5.1.2.1.2.6 | Node Identifier - Device Inventory | O | Yes / No* | |
| 3.3.5.1.2.1.2.7 | Node Name - Device Inventory | O | Yes / No* | |
| 3.3.5.1.2.1.2.8 | Link Identifier - Device Inventory | O | Yes / No* | |
| 3.3.5.1.2.1.2.9 | Link Name - Device Inventory | O | Yes / No* | |
| 3.3.5.1.2.1.2.10 | Link Direction - Device Inventory | O | Yes / No* | |
| 3.3.5.1.2.1.2.11 | Linear Reference - Device Inventory | O | Yes / No* | |
| 3.3.5.1.2.1.2.12 | Linear Reference Version | O | Yes / No* | |
| 3.3.5.1.2.1.2.13 | Route Designator - Device Inventory | O | Yes / No* | |
| 3.3.5.1.2.1.2.14 | Device Uniform Resource Locator (URL) (DeviceURL) | O | Yes / No* | |
| 3.3.5.1.2.1.2.15 | Device URL Reference Medium | DeviceURL:O | Yes / No* / NA | |
| 3.3.5.1.2.1.2.16 | Device Inventory Date and Time Change Information | O | Yes / No* | |
| 3.3.5.5.1.5 | Contents of the DMS Inventory Information | M | Yes* | |
| 3.3.5.5.1.5.1 | Required DMS Inventory Content | M | Yes* | |
| 3.3.5.5.1.5.2.1 | Sign Technology | O | Yes / No* | |
| 3.3.5.5.1.5.2.2 | Sign Pixel Height | O | Yes / No* | |
| 3.3.5.5.1.5.2.3 | Sign Pixel Width | O | Yes / No* | |
| 3.3.5.5.1.5.2.4 | Sign Height | O | Yes / No* | |
| 3.3.5.5.1.5.2.5 | Sign Width | O | Yes / No* | |
| 3.3.5.5.1.5.2.6 | Character Pixel Height | O | Yes / No* | |
| 3.3.5.5.1.5.2.7 | Character Pixel Width | O | Yes / No* | |
| 3.3.5.5.1.5.2.8 | DMS Beacon Type | O | Yes / No* | |
| 3.3.5.5.1.5.2.9 | Vertical Border | O | Yes / No* | |
| 3.3.5.5.1.5.2.10 | Horizontal Border | O | Yes / No* | |
| 3.3.5.5.1.5.2.11 | Sign Vertical Pixel Pitch | O | Yes / No* | |
| 3.3.5.5.1.5.2.12 | Sign Horizontal Pixel Pitch | O | Yes / No* | |
| 3.3.5.5.1.5.2.13 | Maximum Number of Pages | O | Yes / No* | |
| 3.3.5.5.1.5.2.14 | Maximum Message Length | O | Yes / No* | |
| 3.3.5.5.1.5.2.15 | Color Scheme | O | Yes / No* | |
| 3.3.5.5.1.5.2.16 | MULTI Tags Supported | O | Yes / No* | |
| Error Report Message | ||||
| 3.3.1.4.1 | Contents of the Error Report | M | Yes* | |
| 3.3.1.4.1.1 | Required Error Report Contents | M | Yes* | |
| 3.3.1.4.1.2.1 | Restrictions - Error Report | O | Yes / No* | |
(Extended Text Description: Please note that for Table 1, the original example table had either "Yes" or "No" highlighted in each row of column Support. The higlighted items are designated with an asterisk *.)
For this example, requirement id 3.3.5.1.2.1.2.2, Device Description, is the only optional requirement that was selected for this test example. This completed NRTM can also be used to indicate the test items to be tested in a Test Design Specification.
Based on the requirements selected, Table 2 depicts the (standard) design that will fulfill each requirement according to the TMDD Standard.
Table 2. Example RTM
| Req ID (Vol. I) | Requirement | Dialog | DC Type | Definition Class Name | DC ID (Vol. II) | Data Concept Instance Name |
|---|---|---|---|---|---|---|
| 3.3.1.4.1 | Contents of the Error Report | Message | errorReportMsg | 3.2.3.3 | errorReportMsg | |
| 3.3.1.4.1.1 | Required Error Report Contents | data-frame | organizationInformation | 3.3.16.3 | organization-information | |
| 3.3.1.4.1.1 | Required Error Report Contents | data-frame | organizationInformation | 3.3.16.3 | organization-requesting | |
| 3.3.1.4.1.1 | Required Error Report Contents | data-element | error-report-code | 3.4.3.1 | error-code | |
| 3.3.1.4.1.1 | Required Error Report Contents | data-element | informationalText | 3.4.3.2 | error-text | |
| 3.3.5.1.1.1 | Contents of Device Information Request | Message | deviceInformationRequestMsg | 3.2.5.4 | deviceInformationRequestMsg | |
| 3.3.5.1.1.1.1 | Required Device Information Request Content | data-frame | organizationInformation | 3.3.16.3 | organization-information | |
| 3.3.5.1.1.1.1 | Required Device Information Request Content | data-element | device-type | 3.4.5.15 | device-type | |
| 3.3.5.1.1.1.1 | Required Device Information Request Content | data-element | device-information-type | 3.4.5.7 | device-information-type | |
| 3.3.5.1.2.1 | Contents of the Device Inventory Header | data-frame | deviceInventoryHeader | 3.3.5.8 | deviceInventoryHeader | |
| 3.3.5.1.2.1.1 | Required Device Inventory Content | data-frame | organizationInformation | 3.3.16.3 | organization-information | |
| 3.3.5.1.2.1.1 | Required Device Inventory Content | data-element | organization-resource-identifier | 3.4.16.8 | device-id | |
| 3.3.5.1.2.1.1 | Required Device Inventory Content | data-frame | geoLocation | 3.6.9.4 | device-location | |
| 3.3.5.1.2.1.1 | Required Device Inventory Content | data-element | organization-resource-name | 3.4.16.9 | device-name | |
| 3.3.5.1.2.1.2.2 | Device Description | data-element | organization-resource-name | 3.4.16.9 | device-description | |
| 3.3.5.5.1.1 | Send DMS Inventory Information Upon Request | 2.4.1 | Dialog | dlDMSInventoryRequest | 3.1.6.1 | dlDMSInventoryRequest |
| 3.3.5.5.1.4 | Contents of the DMS Inventory Request | Message | deviceInformationRequestMsg | 3.2.5.4 | deviceInformationRequestMsg | |
| 3.3.5.5.1.5 | Contents of the DMS Inventory Information | Message | dMSInventoryMsg | 3.2.6.4 | dMSInventoryMsg | |
| 3.3.5.5.1.5.1 | Required DMS Inventory Content | data-frame | deviceInventoryHeader | 3.3.5.8 | device-inventory-header | |
| 3.3.5.5.1.5.1 | Required DMS Inventory Content | data-element | dmsSignType | 3.6.3.35 | dms-sign-type |
Based on the requirements selected in Table 1, develop a Requirements to Test Case Traceability Matrix (RTCTM). An example RTCTM is shown in Table 3.
Table 3. Example RTCTM
| Req ID (Vol. I) | Requirement | Test Case ID | Test Case Title |
|---|---|---|---|
| 3.3.1.4.1 | Contents of the Error Report | ||
| TC-Support-01 | TC-ErrorReport | ||
| 3.3.1.4.1.1 | Required Error Report Contents | ||
| TC-Support-01 | TC-ErrorReport | ||
| 3.3.5.1.1.1 | Contents of Device Information Request | ||
| TC-Device-01 | TC-DevInformRequest-NoError | ||
| TC-Device-02 | TC-DevInformRequest-Error | ||
| 3.3.5.1.1.1.1 | Required Device Information Request Content | ||
| TC-Device-01 | TC-DevInformRequest-NoError | ||
| TC-Device-02 | TC-DevInformRequest-Error | ||
| 3.3.5.1.2.1 | Contents of the Device Inventory Header | ||
| TC-Device-03 | TC-DeviceInventory-NoError | ||
| TC-Device-04 | TC-DeviceInventory-Error | ||
| 3.3.5.1.2.1.1 | Required Device Inventory Content | ||
| TC-Device-03 | TC-DeviceInventory-NoError | ||
| TC-Device-04 | TC-DeviceInventory-Error | ||
| 3.3.5.1.2.1.2.2 | Device Description | ||
| TC-Device-03 | TC-DeviceInventory-NoError | ||
| TC-Device-04 | TC-DeviceInventory-Error | ||
| 3.3.5.5.1.1 | Send DMS Inventory Information Upon Request | ||
| TC-DMS-01 | TC-DMSInventory-NoError | ||
| TC-DMS-02 | TC-DMSInventory-Error | ||
| 3.3.5.5.1.4 | Contents of the DMS Inventory Request | ||
| TC-DMS-01 | TC-DMSInventory-NoError | ||
| TC-DMS-02 | TC-DMSInventory-Error | ||
| 3.3.5.5.1.5 | Contents of the DMS Inventory Information | ||
| TC-DMS-01 | TC-DMSInventory-NoError | ||
| TC-DMS-02 | TC-DMSInventory-Error | ||
| 3.3.5.5.1.5.1 | Required DMS Inventory Content | ||
| TC-DMS-01 | TC-DMSInventory-NoError | ||
| TC-DMS-02 | TC-DMSInventory-Error | ||
The example RTCTM can then become part of a Test Design Specification. An example Test Design Specification is shown in Table 4.
Table 4. Example Test Design Specification
| Test Design Specification | |||||
|---|---|---|---|---|---|
| ID: TD-DMS-01 | Title: Need to Share DMS Inventory | ||||
| Approach Refinement: | Automated test scripts will be used Communications configuration tables | ||||
| Features to be Tested | Test Identification | ||||
| ID | Title | ID | Title | ||
| 3.3.1.4.1 | Contents of the Error Report | ||||
| TC-Support-01 | TC-ErrorReport | ||||
| 3.3.1.4.1.1 | Required Error Report Contents | ||||
| TC-Support-01 | TC-ErrorReport | ||||
| 3.3.5.1.1.1 | Contents of Device Information Request | ||||
| TC-Device-01 | TC-DevInformRequest-NoError | ||||
| TC-Device-02 | TC-DevInformRequest-Error | ||||
| 3.3.5.1.1.1.1 | Required Device Information Request Content | ||||
| TC-Device-01 | TC-DevInformRequest-NoError | ||||
| TC-Device-02 | TC-DevInformRequest-Error | ||||
| 3.3.5.1.2.1 | Contents of the Device Inventory Header | ||||
| TC-Device-03 | TC-DeviceInventory-NoError | ||||
| TC-Device-04 | TC-DeviceInventory-Error | ||||
| 3.3.5.1.2.1.1 | Required Device Inventory Content | ||||
| TC-Device-03 | TC-DeviceInventory-NoError | ||||
| TC-Device-04 | TC-DeviceInventory-Error | ||||
| 3.3.5.1.2.1.2.2 | Device Description | ||||
| TC-Device-03 | TC-DeviceInventory-NoError | ||||
| TC-Device-04 | TC-DeviceInventory-Error | ||||
| 3.3.5.5.1.1 | Send DMS Inventory Information Upon Request | ||||
| TC-DMS-01 | TC-DMSInventory-NoError | ||||
| TC-DMS-02 | TC-DMSInventory-Error | ||||
| 3.3.5.5.1.4 | Contents of the DMS Inventory Request | ||||
| TC-DMS-01 | TC-DMSInventory-NoError | ||||
| TC-DMS-02 | TC-DMSInventory-Error | ||||
| 3.3.5.5.1.5 | Contents of the DMS Inventory Information | ||||
| TC-DMS-01 | TC-DMSInventory-NoError | ||||
| TC-DMS-02 | TC-DMSInventory-Error | ||||
| 3.3.5.5.1.5.1 | Required DMS Inventory Content | ||||
| TC-DMS-01 | TC-DMSInventory-NoError | ||||
| TC-DMS-02 | TC-DMSInventory-Error | ||||
| Feature Pass-Fail Criteria | This test design is passed if: 1) all test cases are passed; and 2) the data content of dialog responses are verified to be correct against the TMDD XML schema. | ||||
An example Test Case Specification is provided in Table 5.
Table 5. Example Test Case Specification
| Test Case Specification | |
|---|---|
| ID: TC-DMS-01 | Title: TC-DMSInventory-NoError |
| Test Items |
|
| Input Specifications | TCI-DMS-01 - Need to Share DMS Inventory Inputs (No Error) |
| Output Specifications |
TCO-DMS-01 - Need to Share DMS Inventory Outputs (No Error) Perform TPS-DMS-01 |
| Environmental Needs | No additional needs outside of those specified in the test plan |
| Special Procedure Requirements | None |
| Intercase Dependencies | None |
Table 6. Example Test Procedure Specification
| Test Procedure Specification | ||||||
|---|---|---|---|---|---|---|
| ID: TPS-DMS-01 | Title: Need to Share DMS Inventory Procedures | |||||
| Purpose | This test procedure verifies that the dlDMSInventoryRequest dialog of an Owner Center system interface is implemented properly. It tests when a deviceInformationRequestMsg is sent to an owner center, that the owner center responds with an dMSInventoryMsg response message. | |||||
| Special Requirements | None | |||||
| Preconditions | ||||||
|
1. Verify that the XML Request Message is valid against Project XML Schema 2. Verify that the WSDL for the Dialog to be tested is correct |
||||||
| Step | Test Procedure | Results | References | |||
| 1 | CONFIGURE: Determine the organization identifier, device identifier, location, name, and type of the dynamic message sign (per the Owner Center's database) being requested from the Owner Center. RECORD that information as, respectively: organization_id, dms_id, dms_location, dms_name, dms_type | |||||
| 2 |
SETUP: Verify the deviceInformationRequestMsg inputs are: >organization-id = "Center5" >device-type = "dynamic-message-sign (3)" >device-information-type = "device-inventory (1)" |
Pass / Fail (Req 3.3.5.5.1.4) | TCI-DMS-01 TMDD Vol. II (3.2.5.4) | |||
| 3 | SETUP: Start HTTP Client | |||||
| 4 | Load XML deviceInformationRequestMsg | TMDD Vol. II (3.2.5.4) | ||||
| 5 | Send XML deviceInformationRequestMsg to Owner Center | Pass / Fail (Req 3.3.5.5.1.1) | TMDD Vol. II (3.1.6.1) | |||
| 6 | Receive XML dMSInventoryMsg from Owner Center | Pass / Fail (Req 3.3.5.5.1.1) | TMDD Vol. II (3.1.6.1) TMDD Vol. II (3.2.6.4) | |||
| 7 | Log XML dMSInventoryMsg from Owner Center to a file. | |||||
| 8 | Verify that the saved dmsInventoryMsg file validates against the TMDD XML Schema. | Pass / Fail (Req 3.3.5.5.1.5) | ||||
| 9 |
VERIFY that the XML dMSInventoryMsg contains only the following data elements, and each has a valid value: >organization-id >device-id >device-location >device-name >dms-sign-type |
Pass / Fail (Req 3.3.5.5.1.5) | TCO-DMS-01 TMDD Vol. II (3.2.6.4) | |||
| 10 | VERIFY that the RESPONSE VALUE for organization-id is equal to organization_id. | Pass / Fail (Req 3.3.5.5.1.5.1) | TCO-DMS-01 TMDD Vol. II (3.3.5.8) | |||
| 11 | VERIFY that the RESPONSE VALUE for device-id is equal to dms_id. | Pass / Fail (Req 3.3.5.5.1.5.1) | TCO-DMS-01 TMDD Vol. II (3.3.5.8) | |||
| 12 | VERIFY that the RESPONSE VALUE for device-location is equal to dms_location. | Pass / Fail (Req 3.3.5.5.1.5.1) | TCO-DMS-01 TMDD Vol. II (3.3.5.8) | |||
| 13 | VERIFY that the RESPONSE VALUE for device-name is equal to dms_name. | Pass / Fail (Req 3.3.5.5.1.5.1) | TCO-DMS-01 TMDD Vol. II (3.3.5.8) | |||
| 14 | VERIFY that the RESPONSE VALUE for dms-sign-type is equal to dms_type. | Pass / Fail (Req 3.3.5.5.1.5.1) | TCO-DMS-01 TMDD Vol. II (3.6.3.35) | |||
| Test Procedure Results | ||||||
| Tested By: | Test Date: | Pass / Fail | ||||
| Test Notes: | ||||||
2. Reference to Other Standards
- IEEE 829-2008 - IEEE Standard for Software and System Test Documentation, IEEE, July 18, 2008.
- NTCIP 2304: Application Profile for DATEX-ASN (AP-DATEX) v01.07, AASHTO/ITE/NEMA, June 20, 2001.
- NTCIP 2306: Application Profile for XML Message Encoding and Transport in ITS Center-to-Center Communications, version v01, AASHTO/ITE/NEMA, December 2008.
3. Glossary
Additional descriptions/abbrs used primarily in the module.
| Term | Definition |
|---|---|
| Boundary Testing | A test that verifies the System Under Test reacts properly to error conditions. |
| Requirements To Test Cases Traceability Matrix | A matrix that defines the traceability from a requirements to the associated test case. |
| Risk | A subjective estimate of the probability of an error occurring and the amount of damage that may occur as a result of the error. |
| Test Case Specification | A document that specifies the test inputs, execution conditions, and predicted results for an item to be tested. |
| Test Design Specification | Documentation specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests. |
| Test Documentation | Documentation describing plans for, or results of, the testing of a system or component. Types include test case specification, test incident report, test log, test plan, test procedure, and test report. |
| Test Incident Report | A document reporting on any event that occurs during the testing process which requires investigation. |
| Test Log | A chronological record of relevant details about the execution of tests. |
| Test Plan | A document describing the scope, approach, resources, and schedule of intended test activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. |
| Test Procedure Specification | See Test Procedure. |
| Test Summary Report | A document summarizing testing activities and results. It also contains an evaluation of the corresponding test items. |
abbrs. A list of abbrs, and their definitions, used in the course materials.
| ConOps | Concept of Operations |
| INCOSE | International Council On Systems Engineering |
| NRTM | Needs to Requirements Traceability Matrix |
| RTCTM | Requirements to Test Cases Traceability Matrix |
| RTM | Requirements Traceability Matrix |
4. References
Traffic Management Data Dictionary (TMDD)
- Guide to Traffic Management Data Dictionary (TMDD) Standard v3.0 for Traffic Management Center-to-Center Communications, AASHTO/ITE, July 11, 2011.
- TMDD Standard www.ite.org/standards/tmdd
- TMDD Standard, v3.03, Volume I: Concept of Operations and Requirements, AASHTO/ITE, 2013.
- TMDD Standard, v3.03, Volume II: Design Content, AASHTO/ITE, 2013.
Standards
- IEEE 829-2008 - IEEE Standard for Software and System Test Documentation, IEEE, July 18, 2008.
- ITS PCB Training stds_training.aspx
Systems Engineering
- Systems Engineering Handbook - A Guide for System Life Cycle Processes and Activities, Version 3.2, INCOSE, 2010.
- United States Department of Transportation Federal Highway Administration. Systems Engineering Guidebook for Intelligent Transportation Systems Version 3.0. November 2009. https://www.fhwa.dot.gov/cadiv/segb/
5. Study Questions
Questions in the presentation
Question 1:
Which of the following is NOT a reason to perform testing?
- Develop Concept of Operations
- Verify requirements are fulfilled
- Validate the user needs are satisfied
- Assess a system upgrade versus the existing system
Question 2:
Which of the following does NOT belong in a well-written test plan?
- Testing Environment
- Testing Plan Staff Requirements
- Pass / Fail Criteria
- Sequence of Actions to be Performed
Question 3:
Which of the following is NOT in the TMDD Standard v03?
- Needs to Requirements Traceability Matrix
- Requirements Traceability Matrix
- Requirements to Test Case Traceability Matrix
- A single design to fulfill each requirement
Question 4:
Which of the following is part of the Requirements to Test Case Traceability Matrix?
- User Needs
- Requirements
- Design
- Test Plans
Question 5:
Which of the following is permitted by the TMDD Standard?
- Create a new message to fulfill a new requirement
- Change the meaning of an existing data element
- Create a new data element using an existing requirement
- Modify an existing dialog
Question 6:
(Extended Text Description: The figure shows an Example TMDD Dialog, which is in the form of a related powerpoint slide from the powerpoint presentation. This slide contains the following text:
Learning Objective #6
Example TMDD Dialog
3.1.37.2 dlVideoSwitchStatusUpdate
3.1.37.2.1 PRE CONDITIONS
An owner center shall provide updates to an external center upon acceptance of a dlDevicelnformationSubscription dialog.
3.1.37.2.2 DIALOG REFERENCE
See Clause 2.4.3 Generic Publication Update Dialog
3.1.37.2.3 ASN.1 REPRESENTATION
dlVideoSwitchStatusUpdate ITS-INTERFACE-DIALOGUE {
DESCRIPTIVE-NAME "OwnerCenter<-DlVideoSwitchStatusUpdate->ExternalCenter"
ASN-NAME "DlVideoSwitchStatusUpdate"
ASN-OBJECT-IDENTIFIER { tmddDialogs 122 }
URL "Pub.gif"
DEFINITION "A publication dialog that allows an owner center to provide status updates to an external center on the owner center's video switches."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
ARCHITECTURE-REFERENCE { "emergency traffic control information",
"device status",
"field equipment status" }ARCHITECTURE-NAME {"U.S. National ITS Architecture"}
ARCHITECTURE-VERSION {"7.0"} DATA-CONCEPT-TYPE interface-dialogue
STANDARD "TMDD"
REFERENCED-MESSAGES {
{ tmddMessages 85 }, -- videoSwitchStatusMsg (Input Message)
{ c2cMessages c2cMessageReceipt(1) }, --c2cMessageReceipt (Output Message)
{ tmddMessages 10 } -- errorReportMsg (Fault Message)}
Additional descriptive notes: Please note that on the example graphical slide, there are two red ovals encircling the first five lines of text starting with 3.1.37.2 and the bottom four lines of text starting with REFERENCED-MESSAGES.)
Which of the following is not an appropriate test step for the previous dialog?
- The Owner Center sends the videoSwitchStatusMsg to the External Center
- Pre-condition to execute the dlDeviceInformationSubscription dialog
- The External Center sends a c2cMessageReceipt message to the Owner Center
- The External Center sends a deviceInformationRequestMsg to the Owner Center