Monday, December 15, 2008

Enable EDI Test Plan creation and the Testing process


It was a rare occasion in my life to work for a Project when everything was unknown what we were supposed to do. My senior called me up just to say “We have to do this as a challenge, i have already signed the Contract ..... “ and I just replied “Yes Boss .. “.

The Project had two parts, in one part we had to generate the mapping instruction and application set up, on the other part complete test plan creation and testing. When the developer used to complete the code development, and the basic backend set up was done, we used to start testing as per approved test plan. I like to discuss about the typical testing process and test plan creation which was devised by us and appreciated by the client.

The testing process approach was as follows :



Installation & Registration Testing
Installation test will check the configuration path for starting testing.

Entry Criteria: Registration setup configuration, Source path of test data loading and corresponding populated inbound and outbound flat file path, Error Notification mail configuration, scheduler configuration should be completed. Trade Gateway application should be also completed.
Activities: Execute following steps for various actions

  • - Registration of new Vendor
  • - Checking of PO, ASN, Invoice and other docs using vendor ID & password (created in earlier step)
  • - Loading PO (850) on TG web EDI application
  • - Getting inbound flat files (Successful Translation)
  • - Getting inbound flat files (Unsuccessful Translation)
  • - Getting outbound flat files
  • - Getting outbound ‘X12’ file

For all these activities we had to either logged into a particular staging server or look into a predefined folder for the output.

Deliverable: Test Plan with test log and Ramp Issue Log
Proof of Execution: Loading of PO through registered Vendor’s Login ID/ Password
Exit Criteria: Successful loading of PO in TG web application through Vendor’s Login/ Password. Collecting populated Flat Files and x12, if applicable.

Build Acceptance Testing
Build acceptance test is a check to ensure that the retailer’s mapping specification match the TG web EDI functionality in order to determine if further testing can be executed.

Unit Testing
Unit testing is a verification effort on the smallest unit of the software component or module like 850, 856, 810, 860, 855 etc. Unit testing is mainly focused on following areas

Entry Criteria: Availability of Modules with stable build
Activities: Preparation of Unit Test cases, Testing with provided test data, in case of insufficiency, have to build test data for checking and execution of test cases.
Deliverable: Test plan document with test results, test data used, inbound flat files/ outbound flat files/ X12, screen shots of front end page (if required), Ramp Issue Log and test status report.
Proof of Execution: Review of Test Plan document, Traceability Matrix for all test cases, review of test data/flat files/x12 documents, PO#/ASN#/Invoice# for passed test cases and screen shot with explanation for failed test cases.
Exit Criteria: Sign off test plan, Sign off Unit testing

Integration Testing
The primary objective of integration testing is to discover errors in the interfaces between Modules / sub systems like 856 web.htm-856 web-confirm.htm /810 web-confirm.htm-810 web.htm / 856 web.htm-856 pick pack.htm / 850 web.htm-850 SAC detail / 850-856-810 chain.

Entry Criteria: Availability of Modules with stable build
Activities: Preparation of Unit Test cases, Testing with provided test data, in case of insufficiency, have to build test data for checking and execution of test cases.
Deliverable: Test plan document with test results, test data used, inbound flat files/ outbound flat files/ X12, screen shots of front end page (if required), Ramp Issue Log and test status report.
Proof of Execution: Review of Test Plan document, Traceability Matrix for all test cases, review of test data/flat files/x12 documents, PO#/ASN#/Invoice# for passed test cases and screen shot with explanation for failed test cases.
Exit Criteria: Sign off test plan, Sign off Unit testing

End to end Testing
The primary objective of End-To-End testing is to discover errors when the system is tested as a whole. End-To-End testing is mainly focused on following areas

- Identifying the End-To-End / Business Life Cycles.
- Design the test and data.
- Optimize the End-End / Business Life Cycles.

Entry Criteria: Successful completion of Integration testing
Activities: Preparation of End to end test scenarios and execution of the same
Deliverable: Complete Test plan document with test results, all the tested input and output files, Ramp Issue Log and test status report.
Proof of Execution: Review of test plan document with traceability matrix for all the test cases transaction set wise for passed test scenarios and screen shot of failed Test Case scenario.
Exit Criteria: Sign off test plan document as “Testing complete at staging and its ready to go live”

Regression Testing
Testing the new build to ensure enhancements implemented correctly and existing functionalities are stable and not corrupted.

Entry Criteria:
Testing of change requirements are signed off
Activities: Execution of regression test scenario
Deliverable: Regression Test with defect report along with Ramp Issue Log.
Proof of Execution: PO#/ASN#/Invoice# for passed test scenario and screen shots of failed scenario
Exit Criteria: All regression cases should be executed and test reports should be updated accordingly

Reliability Testing
Reliability Testing is a property, which defines how well the results match the specifications. Reliability is considered as the probability of failure-free operation for a specified time in a specified environment.

Reliability Testing helps you to confirm: Business logic conformity, proper controls (Buttons, Labels, Captions etc.) display on front end, Reliable hyper links navigation, correctness of generated outbound X12 etc.

Entry Criteria: Functionality testing is signed off
Activities: Preparation and execution of test scenario
Deliverable: Test plan document with test result, Ramp Issue log (if applicable), Test status report
Proof of execution: PO#/ASN#/Invoice# for passed test scenario and screen shots of failed scenario
Exit criteria: Stability of the application

Test Scenarios
Test scenarios will be identified for each module Test scenarios will be associated with both positive and negative data optimization of test scenarios will be taken care as the test cycles increase


Test Cycle
- Test cases and Test scenarios will be base lined for each test cycle
- Test execution reports and metrics will be maintained independently for each cycle

Dependencies
Every testing scenario has a few operational dependencies. As in this case we used to access ICC’s remote boxes with other required inputs I am spelling them out.

  • () Retailer specific TG screen shots should be available for desired field display and content testing
  • () Map specification template
  • () Servers availability with super-user rights
    () Scheduler should be available and tuned properly
  • () Staging setup should be available
  • () Map development should be complete and released into the proper path with publicacy.


Complete test data (850 X12) should be made available before testing

Status Reporting
The service agency will provide the status reports frequently to ICC. The status report will contain the following items:

-Daily status reports will be provided with the progress of task.
-Weekly status report will be provided with the Planned/Actual/Pending tasks and also forecast for the coming week.
- Monthly status report will be maintained to understand
Planned task progress Issues related to the task Need for the allocation/de-allocation of resource.

For any query, please mail me at ambarnath@crossroadtechnologies.in

1 comment: