EDI Testing

Testing: It is the process of demonstrating that errors are not present. It can also be said in other words as a means of achieving an error-free program by finding of errors.

Software Testing: It is the process of executing computer software in order to determine whether the results it produces are correct.

The Software Testing has become an integral part of SDLC (Software Development Life Cycle) as the product or project has to be tested and then to be on boarded. Hence the concept of STLC (Software Testing Life Cycle) came into vogue. Naturally when an EDI map is being placed in production it has to be tested for ensuring proper transformation of data as desired in the Field Mapping Document.

EDI Testing: It has various degree of intensity depending upon the requirement. Generally there are two types of testing in EDI. They are

1 Map output Testing : This is the most common sort of EDI testing where the tester is expected to check the output vis-à-vis the FMD. The output can be X 12/ EDIFACT or Flat File/XML. It is expected that the tester should visualize the expected bug level in advance and perform the testing. I am sighting a case to make the point clear.

In the FMD it is said that P04 and P16 pair of records will be generated from the X12 based on occurrence of PO1 – PID segments. In the provided X12 test data there was one set of PO1 – PID and the map generated perfect output. If the Tester feels satiated then he stands wrong. Who knows in the production environment multiple sets of PO1 – PID segments will not come ? So to be on safer side, the tester must create a test data with multiple sets of PO1 – PID segments and run the map. From my gathered experience I can say there is a possibility of getting an error so far PO4 – P16 record looping is concerned. We may see that all PO4 records are coming first and then all the P16 records are coming. Hence the developer has to change the map logic and incorporate a header group logic for clustering the PO4 – P16 records.

Apart from this the Tester must help the developer for setting up various back end set ups like SAP cross reference table depending upon the customer’s test data. It may so happen that the customer is not in a position to provide test data (X12) , then the tester has to generate the test data based upon clue available from the FMD to facilitate developer’s unit testing. But for outbound maps (application output to EDI X12) if no test data provided then it has to be obtained from the client. We should not start creating application output at our end.

Generally we don’t have any test plan for this sort of testing, we plot the test results on the FMD itself in different columns for different combinations of test data with Pass/ Fail status.

We have to keep in our mind that for this sort of testing generally Clients don’t pay hence we are not expected to spend much time for this. The map development time includes the testing time. But if a particular map needs to be tested with 25 test data then it should be mentioned to the client and extra days/ hours should be sought for.

2 Web based EDI Application Testing : This is much more critical type of EDI testing where we need to be much more knowledgeable in functional process flow, structures of various EDI docs, Back end application set up, development of Functional Test Plan and Testing within a stipulated time frame.

The key areas where we should performance testing for web based EDI Application.

a) Application Set up testing : This is basically nothing but Smoke Testing. The readiness of the testing environment was checked first. Before we actually start the testing, lot of back end setup was to be fixed by the VAN at the remote server. A Biliden # was to be created and by them and vendor creation permission was to be granted before we could take up actual testing. A scheduler was set up so that at a particular interval the test data can be picked up automatically, it was often found that the scheduler was failing and the pace of testing gets affected. Although this is not a part of functional testing but important enough to clear all possible operational bottlenecks at the very first instance.

b) Vendors Login Page : Refer to relevant Test cases in the Test Plan

c) Various Functional Document Display Pages : Purchase order, Advance Shipment Notice, Invoice, DSD Invoice, Remittance Advice etc. Refer to relevant Test cases in the Test Plan. We have to remember that for all outbound Documents there will be two interfaces, one entry interface and other one is confirm page. There are also a few embedded HTML pages like Allowance/ Charge page, Change History pages etc. We had to perform GUI testing and Positional / Sequence testing. Most of the time it was instinctive testing as there was no guideline for such things. Just mere bug posting was not desired from us hence we had to fix the display issues with a back end tool called Progress. Refer to my documentation in this regards.

d) Mapping and Flat file Testing : The most critical but interesting part of testing is this one. We were offered the various flat files instead of the database tables owing to some security reasons. While testing, we used to put our test data in a particular location in the production server itself and the flat files were generated in another designated location.

Under this testing, basically we had to test critical map-logic if proper values were not displayed in the web interface. In the test plan we did not put all the test cases as it became very lengthy, but logged all issues in the issue log file. The severity level of bugs was also mentioned in the issue log file. The developers at the client’s end used to fix the bug and it was regressed by us for clearance.

The test plan creation is another important thing. It should be properly sequenced so that it can be understood and executed even by a layman. We have to keep in our mind that although we perform staging testing at our end, but when the map will go live then the final round of production testing will be performed by the client.

We have to remember that once the testing is passed per approved test plan the onus of successful running of the map lies with the test lead not the developers.