Microservice Architecture Testing

Adoption of Microservices architecture has influenced SDLC and introduce many quality challenges. For example:

• Increased dependencies over various microservices.
• Roadblocks in parallel development.
• Traditional methods of testing is impacted.
• Potential points of failure in application.

Increased dependencies over various Microservices

Microservices architecture involves dividing a big application or service into more logical and isolated components. This method of testing adds value with respect to scaling and flexibility for change. To configure and provision complete test environment setup is exponentially more complex in this architecture.

For example, Consider a application which involve one application with 10 services before microservices migration and each of these web services has 10 operations and a microservice is developed for each operation (10 times 10). Original test environment requires access to 10 web services only, but test environment with microservices architecture will require access to 100 microservices each of which must be properly configured for all test scenarios.

Roadblocks in Parallel Development

The increased number of system dependencies due to introduction of microservices complicates the coordination in parallel development. As the number of microservices increase, the more challenges developers/testers needs to face to develop and release new functionality in parallel.

Traditional Method of Testing is impacted

Microservices requires a more comprehensive approach of testing at message layer itself.

Validating each independent microservice is just the initial step. It is critical to test all transaction paths through more distributed microservices.

Microservices provides the ability to enable rapid change but it is also important to understand below points while choosing this architecture:

• Changes associated with the service itself.
• Service dependencies when any change occurred in application.
• Impact of change on critical end-to-end transactions.
• Impact of change on end user experience.
• New requirements for test data.
• Impact on non-functional requirements such as performance, reliability and accessibility etc.

Potential Points of Failure in Application

Microservices migration involves introduction of various independent points of failure. Lets return to our previous example, a failure in single web service might impact all 10 operations. But migration to 10 separate microservices, a failure in any single service may or may not impact other nine services.

Testing teams should monitor broader array of test dependencies among multiple web services.

Testing teams should have access to test environments which encapsulate highly componentized and distributed architecture.