Test data model

In the chapter "Data model" we introduced how to add or adjust GDSN modules and their fields in Product 360 which includes a "Data model check list". This check list ensures a correct defined data model. It's also checking if the changes in the Product 360 data model are visible by the generic functionality of Product 360. For the mentioned check list you should create test data for exhaustive testing.

For example you can create an Excel file as import file, like shown below for the fields Packaging type, Packaging feature code, Usable product volume and Usable product volume UOM of the sub entity ArticlePackaging, which is representing the GDSN Module PackagingInformationModule:

(Note: this table does not contain all scenarios to test)

Test import

Create an import mapping for your excel file and execute the import. Ensure that all expected errors are printed in the import log. Please check the created data after for correctness.

Test export

Create an export to check if you can export the data as expected. This also ensures that all fields are visible with the needed qualification.

Test Service API

If you are planning to use the Service API for your fields, ensure that you have tested it.

Testing created data quality rules

There are many ways to test your created data quality rules. For example you can test the created data quality rules within the Informatica Developer. The necessary steps are explained by using the "IfNotEmptyConditionNotEmpty" rule:

1. Create an Excel file which contains all input ports and an expected behavior as description.

   inObjectID	inConditionField	inCheckField	inStatusMessage	Description
   10001			GDSN1	both inputs empty, ok
   10002		somevalue	GDSN1	first input empty, ok
   10003	somevalue		GDSN1	first input not empty, but second one, error
   10004	somevalue	another	GDSN1	both inputs not empty, ok
   10005	somevalue			first input not empty, but second one, with default error message
   10101	somevalue		GDSN1	aggregated, not ok
   10101	somevalue	another	GDSN1

   (Note: not all possible test scenarios are covered here)

2. Create an Excel file which contains the expected output after the data quality rule was running.

   outObjectID	outStatusMessage	outStatusCode
   10001	No Error	1
   10002	No Error	1
   10003	No Error	1
   10004	GTIN is required but not provided	0
   10005	inCheckField must be empty because inConditionField is not empty	0
   10101	GTIN is required but not provided	0

3. Create a mapping to send the Excel file data created at step 1 through your data quality rule.

   

4. Compare the expected result from step 2 with the actual result of step 3.

Testing created data quality configuration

Depending on your data quality check, you can reuse the data you already created for the data model test. But you might need to extend those with further data constellations.

A recommended way to test if your data quality configuration is working as expected is:

1. Think about all possible data constellations and create your data accordingly.

2. Execute the data quality check for your configuration on the data of step 1.

3. Evaluate if your expectation and the actual result is equal.

In case the data quality configuration result is differently as your assumption, please check following:

1. Are the correct fields mapped to your data quality configuration?

2. If existent, is the correct qualification of the fields used?

3. If existent, is the port "InObjectID" mapped?

4. Did you use the correct data type?

5. In case you are using a sub entity of item as data type, then there must be one data entry for this sub entity to execute the rule.
   If you want to ensure that a value is in a specific field of a sub entity use the item as data type instead of the sub entity and qualify the field accordingly. You could also implement a data quality rule which is checking the field via service API.

6. Is the used data quality rule the correct rule for your validation? Please check the description of the rule again.