Systemic viewState of mind
Any change needs to incorporate more holistic thinking to ensure the scope and actions required
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
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] :
- Test during the sprint rather than at the end or after the sprint
- Prevent bugs rather than look for them
- Understand what to test rather than check functionality
- Design a better system rather than trying to break the software
- The team is responsible for the quality of the product rather than the testers being responsible for the quality.
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
- [Cohn 2009] : Mike Cohn - 2009 - « Succeeding with Agile: Software Development Using Scrum » - ISBN-13: 978-0321579362
- [Conway 1968] : Melvin Conway - 1968 - « How do Committee Invent ? » - Datamation magazine - http://www.melconway.com/Home/Committees_Paper.html
- [Evans 2004] : Eric Evans - FEV 2004 - “Domain-Driven Design: Tackling Complexity in the Heart of Software” - ISBN : 9780321125217
- [Laing 2016] : Samantha Laing, Karen Greaves - 2016 - « Growing Agile : A Coach’s Guide to Agile Testing » - https://leanpub.com/AgileTesting/read_sample
- [Moustier 2019-1] : Christophe Moustier – JUN 2019 – « Le test en mode agile » - ISBN 978-2-409-01943-2
- [Moustier 2020] : Christophe Moustier – OCT 2020 – « Conduite de tests agiles pour SAFe et LeSS » - ISBN : 978-2-409-02727-7
- [SAFe 2021-2] : SAFe - FEV 2021 - “Principle #2 – Apply systems thinking” - https://www.scaledagileframework.com/apply-systems-thinking/
- [SAFe 2021-4] : SAFe - FEV 2021 - “Principle #4 – Build incrementally with fast, integrated learning cycles” - https://www.scaledagileframework.com/build-incrementally-with-fast-integrated-learning-cycles/
- [Schwaber 2020] : Ken Schwaber et Jeff Sutherland - « Le Guide Définitif de Scrum : Les Règles de Jeu » - NOV 2020 - https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-French.pdf