{"id":47960,"date":"2022-06-14T11:27:51","date_gmt":"2022-06-14T15:27:51","guid":{"rendered":"https:\/\/sdtimes.com\/?p=47960"},"modified":"2022-08-24T12:17:23","modified_gmt":"2022-08-24T16:17:23","slug":"continuous-test-data-management-for-microservices-part-2-key-steps","status":"publish","type":"post","link":"https:\/\/sdtimes.com\/test\/continuous-test-data-management-for-microservices-part-2-key-steps\/","title":{"rendered":"Continuous test data management for microservices, Part 2: Key steps"},"content":{"rendered":"

This is part 2 in a series on applying test data management (TDM) to microservices. Part 1 can be found here<\/a>.\u00a0<\/em><\/p>\n

\n

The continuous TDM process for microservices applications is similar to that for general continuous TDM, but tailored to the nuances of the architecture. The key differences are as follows:\u00a0<\/span><\/p>\n

Step 1(b): Agile Design<\/strong><\/h5>\n

Rigorous change impact analysis during this step is key to reducing the testing (and the TDM) burden for microservices applications\u2014especially 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:\u00a0<\/span><\/p>\n

(a)<\/span> \u00a0 <\/span>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. This approach is supported by tools such as <\/span>Broadcom TestAdvisor<\/span><\/a> and <\/span>Microsoft Test Impact Analysis<\/span><\/a>. This approach is more useful for white and gray box testing, specifically unit and component testing.\u00a0\u00a0<\/span><\/p>\n

(b)<\/span>\u00a0 <\/span>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. This approach is supported by such tools as <\/span>Broadcom Agile Requirements Designer<\/span><\/a>, and is more beneficial for testing in the upper layers of the test pyramid.\u00a0<\/span><\/p>\n

I 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 in the previous section.\u00a0<\/span><\/p>\n

Step 2(a): Agile Parallel Development\u00a0<\/strong><\/h5>\n

As discussed in the previous section, as part of development, a component developer must also define and implement these APIs:<\/span><\/p>\n