Systemic view

State of mind

Any change needs to incorporate more holistic thinking to ensure the scope and actions required

State of mind


SAFe applies this principle to understand software development as a whole because [SAFe 2021-2] :

  • the solution is a system in its own right
  • the company that builds this system is a system in its own right
  • this company must optimise the entire value stream
  • if the global system is not managed, it will not manage itself and will end up constituting autonomous but individual, independent parts that will compete with each other

Each part must therefore be pushed to cooperate.

If we look at collaborative modes, even if only at the level of architecture, Eric Evans, the creator of Domain-Driven Design (DDD), proposes a tool called "Context Mapping" which provides different modes of collaboration [Evans 2004] [Moustier 2020]:

  • "Separate path": the two groups have no impact on each other and can evolve separately
  • "Anti-corruption layer': the activities of one group are isolated from the others by a group that reflects the interactions with the subsystem that is then protected
  • "Conformist": one group must comply with changes pushed by another group
  • "Client-supplier relationship": changes in one group imply adaptation by the other group
  • "Shared core": several groups share requirements realised by a single entity
  • "Open host service": this is a generalisation of the anti-corruption layer to several groups that try to interact with a subsystem to be protected
  • "Partnership": when two groups have their successes and failures intimately linked
  • "Mudball": a context that is too amalgamated to draw simple relationships between groups in that context

Although DDD is presented as an architectural technique, it turns out that business organisation and architecture are strongly linked [Conway 1968] and justifies this parallel as a basis for thinking about an organisational and technical systems approach.

Application to test maturity

Testing has different sides, notably [Moustier 2019-1]:

  • the business side, which enables the production of relevant tests
  • the industrial side, which enables tests to be organised when the massification of resources (people, scenarios, data, environments, automation, etc.) is part of the environment
  • the systemic side, which allows us to go further in testing because when the first two aspects are mastered, testing will be limited by all those who produce the solution; it is then that the organisation must change to integrate testing into all parts such as :

                  ○    improving ideation to have testable User Stories

                  ○    improving development with unit tests and having a test pyramid in the right direction [Cohn 2009].

                  ○    asking developers to add identifiers to HTML widgets to make it easier to search

                  ○    integrate non-functional requirements into all phases of the product

                  ○    aso

Without a global approach, testing is limited to a reactive position and anticipation only leads to a tunnel effect. Agile, with its iterative and short approach [SAFe 2021-4], reduces this effect but leaves testers in a situation where they have very little time, leading them to test after the sprint when the Product Owner should have a potentially deliverable Product Increment [Schwaber 2020].

Thus, the contribution of the systems view in agile testing gives a kind of "Agile Testing Manifesto" [Laing 2016] [Moustier 2019-1] :

Agilitest's position on this practice

As an automation tool, Agilitest must be part of an automation approach or strategy. Its simplicity should not lead teams to delegate this automation to a group of people who must carry out the automation of tests, otherwise we will quickly find ourselves in the pitfalls mentioned above.

To discover the whole set of practices, click here.

To go further

© Christophe Moustier - 2021