Employing Automation to test Data Interface

Say, you got a DB comprising of huge data with billions of records. You have to showcase it on UI only after making sure that everything you want to represent on UI is accurate and as expected. Incorrect data could impact your business in unknown and serious ways that can lie undetected for months.So, here you might need to plan a new strategy, which should lead to answers of all your questions.One of the finest approach among this strategy should be- to make sure that everything you are showing is validated and verified. This leads to a special type of testing called as Data Interface Testing.

What is Data Interface Testing ??

Before we go ahead with Data Interface Testing, let’s first discuss about data interface. Lots of application in the market are nowadays based on Data Mining or Big Data concept. This helps to streamline the big data and showcase on UI in an adequate manner.

Now, as many people say that there is always some pros and cons for each process. Similarly, even this one has few. One of the biggest one is showcasing huge data. But I have a solution.

There is always a challenge to show the huge data on UI where everything is placed at their respective place with correct data set and correct orientation (if you’re showing the data in graphical representation).

 

So, the interaction between database and User Interface brings the term Data Interface. And to make sure that it works well both ways i.e. request and response results, we call it as Data Interface testing.

Big Question !! 

Can I test this much of data and all of that manually??

Answer is yes, it is possible. But practically not a good way to do the same.

So what …?? Automation ??

Yes.

But what if I don’t have any good knowledge for it ?

Don’t you worry, we got a cheat for you !!!  A tool to test data interface automatically, with a very basic knowledge for Automation/coding.

Some Info Regarding this tool
This tool is made to test validation and verification of data between database and user interface. To make this tool useful, one can easily use it on it’s own working environment, by customizing the details in provided file and coding as per their requirements. .

How this tool works ?

With it’s main class, it reads multiple files which further executes the methods written in those properties.

For reference, the source code is mentioned below:

Representing Main Class of Tool

Method written in above class is dependent upon various files. One of them is called as Property_Reader file.

This is a custom made file, which executes multiple methods and brings result for main class.

1. Property_Reader_Method

2. db_property

This file comprises of all properties, which helps in setting up connection with server/DB.

Following are the properties used in this file.

1. Url=jdbc:presto://10.0.11.198:8080/test/default
2. UserName=root
3. Password= 12345
4. ClassName=com.facebook.presto.jdbc.PrestoDriver

• You can change your URL and credentials as per available server(s).
• Password can be null too. Depends upon the server details.
• For current we are using presto as DB.

3. query_column

This comprises of column name for which data needs to be fetched from DB. For every query there should be a unique query name which must be identical in all property files for that query.

For below mentioned example. “testA_count” is the name of query which is unique from rest of the two but same in other property files for queries with same conditions.

Apart from that, irrespective of number of columns available in expected and actual query, it will only bring data for “Column A” column in the result set.

Same case for others too.

4. query_actual

This property file contains the queries created by developers or fetched through server logs file which are created while accessing the application through UI.

5. query_expected

This property file contains the queries created by testers.

By running the above mentioned code for main class, it will create a new result file every time. This file will comprise of end result for executed queries, having expected and actual result with numbers and pass/fail result.

For Failed Case:

Let’s change the actual query to-

Points to be considered:

• Make sure that the query name should always be the same in all expected, actual and column property file.
• For every query there should be a unique query name.

Benefits of using this tool are:

• Any Structured DB can be used for this eg. Presto, MySQL, MS-SQL etc.
• Platform independent. Can be run on Windows/Ubuntu/Linux.
• Can be run on a project written in any language.
• Doesn’t require any prior coding skills or automation knowledge.
• One can easily put the expected and actual test case in respective property files and can have the result set, with complete information.
• Can be easily customized as per available resources/requirements