e-Standards Testing

Raghu Krishnan

 

With the increased in the need for partner integration, electronic document exchange standards have become increasing popular. Standards have been in existednce for over more than a decade now, but with new technologies like such as XML emerging in the recent past, have takenthese standards are taking on new dimensions.

 

Electronic document exchange has simplified the integration process and drastically decreased the time taken needed for document exchange and processing. These advantages have encouraged companies to deploy this document exchange technology in mission criticalmission critical integrations involving vast large dollar amount transactions. This in turn has increased the need for a more reliable, secure, fast and well definedwell defined transports. . The sStandards are continuously aiming altered to at better addresssolving these issues. The areas that the standards focus on forTo provideing a fast, secure, and reliable transport, enhancements of standards are focused on security, exception handling, partner profile management, fail-over, delivery, payload definition, etc.

Standard - What does it mean for QA?

A standard typically defines includes a transport, a document format, and specific security criteria.

 

A transport typically contains the following:

 

• A mandatory low- level definition of headers
• Security
• Error codes with low -level exception handling
• Aand n optional business- level document definition
• Transaction choreography, (which encompasses document relation, document handling, and processing)
• Transaction -level timeout criteria
• Business -level security concerns

 

Standards with their maturity have become diversified in their approach and scope. While some standards have taken the approach of defineing just only the document definition for their payloads, others have defined the actual business- level transactions in addition to the document definition, or and a few others focus on just only the low low-level transport protocolpiece  toand believe in keeping the transactions simple and allowing almost any payload to be sent back and forthtransferred. Because each standard attempt to solve the document exchange problem, but for a specific industry vertical, no one ‘best’ standard existsin the industry.

 

This document discusses the high high-level aspects of testing standards for electronic document exchange without going into details of any specific standard. This document focuses on broad and common aspects of most standards and discusses key testing areas for the same.

Testing an Implemented Standard:

Testing an implemented standard involves testing the following key areas:

• Document Format format Conformanceconformance
• Document Validationvalidation
• Document Transfertransfer
• Process Choreographychoreography
• Security
• Exception and Error error Handlinghandling
• Base Platform platform and Toolstools

 

Document Format Conformance:

Most documents for a standard have header and payload sections. The header section typically contains information about the payload, sender and receiver of the document. The header, and has a specific structure. In addition, specific fields in the header might also be used to recognize the document and to whichstandard or version of the standard it belongs.

 

 

Testing a document generated for conformity to the a specification is an important part of the document format tests. While testing the structure of a document, it is important not only to look for missing fields and values but also to ensure thatthere are no additional fields exist in the formed document.

 

Sometimes, a certain value in a header field can cause subsequent changes in the values of other header fields. These cases should be identified and tested with the variations. The values of the header fields also might also suggest certain specific operations to be performed on the document. Each variation should be tested thoroughly.

 

The payload section of the a documents can be defined by the standard or by the user. In cases whereWhen the payload is user defineduser-defined, there is invariably a headersection  alwaysthat refers the payload. This issue may be compounded with multiple payloads. In the case whereWhen the payload is defined by the standard, the above mentioned test areas listed above for the header section are applicable to the payload also.

 

Document Validation:

The headers and payloads defined by a standard invariably have specific values for the fields in these sections. Validation is an extension of the document format conformance. Having After checked checking the structure of the a documents, it is important to ensure that the fields are populated by with the correct value, within the acceptable range, of the right data type, etc.

 

Validation exception is an important aspect that has mustto be tested. The exception should clearly convey the validation error. Special validation exception handling defined by the standard should be tested. For example, the RNIF 2.0 transport requires that header validation errors be reported to the partner only when running in “Test” mode. If exception messages are required to be sent to the partner, the exception message should be tested for document conformity and validation.

 

Document Transfer:

For actual document transfer,E every standard requires the use of a low levellow-level transport like such as httpHTTP/S, https, ftpFTP, smtpSMTP, etc. for actual document transfer Every low levellow-level transport should be tested for document transfer. Pay Sspecial attention should be paid to the specifics of setting up and using the protocol, . Ffor example, using valid and invalid certificates for SSL, using an SMTP server for email based document exchange, etc.

 

   Documents can be transferred synchronously or asynchronously between partners. Synchronous document exchange tests should ensure that the connection is not closed between the partners during the document exchange. Synchronous connections usually have a timeout associated with them, as it would be expensive to hold a connection for too long. Tests should focus on this timeout feature.

 

Process Choreography:

Certain standards require a certain order in which documents must be sent and received. The testing should focus on making sure that the documents are sent or received in the order specified.

 

Standards that require document correlation within a transaction require an ID to be common across all of the documents in that transaction. The testing should ensure that the ID is consistent for a set of transactions. The negative testing should focus on the exception handling part of invalid document order and mismatches in correlation IDs.

 

Delivery semantics are an important part of process choreography. Standards that define retry and timeout constraints pose an interesting testing challenge. Testing retry conditions encompasses actions taken during transient retries and actions taken when all retries have been exhausted. If different actions have to be taken, they have tomust  be tested individually. If the standard defines waiting times between retries, tests have tomust be performed to focus on waiting for specific periods before retrying.

 

Security:

Security plays a big part in the standards testing. The sSecurity part extends from the SSL and low low-level security to business business-level security aspects like such as signatures and encryption. The tTesting should focus on using the right certificates for SSL, document signing, verification, encryption, decryption, etc. Different authentication options should be testing used to testfor SSL connections. Hash algorithms supported by the standard should be tested separately.

 

Exception handling will should involve missing certificates, incorrect user/cert associations, mismatches in security options between partners, and mismatches in hash algorithm settings between partners. Testing Rreverse invoke settings is an extension to of this testing area.

 

Exception and Error Handling:

Exception and error handling can be separated into two parts:,

·        iInternal exceptions thrown within the system, which may or may not be communicated to the trading partnerand

·        Eexternal exceptions received from the trading partner in the form of an error message

 

All exceptions should be caught and appropriate action should be taken.

 

The exceptions, whether internal or external, should be meaningful and clearly convey the reason for the failure. Formatting the error before sending it to your partner is important. Exceptions or Error error messages received should be processed accordingly and the appropriate action taken as specified in the standard.

 

Base Platform and Tools:

The base platform used to build the standard solution should successfully support the implementation. The tools used to implement the standard should provide full the functionality and customizability customization required to implement the standard. Every supporting tool should be tested for seamless integration. and aAny interoperability issues should be detected and fixed.

 

The architecture of the base platform should be such that it supports multiple standard solutions at the same time. Multiple versions of aS standards that have multiple versions shouldalso be supported such that they function independently and in conjunction with one another.