Tohuwabohu excorcism

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== 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/

{{https://agiletester.ca/wp-content/uploads/2020/12/Agile-Testing-Quadrants-768x521.jpg}}
====== Strategy  ======

==== Strategy as Trophy ====

https://kentcdodds.com/blog/static-vs-unit-vs-integration-vs-e2e-tests

{{https://s3.eu-central-1.amazonaws.com/alf-digital-wiki-pics/sharex/GmCNsXNsnu.png}}




==== Strategy as Testing Pyramid  ====

https://kentcdodds.com/blog/static-vs-unit-vs-integration-vs-e2e-tests

{{https://www.onpathtesting.com/hs-fs/hubfs/agile%20testing%20pyramid%20onpath%20testing%20QA.png?width=3891&name=agile%20testing%20pyramid%20onpath%20testing%20QA.png}}



==== Strategy Contract testing over Enterprise-wide-testing ====

LESS enterprise wide Test environment
https://www.thoughtworks.com/radar/techniques/summary/enterprise-wide-integration-test-environments

MORE Contract Testing
https://www.thoughtworks.com/radar/techniques/consumer-driven-contract-testing