In the world of software, changes are happening fast. Soon, we’ll be storing a ton of data, but not all of it is the same.
Data comes in all shapes and sizes—like tables, hierarchies, and graphs. Even though they look different, they all end up stored as tables or hierarchies on the computer. For example, think of a database like a big filing cabinet with lots of drawers (tables) inside it. A graph is saved as XML or JSON, but in the end, it’s saved as a hierarchy. And if you have a file with plain text, it’s a table with just one column.
In software projects with automated tests featuring poor data coverage, the successful features that generate the most profit are the ones that could cause the most trouble. They’ve been around for a long time, will be developed by different developers, and are quite complicated. These are reasons why the logic of such features may not be completely understood, and developers tend to introduce new bugs in data processing logic.
Due to low data coverage, automated tests will not be able to detect new bugs within data processing logic, and a buggy release may be delivered to a customer. A data processing bug might destroy a lot of customer data in the field. In my opinion, data bugs are more dangerous than logical bugs because data bugs may destroy data in the field that might be unrecoverable and may lead to high expenses.
In summary, I am convinced that successful functionality becomes complex over time and must be well protected by automated tests to be able to further develop. Especially, data processing logic is often unprotected today because developers trust code coverage. However, code coverage only shows that the code was executed, and it is verified only if produced data was checked against expected results, which is not code- but data coverage. Today, we still don’t have tools to measure data coverage, and this needs to be done by “belly feeling.”
