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
Nobody Cares About Your MTTR
This post outlines why IT metrics like MTTR are irrelevant to business leaders, and it emphasizes that IT teams need network observability to bridge this gap.
Rally Office Hours: October 2, 2025
The Rally Model Context Protocol (MCP) Server acts as a standardized interface for AI models and developer tools. Learn about this exciting new feature then follow the weekly Q&A session with Rally...
Why 1% Packet Loss Is the New 100% Outage
In an era of real-time apps and multiple clouds, the old rules about 'acceptable' network errors no longer apply. See why you need end-to-end observability.
Rally Office Hours: September 25, 2025
Rally Office Hours delivers an essential product tip: Learn to transition from Legacy Custom Pages to powerful Custom Views. Plus, Q&A insights.
Defining the Network Engineer of Tomorrow
Read this post and see why the most important investment isn't in new hardware, but in transforming your team from device managers to service delivery experts.
Harnessing AppNeta’s Browser- and HTTP-based Workflows to Track User Experience
AppNeta’s browser- and HTTP-based workflows let you see what users actually experience. Preempt issues before they become headaches for your end users.
“Rego U” Recap: Why SPM Is Still Hot
Rego Consulting’s Annual Conference underscored why strategic portfolio management (SPM) is still essential. Leverage SPM to bridge strategy and execution.
What's New in AutoSys 24.1: Built for the Modern Automation Landscape
See how AutoSys 24.1 is designed to streamline your daily tasks, accelerate troubleshooting, and simplify how you integrate with the latest technologies.
Rally Office Hours: September 18, 2025
In the latest edition of Rally office hours, learn about changes to the Progress Views widget and then follow the weekly Q&A session with Rally product experts.