Obtaining test data for functional testing usually involves copying and subsetting the production data values used by the software under test. Production data must be carefully masked to comply with data privacy regulations and is often provisioned for testers by a dedicated test data support team. The assumption behind this approach is that production data is realistic, readily available, and made secure for testing.
A global financial services company follows an Agile development process to continuously update their core applications. They have established a continuous delivery pipeline for releasing new features into production and they are leveraging test automation tools to accelerate the cycle time for each release. They also established a rigorous regression testing framework to ensure software defects are caught before they are introduced into the production environment. Fixing bugs in production is time-consuming, expensive and negatively impacts the digital customer experience.
QA professionals know the importance of full test coverage for catching hidden software defects. The impact of undetected bugs that leak into production can range from inconsequential to nothing short of catastrophic. A recent Internet outage provides a real-world example of how a single bug can disrupt the global operation of digital business on the Internet.
In traditional Test Data Management (TDM), the test data lifecycle is based on the premise that some or all data used for testing is sourced from production. A full or subsetted copy of a production database is transferred to a clean room where it is examined for personally identifiable information (PII) and masked or anonymized before being transferred to a non-production environment for testing.
Software release frequencies are continuously accelerating. The latest Capgemini/Sogeti Continuous Testing Report 2020 measured the release frequencies for 500 large enterprises in North America and Europe. The results, shown in the graphic below, indicate 61% of organizations are deploying a new build on a daily or weekly basis. Another 26% deploy code hourly, while some even deploy several times per hour.
As the technology leader in synthetic test data generation, GenRocket has created a new paradigm for Test Data Management (TDM) to meet the need for speed when testing in Agile and DevOps environments. Traditional TDM requires modernization. Copying, masking and subsetting production data is simply too time-consuming and cumbersome for the age of Agile.
Wikipedia defines dynamic data as information that changes asynchronously over time as new information becomes available. In financial services, the term is synonymous with transactional data, but the concept of dynamic data is not unique to financial transactions. Dynamic data can result from any change in state during the execution of an application workflow. To properly test workflows with dynamic state changes, the data used for testing must also be dynamic.
There is growing interest among quality assurance professionals in the use of synthetic data generation for software testing. Their interest in synthetic data is usually triggered by a requirement for data privacy or the need for accelerated data provisioning for Agile and DevOps. However, the most compelling reason to augment the use of production data, or manually created spreadsheet data, with synthetic data is to have total control over the variety of data needed to maximize test coverage.
Agile adoption is in full swing. According to the most recent State of Agile Report, it’s being adopted by 95% of organizations. That’s not to say it’s easy to accomplish an Agile transformation. In fact, 77% of organizations are still in the process of implementing its methodologies as they struggle with cultural, organizational and technological change.
Part 3 in the series: Moving from Test Automation to Intelligent Automation In part 2 of this series, Data Modeling and Referential Integrity, we explored GenRocket’s ability to reproduce the structure of any database, file format or data interface standard by importing a data model and establishing referential integrity between related data tables. This capability allows a data architect to establish a framework for testers to generate any volume or variety of test data that conforms to the structure of application data sources. In GenRocket’s component architecture, data tables are referred to as Domains while columns, are referred to as Attributes. In addition to data tables in a database, Domains can define any real-world object. Think of a Domain as you would a noun: a person, place or thing.