Testing Services

Motivation

Micro Services need "Loosely Coupled Organizations"

Micro services work best with an organizational shift towards “Loosely Coupled Organizations” .

Throughout the book, I’ve made the case for a loosely coupled architecture and argued that alignment with more autonomous, loosely coupled, stream-aligned teams is likely going to deliver the best outcomes. A shift to a microservice architecture without a shift in organizational structure will blunt the usefulness of microservices—you may end up paying the (considerable) cost for the architectural change, without getting the return on your investment. I’ve written generally about the need to reduce coordination between teams to help speed up delivery, which in turn enables teams to make more decisions for themselves.

Building Microservices, 2nd Edition by Sam Newman

https://www.oreilly.com/library/view/building-microservices-2nd/9781492034018/ch15.html

Low Autonomy Precludes Continuous Business Value

Designing Autonomous Teams and Services by Nick Tune, Scott Millett https://www.oreilly.com/library/view/designing-autonomous-teams/9781491994320/ch01.html

Loosely Coupled Organizations are ...

What make a team: “Loosely Coupled” ?

Characteristics of autonomous, loosley coupled teams, to achieve the best performance:

Make large scaled changes, to the design of their systems, without the permission of anybody outside the team
Complete their work, without communicating and coordinating with people outside their team
Deploy and release their service on demand, regardless other services it depends upon
Do most of their testing on demand, without requiring an integrated test-environment
Perform deployments in normal business hours with negligiable hours.

Sam Newman about “Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, 2018 ” by Nicole Forsgren, Jez Humble, Gene Kim

https://kevinvecmanis.io/books/management/2020/11/20/Accelerate-Book-Review.html

End-to-end tests for any type of system are at the extreme end of the scale in terms of functionality they cover, and we are used to them being more problematic to write and maintain than smaller-scoped unit tests. Often this is worth it, though, because we want the confidence that comes from having an end-to-end test use our systems in the same way a user might. But with a microservice architecture, the scope of our end-to-end tests becomes very large. We would now need to run tests across multiple services, all of which need to be deployed and appropriately configured for the test scenarios. We also need to be prepared for the false negatives that occur when environmental issues, such as service instances dying or network time-outs of failed deployments, cause our tests to fail. These forces mean that as your microservice architecture grows, you will get a diminishing return on investment when it comes to end-to- end testing. The testing will cost more but won’t manage to give you the same level of confidence that it did in the past. This will drive you toward new forms of testing, such as contract-driven testing, as well as exploring release remediation techniques and ideas like testing in production.

Building Microservices, 2nd Edition}, Sam Newman, 2021, O'Reilly Media, Inc

Goal formulation

Achieve independent testing on-demand for teams, without any compromises on the software-quality.

Tactics, Approach

Most of the microservice-projects replace end-to-end tests.

TODO: confirm statement, find citation.

How to Measure: consider:

Brian Marick testing quadrant:

https://agiletester.ca/applying-the-agile-testing-quadrants-to-continuous-delivery-and-devops-culture-part-1-working-towards-continuous-delivery/

Strategy

Tohuwabohu excorcism

Table of Contents