Our very own software testing engineer Ani Hakobyan has shared her thoughts about the importance of Data testing. All the articles by Ani are available here.
“Where there is data smoke, there is business fire”, said Thomas Redman.
And he was right.
In today’s life, the sexiest thing that has much more power than we can imagine is Data. We’re facing it everywhere.
But, let’s understand, what the data actually is:
Data is some compiled information that is stored in any tool. Whether the last is an excel spreadsheet, a database or a piece of paper at all.
In the case of software development, processing the data and storing it has an impact on how the business will progress further, and will it progress at all or not. No doubt that the testing activities should take place for this part as well.
You will ask me why?
Of course, I will tell you 😉
As muggle, to muggle…
So, why does the Data need Testing?
The data reaches the application through different ways and sources. But, does anyone need raw data? Will the users or business staff figure out what is going on?
Let me explain to you.
Raw data is data that was collected from a primary source and isn’t processed by any machine or user.
Data aggregation is the process where raw data is gathered and expressed in a summary form for statistical analysis.
The process of analysing the raw data is performed by a data analyst or scientist – anyone who can retrieve the data by using SQL. Data Engineer in its turn Extract, Transfer and Load (ETL) the different data files and convert it to the raw data. And then the Data Analyst converts that raw data to aggregated data and explains the result.
As much data, as much place is needed to keep it. When your business is growing and your applications need to expand availability, power, and performance, you have two options to meet the challenge: horizontal scaling (adds more instances of machines without first implementing improvements to existing specifications) or vertical scaling (keeps your existing infrastructure but adds computing power).
Now we’ve come to Transactions, which is a sequence of operations performed on a distributed database as a single logical unit of work. And here we’re facing the CAP theorem.
It tell us that your database can have:
- Consistency – your data is up to date – that means you’re receiving the data in real time.
- Availability – your database answer to all your requests, and
- Partition Tolerance – your database shouldn’t crash if there are arbitrary number of messages being dropped (or delayed) by the network.
But, I said CAN. That means that you can have only 2 of these 3 options. And that also means that you will have a blind spot when storing and, most importantly, retrieving your data.
The testing of the data can be performed on each of the 4 testing levels: Unit testing, Integration testing, System testing, Acceptance testing. As for me, the most useful testing level for this case will be the Unit testing, as the issues will be identified earlier and fixed accordingly.
- As a Software testing engineer, you can validate data by ensuring that it is mapped correctly. You can verify if the fields on UI are mapped correctly to the corresponding fields in the database.
- Most useful and famous databases are relational ones where the tables are connected to each other with the Primary and Foreign keys. There is also a practice to “group” tables in a schema that represents the organisation of data and the connections between the tables in each schema. Here is a job for the testers to validate them.
- One of the properties of a database is ACID. It means, the database should be Atomic – the transactions should succeed or fail all together; Consistent – the rules or constraints of a database should be followed; Isolated – do not disturb each other, being parallel during the process; Durable – the data after transactions should be kept in a storage and do not be lost. The Software tester can validate the properties of ACID to be aware how well the database handles the data stored in it.
Here we go!
I hope you enjoyed reading my article, and now you have an understanding of why the data needs to be tested.
See you!