5 trends are increasing the demand for test data providing.
As the demand for rich and compliant data develops, test data “provisioning” must become more automated, self-sufficient, and change-responsive.
Any test data solution today must be capable of faster than ever before of satisfying data requirements of higher volume, diversity, and complexity. This frequently critical need is not always fully realized by companies, which results in negative effects such as:
- Growing constraints in testing
- An increase in the number of incorrect test failures.
- Throughout the SDLC, there has been a loss of productivity.
- Infrastructure costs are rising.
- Risks of ongoing compliance.
Many reasons have contributed to the increased strain on already overburdened test data services. This essay looks at how linked trends have increased the frequency, amount, and complexity of test data requests today. These new and continuing trends can be divided into five categories, each of which must be taken into account when developing a reliable test data solution:
- The interconnectedness of data kinds.
- Changes in systems, settings, and production data at a rapid rate and magnitude.
- A higher level of parallelization between testing and development.
- The changing nature of a “data requester” and the usage of automation in testing.
- Compliance regulations are constantly changing.
These connected trends offer a possible risk to software delivery speed and quality, necessitating a shift away from old test data “provisioning” approaches. It necessitates an automated solution capable of responding to changing test data demands on the fly. A fundamental distinction between Test Data Management (TDM) and Test Data Automation is the ability for parallel teams, tests, and frameworks to self-provision data on demand (TDA).
Read Curiosity’s latest chapter in the new Sogeti report, State of AI applied to Quality Engineering 2021-22, to learn how you can transition from TDM to delivering data requests from across DevOps pipelines on demand. But first, let’s look at a few of the causes that are putting further demand on already overburdened test data provisioning services.
1. The Complicated Nature of Interconnected Data Sources
In today’s world, a test data solution can only populate isolated data into a few databases and file types. Instead, testing and development necessitate a large amount of reliable data that covers a variety of legacy and cutting-edge technologies.
This integrated, interconnected data is required for integration and end-to-end testing, but it significantly increases the amount of data required for testing. A variety of trends in Enterprise Software and IT have resulted in an explosion of data kinds used by businesses today. They are as follows:
- The continual migration of legacy infrastructure to online and cloud-based infrastructure.
- The rise of Big Data and AI, as well as the associated data storage, analytics, and processing technologies. Open-source technologies like Apache Hadoop, Spark, Kafka, and Solr are frequently used in this way.
- New database and file types are being adopted. This includes the adoption of databases from the twenty-first century, such as MariaDB and Firebird, as well as graph databases like Neo4j.
- APIs and message layers are extremely important in today’s world. As a result, message data such as XML files, as well as industry-specific formats and standards, have become necessary.
- Business Intelligence technology is always evolving.
- Microservices are becoming more popular.
While businesses are constantly embracing new technology, these emerging data formats do not completely replace legacy components. Migrations take time, and few businesses have the resources to replace their entire IT stack at once.
As a result, it’s usual to have a mix of new and historical data types being utilized in different regions of an organization. Different elements of a business, for example, might leverage cloud-based technology while others rely on proprietary data types housed on Mainframe and midrange systems. Using the variety of interfaces available today, the old and new must normally communicate and integrate:
Today’s testing necessitates the use of integrated data sets across a wide range of technologies.
As a result, every test data solution must typically be capable of evaluating, editing, and providing integrated data for a wider range of technologies than ever before. It should have a large number of connectors that can be expanded, and it should be able to create integrated data from several files, databases, and applications at the same time.
As testers and developers need integrated data that interact seamlessly across a wide range of platforms, the diversity and complexity of data types add to the complexity of data requests made today. Simultaneously, the rate and development of data requests are increasing, resulting in an increase in the speed and diversity of data requests made today.
2. Iterative Delivery, Agile Software Development, and Continuous Integration/Continuous Delivery
Several developments in software delivery have accelerated the rate of change in data required for testing and development, putting additional strain on test data providing. These developments have accelerated the rate and magnitude of change in systems, surroundings, and production behavior, necessitating the generation of new and more diverse test data. They are as follows:
- Iterative delivery is becoming more popular, with fresh releases and updates arriving in days or weeks rather than months or years.
- Agile software development approaches, with their emphasis on incremental modifications and parallelization, are becoming more popular.
- Increased automation and new technologies in DevOps pipelines and CI/CD, allowing for continuous development and integration of new features.
Existing data becomes out-of-date and often obsolete with each quick update. Existing data may not correspond to the most recent system logic or data formats. In the meantime, coverage gaps develop as historical data lacks the data combinations required to evaluate new or updated logic. While test coverage deficits might lead to defects, inconsistencies or improper combinations can lead to erroneous test failures and bottlenecks.
As each of the three trends emphasizes parallel ways of working, the velocity and number of data requests have increased. A test data solution can no longer provide a small number of teams with relatively unchanging sets of data. Instead, current data must be made available to a wide range of cross-functional teams and automated frameworks:
Today, test data must often be made available to several teams and frameworks at the same time.
Today, any test data solution must be able to provide up-to-date and full data at the same rate that parallelized development teams evolve complex systems. Continuously changing data sets, available in parallel and on the fly, are required for testing and development. Furthermore, the on-demand data must be fully versioned, allowing for the testing of various combinations of versioned system components.
3. Containerization, Source Control, and Code That Can Be Reused
Not only is the rate of system change increasing, but the magnitude of changes to complex systems today may be larger than ever before. This poses a problem for slow and overly manual data provisioning, as a significant amount of data may need to be updated or replaced as a result of quick system changes.
A variety of development approaches have accelerated the velocity and scope of system change. Parallelized developers can tear and replace code at lightning speed because of the adoption of containerization, source control, and easily reusable code libraries. They can quickly implement new tools and technologies, resulting in systems that are densely woven webs of constantly moving components.
Today, a test data solution must be able to provide consistent test data “journeys” based on the significant impact of these changes across interconnected system components. Data must be allocated at the same rate as developers chop and update reusable and containerized components.
This will usually necessitate a closer coupling of system requirements, tests, and code, as well as the ability to quickly identify what data is required depending on changes across the SDLC. Otherwise, testing bottlenecks and errors would occur because testers and developers will be unable to offer properly tested software in short iterations due to a lack of up-to-date data.
4. Testing Automation
Another important development is test automation, which has raised the requirement for up-to-date data in testing and development.
Test execution automation and continuous integration and delivery (CI/CD) have significantly enhanced the pace and amount of data requests. Data-hungry frameworks consume data at a rate that manual testers could never match, and they frequently run enormous test suites overnight and on weekends. Parallelization of the same tests is also common, increasing the demand for data.
Automated testing increases the problems associated with faulty data provisioning by increasing the speed with which data is required. Manual testers can alter their testing if data is incomplete, invalid, or used up, but scripted tests are less forgiving. If data is invalid, out-of-date, or missing, an automated test will simply fail. This contributes to testing and development bottlenecks, as bugs missed during automated testing must be investigated.
The nature of a test data requester has altered as a result of test automation. Manual testers and developers, as well as technologies like test automation frameworks and CI/CD pipelines, should have on-demand access to test data solutions today. On-the-fly parameterization and triggering of test data jobs should be possible for both humans and programs. Another significant distinction between traditional Test Data Management and Test Data Automation is this.
5. Changing Data Privacy Regulations
Data privacy laws and regulations are the most recent set of events that have complicated and called for a revision of test data “best practices.”
The potential ramifications of the EU General Data Protection Regulation (GDPR) for testing and development have been extensively covered by Curiosity. As part of their efforts to comply with stricter data processing requirements, organizations in the EU have already prohibited the use of raw production data in testing. These laws frequently place restrictions on how and when data can be used, as well as who can use it and for how long.
Traditional test data best practices face additional logistical problems as a result of legislation such as the EU GDPR. Today’s businesses may be required to identify, copy, and destroy every copy of a person’s data “immediately.” This usually necessitates more control and management over how data is used in testing and development, as well as quick and dependable data locators across non-production settings. Avoiding copying sensitive data to less-secure, less-controlled testing and development environments is often a safer and easier approach.
In many ways, the EU GDPR was a watershed moment for data privacy, but it was far from unique. It follows a broader worldwide trend, in which a number of countries have passed legislation that is similar to the EU GDPR in certain areas. I These international legislation changes could have a similar impact on the use of data in testing. They include the GDPR in the United Kingdom, the CCPA in Canada, the PDPB in India, and the LGPD in Brazil.
Changing data privacy regulations can make handling test data more difficult, as well as the level of overall control required in non-production situations. Organizations that are already trying to provide testers and developers with data of adequate variety and volume may not relish the prospect of not being able to furnish data, let alone having to remove and limit the usage of current test data. Noncompliance, on the other hand, might have serious consequences.
AI’s Promise and Test Data Automation
Many new and continuing trends indicate that data of greater amount and variety is needed in testing and development faster than ever before. Some of these factors have been discovered in this article, including:
- New and interconnected data sources and targets have emerged, necessitating consistent and intricately associated data.
- The rate and scope of change in systems, settings, and production, necessitate new and constantly changing data for testing and development.
- A higher level of parallelization in testing and development, which necessitates access to large amounts of data on-demand and in parallel.
- The use of automation in testing has changed the character of a “data requester,” necessitating more accurate data in larger quantities and with greater diversity.
- Changing data privacy laws necessitate more oversight of how and when sensitive data is handled in non-production settings.
These developments are putting further demand on already overburdened test data “provisioning” services, causing delays and jeopardizing testing and development quality. This necessitates a re-evaluation of test data “best practices.”
Parallel teams and automation frameworks may self-provision rich, full, and compliant data on the fly using one approach.