Microservices come with some testing difficulties due to the architecture being distributed, with constant and independent evolution of services. One has to test the individual services and their interactions with each other.
For me it’s just the same as API testing… just more APIs 
The only advise I could give is probably the same for API testing, right your tests in isolation.
Check the unit coverage and compare it to your API tests, don’t test the same things twice, so you’ll win some time there.
Have you read Martin Fowler’s articles on microservices? Particularly the deck on Testing Strategies?
The testing strategies deck is 10 years old, but I have yet to find a better explanation of what’s possible.
@ramanan49 Shift-Left Test strategy w.r.t API mocking using wiremock/mockoon and also contract testing using pact
Initially faced some challenges but when break test cases as individual for microservices it helped, as different dev team working on different microservice, team-a is ready with work and have dependency on team-b , which delay for running end-to-end test case.
Once have dependent microservice resolve, can run integration test
Another test I would suggest for chaos testing for microservices which will give insight and help if want to scale
There are various open source tool available for chaos
Thanks for sharing! It sounds like your team has made significant progress moving from waterfall to agile. Even though you’re still doing manual testing, the shift to DevOps and writing detailed user stories seems like it’s really improving clarity and quality for both enhancements and regulatory changes. I can relate—managing regulatory requirements alongside feature development can be tricky, but having a structured agile process definitely helps. Are you planning to introduce any automated testing in the future to complement the manual testing?