Maryland Extensible Markup Language Test Plan and Certification for Competitive Gas Supply

Version 1.0
July 2011

Table of Contents

1. Introduction

1.1 Version Control

1.2 Purpose of this Test Plan

The first goal of this Test Plan is to define objective criteria by which a competitive gas supplier ("CGS") may validate that it is creating Extensible Markup Language ("XML") transactions that adhere to uniform electronic transactions as described by the Maryland Competitive Gas Supply Process and Transaction Standards Manual ("Manual").

The second goal of this Test Plan is to define objective criteria for a CGS and a gas company ("LDC") to move into a production environment and begin competitive gas supply operations. This objective focuses on the process of testing CGSs' systems so they may begin uniform electronic transaction ("UET") communication with LDCs.

The third goal of this Test Plan is to define objective criteria for a CGS to validate that it is executing business processes as defined by Maryland Competitive Gas Supply Process and Transaction Standards. This objective focuses on testing UET communications between LDCs and CGSs.

1.3 Assumptions

1. This test plan has been developed to assist LDCs and CGSs by providing examples of various transactions that may be certified for testing by each LDC.
2. This test plan is designed to test UETs that CGSs and LDCs must exchange with each other.
3. This test plan assumes that participants will use automated processes when testing. Any manual interaction required to complete testing must be documented and communicated to CGSs at the beginning of the testing cycle.
4. This test plan only addresses electronic XML communication between LDCs and CGSs. It does not test the ability of either the LDC or CGS to render a bill or to validate the bill contents.
5. Each LDC is permitted to test scenarios according to its specific system requirements. The uniform XML Test Plans containing LDC specific system requirements will be made available for CGSs to review prior to testing.
6. The connectivity test will be performed with a sample of one outbound file per CGS.

1.4 Overview of Testing Process

1. The CGS contacts the LDC to indicate their readiness to begin testing.
2. The LDC will notify the CGS of the date testing will begin. The LDC is responsible for facilitating identification of exceptions to testing, by both the LDC and each CGS, as well as coordinating development of the testing schedule on a per-CGS basis.
3. CGS will send test files through an LDC test environment.
4. Each party will send these files to the other party through Internet XML, and notify the testing contact of the LDC or CGS that the files were sent.
5. LDC and CGS shall validate against the XML schema to confirm that files comply with the appropriate schema.
6. After testing has been completed successfully and is XML certified, the LDC will send a formal notice via e-mail.

2. Requirements of Testing Parties

In order to allow adequate planning, the CGS and the LDC must communicate before, during, and after testing in a mutually agreeable fashion. Prior to testing, the CGS shall provide a list of competitive gas supply services to the LDC they are expecting to offer. The LDC and CGS must cooperate to identify and resolve XML-related computer system problems. As referenced below, an LDC may be dealing with several CGSs concurrently, thus the LDC must maintain sufficient resources to provide the necessary information, communicate problems, and coordinate the test schedule. Prior to testing, the LDC will establish and provide a set of accounts with the necessary testing information for each CGS prior to the start of testing.

2.1 CGS Requirements

1. Review the test plan as available on the Commission and LDC Website.
2. Review each LDC's testing requirements documentation.
3. Contact the LDC and request to be scheduled for testing.
4. Obtain test account numbers and test plan from the LDC. Create and submit UETs according to the test plan for those accounts.
5. Test scenarios for each billing method the CGS will offer.
6. Participate in any required testing meetings held by the LDC.
7. Send UETs according to schedule.
8. Notify, via E-mail, the LDC when the CGS sends UETs. The LDC will notify the CGS when it sends UETs.

2.2 LDC Requirements

1. In the event the LDC completes a major system upgrade which impacts XML processing, LDCs have the option to complete all internal testing before conducting any external testing with CGSs.
2. Communicate a testing schedule to the CGS.
3. Compile testing requirements and schemas specific to each LDC's test and production environment. Information should include URL's, schemas, and error messages.
4. Provide a contact and an email address to which manual and automated protocol and exchange failure messages are sent.
5. Send test account numbers to the CGS.
6. Upon CGS request, provide sample bill prints to CGS testing Rate Ready or Bill Ready consolidated billing scenarios. This may be a sample bill with or without actual CGS test data or a general sample to provide the CGS a sample of the manner in which their charges will be presented on the LDC consolidated bill.
7. Send UETs according to scheduled UET sequence. The LDC will notify the CGS via E-mail when the LDC sends UETs. When the CGS sends UETs, it will notify the LDC via E-mail.

3. Test Plan Components

3.1 Testing Schedule and Priority

The LDC and CGS shall begin enrollment and billing testing on the agreed upon date.

3.2 Certification

Certification is granted to a CGS by an LDC upon successful completion of all required XML testing scenarios. The LDC should notify the CGS via email upon successful completion of XML testing.

3.3 XML Transactions Subject to Testing

All transactions below that will be used by the CGS will be tested by the LDC.

Legend: A - Account Number Change, C - Change, D - Drop, E - Enrollment, I - Cut Out in Error, R - Reinstate,
S - Switch, T - Terminate, X - Cancel

4. Overview of Test Scenarios

4.1 Internet Connectivity Testing Scenarios

LDC provides URL internet site in order for the CGS to ensure the username and password is working properly.

Internet Testing Goals

1. Establish Internet XML connectivity for CGSs, including secure internet connections ("HTTPS").
2. Validate that normal testing XML files can be sent.

4.2 Account Request and Bill Test Plan Scenarios

The test plan scenarios listed below are the foundation for Account Request and billing testing. Each LDC starts with this list and makes adjustments based on their business practices. For example, Bill Ready Utilities will waive all Rate Ready test scenarios. Parties may mutually agree to make exceptions to the test plan based upon the competitive gas supply services to be offered by the CGS. Any changes to test plans should be documented and communicated to CGSs prior to beginning testing.

Billing test scenarios are further categorized by the billing method. All scenarios for a particular consolidated billing method must be tested with any CGS planning to use that consolidated billing method.

4.3 Summary of Test Scenario Categories

Legend: A - Account Number Change, C - Change, D - Drop, E - Enrollment, I - Cut Out in Error, R - Reinstate,
S - Switch, T - Terminate, X – Cancel, S - Switch, T - Terminate, X – Cancel

Test scenarios are identified according to the category above.

4.4 Summary of Billing Method Test Scenario Categories

5. Test Scenarios

Actual results will be documented by the testing parties. If actual result is different than expected result, testing will continue until results match expectations.

5.1 Internet Connectivity Scenario

5.2 Account Request to LDC Scenarios

5.3 Account Request to CGS Scenarios

5.4 Rate Change by CGS Scenarios

5.5 Usage, Charges and Financial Scenarios

5.6 Write-Off Data View Scenario