Contexts for Data Validation and Verification

Contexts for Data Validation and Verification

December 14, 2015

“The one who owns information, owns the world”
W. Churchill

Data is one of the main assets for a company. Corrupted, inaccurate, or invalid data can lead to loss of the reputation, money, clients or other business artifacts. That’s the reason why Data Validation and Verification provision may be among the top-priority business objectives.

Data Validation and Verification can be considered from different points of view depending on business needs and expectations. This means that Data Validation and Verification is context-dependent, and one of the basic test principles rests upon this statement. So, any testing in this area should start from identification of testing direction(s), and this is a required condition for achieving predefined business objectives. The following list represents possible fields where Data Validation and Verification can be performed:
• Database Testing
• Input/Import/Export Process Testing
• System Testing
• Maintenance Testing
• Validation of the Data Itself

Testing within the above mentioned directions is much broader actually, but Data Validation and Verification makes a significant part of it. Each testing has a unique set of business objectives and, as a result, distinct goals, test approaches and test types.

Let’s review some examples for obtaining a better understanding.

Database Testing
Database testing can be related to different kinds of databases (e.g. OLTP, DW, OLAP). The following list represents some objectives which can be set for this area:
– Verify that the data is stored in the correct format and is mapped as required (structural testing).
– Verify that the procedures/functions/triggers handle the data appropriately (object validation testing).
– Verify that the transactions handle the concurrent sessions as required (transaction testing).

Input/Import/Export Process Testing
This testing is related to different kinds of insert or extract data processes (e.g. import/export files into/from database, ETL). Testing efforts might be concentrated on the following aspects:
– Verify that all records, fields, and full contents of each field are loaded into destination (data completeness testing).
– Verify that the data is transformed correctly (data transformation testing).
– Verify that the data is loaded into the destination without loss and that the application rejects, substitutes default values, fixes, ignores, and reports invalid data as required (data quality testing).

System Testing
This testing is related to software solutions verification (e.g. for a web app or a mobile app) and includes a wide range of common testing types. Here, a possible objective might be verification data in reports/pages/dashboards.

Maintenance Testing
Various tasks arise during maintenance. Because of that, testing approach and testing types selected will depend on specific situation. For example, it might be needed to check whether data is influenced somehow (during the compatibility testing) or whether data have migrated correctly to destination resource.

Validation of the Data Itself
This type is absolutely different from all testing types mentioned above. Its specific nature resides in the fact that requirements (storage, extract, transmit, load) do not exist here. We only have an array of data and set of knowledge about some aspects of data nature. As result, we need to analyze it in terms of some deviations or anomalies.



Recent Articles

Get 100% Code Coverage for Salesforce Custom Metadata Based Decisions

January 18, 2018 | Bohdan Dovhan

How to obtain a full coverage for code which uses Custom Metadata for strategy-like decision implementation? Introduction Many applications use configuration data. Configuration data might be relevant to the entire organization, or a subset of user, or even different for each user. For the purposes of this article, we will focus only on global configuration […]

Logging of Exceptions in Salesforce

January 11, 2018 | Mykola Senyk

Unpredicted behaviour in a custom code. Can we eliminate it? The ability to customize your Salesforce org code is not just a “nice to have.”  It greatly increases the capability and flexibility of Salesforce. However, custom code can also be tricky to use. It would be great if we could detect unpredicted behavior in our […]

© Copyright - CoreValue 2018
Salesforce, Sales Cloud, and others are trademarks of, inc., and are used here with permission.
Used with permission from Microsoft.