Focus on the entire solutionState of mind
Trying to get rid of the unnecessary and constantly optimising
The importance to focus on the entire solution
A customer does not buy a part of a solution but a whole, and as long as a team's development is not integrated into the product, it has no value. With this in mind, the DoD should therefore include integration and not just the realisation of the code for a given User Story (US) [LeSS 2021-1].
Furthermore, an improvement of a part of the product must be seen in the whole solution and even if a choice is made between a local optimisation of the system and a global improvement, LeSS proposes the whole product instead.
Indeed, a new, more efficient version of a business process that is inconsistent with other processes is unlikely to be perceived positively by customers. It is therefore important to involve the teams in a process where all are aligned with this objective.
This systemic aspect is all the more reinforced if the product is the result of collaboration between different engineering sectors, such as the medical or automotive sector, which brings together software development, electronics, mechanics, etc. In agility, this multi-domain approach is possible thanks to the Model-Based System Engineering (MBSE) approach [Moustier 2020] and clearly shows the need to grow the product as a whole and not just a part of it: if the code does not allow an innovation linked to the hardware to be piloted, nobody will be able to use it.
Thus, to address this underlying systems approach, Peter W. Senge proposes eleven laws [Senge 1994]:
- Today's problems come from yesterday's 'solutions'.
- The harder you push, the harder the system will push you back.
- Behaviour gets better before it gets worse.
- The easy way out usually brings you back to the office.
- The cure can be worse than the disease.
- Wanting to move faster slows you down.
- Cause and effect are not closely related in time and space.
- Small changes can produce big results... but the areas where the leverage is highest are often the least obvious.
- You can have your cake and eat it too, but not immediately.
- Splitting an elephant in half does not produce two little elephants.
- Do not throw stones.
In this perspective, there are tools that facilitate the systemic approach to product engineering and align business, management and technology, including :
- Impact Mapping [Adzic 2013].
- Event Storming [Brandolini 2019]
- Story Mapping [Patton 2014]
Application to test maturity
To support the systemic view of the solution, the testing effort will inevitably need to integrate the four quadrants of agile testing [Marick 2003][Bach 2014][Crispin 2021] so as to address many aspects of testing including non-functional requirements [Hage Chahine 2018].
However, in order to address the full range of aspects expected by the system, the incremental, paced and synchronised approach sometimes implies being able to test a partially completed product without wanting to impact all of its customers. For this, practices such as Dark Launch or Canary Releasing can be used.
If we want to have a systemic vision of testing, PanTesting [Moustier 2020] allows us to address a holistic approach to agile testing at scale by introducing the concepts of:
which are combined with testability.
Agilitest's position on this practice
Agilitest is a tool for automating test scripts and in this systemic vision of the product, it is of high added value to combine the use of this tool with the practice of ubiquitous language to reflect the parts of the domain that are tested automatically.
Furthermore, to facilitate the provision of an expected part, Agilitest's #nocode approach [Forsyth 2021] allows for simple and quick test automation.
To go further
- [Adzic 2013] : Gojko Adzic - DEC 2013 - “Impact Mapping” - ISBN 9784798136707
- [Bach 2014] : James Bach - « The Real Agile Testing Quadrant » - SEP/2014 - http://www.developsense.com/presentations/2014-06-Dublin-RSTAgileTesting.pdf
- [Brandolini 2019] : Alberto Brandolini - « Introducing EventStorming » - Leanpub - 2019 - https://leanpub.com/introducing_eventstorming
- [Crispin 2021] : Lisa Crispin & Janet Gregory - JAN 2021 - “Applying the Agile Testing Quadrants to Continuous Delivery and DevOps Culture – Part 2 of 2“ - https://agiletester.ca/applying-the-agile-testing-quadrants-to-continuous-delivery-and-devops-culture-part-2-of-2/
- [Forsyth 2021] : Alexander Forsyth – JAN 2021 - « Low-Code and No-Code: What’s the Difference and When to Use What? » - https://www.outsystems.com/blog/posts/low-code-vs-no-code/
- [Hage Chahine 2018] : Marc Hage Chahine - JUL 2018 - “Types de tests (ISO 25 010): les tests fonctionnels (1/8)“ - https://latavernedutesteur.fr/2018/07/02/types-de-tests-iso-25-010-les-tests-fonctionnels-1-8/ et les articles suivants
- [LeSS 2021-1] : LeSS - 2021 - “Whole Product Focus“ - https://less.works/less/principles/whole-product-focus
- [Marick 2003] : Brian Marick - « Agile testing directions : tests and examples » - 22/AOU/2003 - http://www.exampler.com/old-blog/2003/08/22/#agile-testing-project-2
- [Moustier 2020] : Christophe Moustier – OCT 2020 – « Conduite de tests agiles pour SAFe et LeSS » - ISBN : 978-2-409-02727-7
- [Patton 2014] : Jeff Patton - « User Story Mapping » - O’Reilly - 2014 - ISBN 978-1491904909
- [Senge 1994] : Peter M. Senge - « The fifth discipline - the art and practice of the learning organization » - Currency Doubleday - 1994 - ISBN 0-385-26095-4