User Tools

Site Tools


devops:tests:testing_services

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
devops:tests:testing_services [2023/06/07 16:20] – removed - external edit (Unknown date) 127.0.0.1devops:tests:testing_services [2024/11/30 16:51] (current) – [Tactics, Approach] skipidar
Line 1: Line 1:
 +===== 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