In my prior blog, Continuous Test Data Management for Microservices, Part 1, we offered an introduction to the key approaches for applying continuous test data management (TDM) to microservices.
The continuous TDM process for microservices applications is similar to that for general continuous TDM (see figure below), but tailored to the nuances of the architecture. In this post, I’ll outline the key steps for applying TDM across the lifecycle.
Step 1(b): Agile Design
Rigorous change impact analysis during this step is key to reducing the testing (and the TDM) burden for microservices applications—especially in the upper layers of the test pyramid and the CD stages of the lifecycle. There are various ways to do this, following are a few highlights:
- Code-change-based impact analysis (also known as a white-box, inside-out approach). Through this approach, we identify which services and transactions are affected by specific code changes in implementing backlog requirements. We then focus testing and TDM efforts on those services and transactions affected (see figure below). This approach is supported by tools such as Broadcom TestAdvisor and Microsoft Test Impact Analysis. This approach is more useful for white and gray box testing, specifically unit and component testing.
- Model flow-based impact analysis (also known as a black-box, outside-in approach). Here we do change impact analysis using flows in model-based testing. This analysis helps to highlight key end-to-end or system integration scenarios that need to be tested, and can also be traced down to individual components and source code (see figure below). This approach is supported by such tools as Broadcom Agile Requirements Designer, and is more beneficial for testing in the upper layers of the test pyramid.
We recommend a combination of both approaches to ensure sufficient test coverage, while minimizing the number of tests in a microservices context. Based on the change impact set, we prepare test data for the tests discussed above.
Step 2(a): Agile Parallel Development
As discussed in the previous section, as part of development, a component developer must also define and implement these APIs:
- APIs that allow us to set test data values in the component data store. These are sometimes referred to as mutator APIs.
- APIs that allow us to extract test data values, for example, from instances of components in production. These are also known as accessor APIs.
Developers should use the white-box change impact testing technique discussed above to focus their unit and component testing efforts.
Step 2(b): Agile Parallel Testing
This is an important stage in which testers and test data engineers design, or potentially generate or refresh, the test data for test scenarios that have been affected by changes and that will be run in subsequent stages of the CI/CD lifecycle. This assessment is based on the backlog items under development. Testers use the TDM approaches described above for cross-service system testing and end-to-end testing.
In addition, the test data will need to be packaged, for example, in containers or using virtual data copies. This approach can ease and speed provisioning into the appropriate test environment, along with test scripts and other artifacts.
Step 3: Build
In this step, we typically run automated build verification tests and component regression tests using the test data generated in the previous step.
Step 4: Testing in the CD Lifecycle Stages
The focus in these stages is to run tests in the upper layers of the test pyramid using test data created during step 2(b). See figure below. The key in these stages is to minimize the elapsed time TDM activities require. This is an important consideration: The time required to create, provision, or deploy test data must not exceed the time it takes to deploy the application in each stage.
How do we get started with continuous TDM for microservices?
Continuous TDM is meant to be practiced in conjunction with continuous testing. Various resources offer insights into evolving to continuous testing. If you are already practicing continuous testing with microservices, and want to move to continuous TDM, our recommendation is to proceed as follows:
- For new functionality, follow the TDM approach we have described.
- For existing software, you may choose to focus continuous TDM efforts on the most problematic or change-prone application components, since those are the ones you need to test most often. It would help to model the tests related to those components, since you can derive the benefits of combining TDM with model-based testing. While focusing on TDM for these components, aggressively virtualize dependencies on other legacy components, which can lighten your overall TDM burden. In addition, developers must provide APIs to update and access the test data for their components.
- For other components that do not change as often, you need to test less often. As described above, virtualize these components while testing others as needed. In this way, teams can address TDM needs as part of technical debt remediation for these components.
Conclusion
This two-part blog series has provided an overall approach for continuous TDM practices for microservices. As you can probably tell, such component-based applications are extremely well suited to supporting continuous TDM. This is true because these applications are modular and componentized.
Stay well, my friends, and may all your microservices TDM efforts be continuous!
Shamim Ahmed
Shamim is a thought leader in DevOps, Continuous Delivery, Continuous Testing and Application Life-cycle Management (ALM). He has more than 15 years of experience in large-scale application design and development, software product development and R&D, application quality assurance and testing, organizational quality...
Other resources you might be interested in
DX NetOps: Harness Syslog for Operational Visibility
Learn how to configure DX NetOps for robust syslog ingestion, gaining comprehensive operational visibility by displaying all external syslog messages directly within DX NetOps Portal.
Rally Office Hours: September 4, 2025
In the latest edition of Rally office hours, learn how to view filter substitutions and then follow the weekly Q&A session with Rally product experts.
Rally Office Hours: September 11, 2025
Hear about recruiting MCP Server early adopters and ancestor filtering in Rally's Custom Lists, then follow the weekly Q&A session with Rally product experts.
Powering RAG Pipelines With Automic Automation
See how Automic Automation optimally equips you for the AI revolution, combining proven enterprise capabilities with the potential of generative AI.
Unlock Real-Time AWS Observability With Streaming Ingestion in DX Operational Observability
With streaming ingestion capabilities, DX Operational Observability offers visibility into your AWS telemetry, enhancing insights and incident response.
Observability and IT Monitoring Governance: Establishing Order (Part 3 of 4)
Find out how DX Unified Infrastructure Management (DX UIM) supports monitoring governance, enabling teams to manage configurations and track alarm policies.
Observability and IT Monitoring Governance (Part 4 of 4)
This post shows how baselines, KPIs, and thresholds are essential for monitoring governance. See how IT can shift from reactive to proactive IT management.
What's Really Happening in Your Branch Office Network?
Fragmented monitoring tools create critical visibility gaps in branch networks. Find out why you need network observability to pinpoint the cause of issues.
Rally Office Hours: August 28, 2025
Learn about the general availability of the AI writing assistant in Rally, then follow the weekly Q&A session with Rally product experts.