Microservices Testing Strategies — Part 3

Post-Deployment Tests

System Integration Tests (E2E Tests)

System Integration Tests (SIT) ensure we build the right system and test how the application behaves in an integrated environment. We test the important user flows from start to finish to ensure their behaviours are expected. We should not use any mocks or stubs for system integration tests. All system components should be integrated. This way, we can ensure that system-level integration is working as expected. These tests take more time than others. Therefore, we need to test the critical business flows at the SIT level.

System Integration Tests (E2E Tests)
  • Prioritize the backlog.
  • Gather high-level business rules.
  • Elaborate on those business rules and create the steps for them.
  • Prepare required test data, endpoints, and expected results.
  • Start to write test scenarios based on the above inputs.
Gherkin Syntax
Sample SIT test case
SIT Pipeline

Performance Tests

After system integration tests are passed, we run the service-level performance testing. In microservices, we can do performance testing in several ways. First, we mock all external dependencies and hit the service endpoint directly to measure standalone service performance. This test gives us an isolated service performance.

Service Level Performance Testing
AppDynamics Ram and Garbage Collection Monitoring
Splunk CPU, Memory, IO, and Container Scaling Monitoring
Performance Testing Pipeline

Other Technical Tests

Chaos Testing

Chaos testing focuses on the resiliency and integrity of the system by proactively simulating failures through a simulated crisis. This way, we know the system behavior when unplanned and random disruptions happen. These disruptions can be technical, natural, or disasters like an earthquake affecting the servers.

© https://chaos.gremlin.com/rs/251-JGH-155/images/2018-06-Chaos_Monkey_Microsite_PDF.pdf

Mutation Testing

Mutation testing is another technique in which we inject mutants into our codes and check whether they are alive after the test execution. If these mutants are demolished, it is a good sign that our tests detect the failures; if not, the test code or test data should be improved. Mutation testing ensures the quality of our tests, not the service code itself, and they should be performed as early as possible in the PR pipelines.

Mutation Testing Flow Chart

Security and Vulnerability Tests and Scans

We added automated vulnerability and security scans in the service pipeline using Zed Attack Proxy. We scan our service with OWASP security and vulnerability rules in each new PR in the PR pipelines. We also use tools like ShiftLeft to check security problems as early as possible.

Exploratory Testing

Exploratory testing is an unscripted technique used to discover unknown issues during and after the software development process. We should do exploratory testing throughout the testing life cycle. We generally start exploratory testing after the requirement analysis phase as early as possible. This way, we can find the risks and problems earlier, which also helps automation test efforts. We use many inputs and outputs of exploratory testing sessions for test automation. In API exploratory testing, we use postman and insomnia tools. For exploratory testing details, you can check this article.

Test Data Approach

One of the biggest challenges in testing is test data, and we are following below essential points which are also stated in our test data strategy:

  • We have test data generation services and call those services’ endpoints to get freshly created test data for our scenarios.
  • If we have no options to create the test data automatically, we do a requirement analysis and create it manually or get help from the relevant teams for our needs.
  • We create new test data before execution and delete those after completion.
  • In test environments, we mask critical and confidential data.

Pre-Release Testing Approach

Before releasing our services to our customers, we do some pre-production verifications. Before production deployment, the service team should verify to cover their new changes and critical scenarios.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store