We have all heard about the technique of Shift Left, where test activity is brought to the earlier stages of the life cycle. This is a great way to improve product development as it moves testing activities to the left, which removes ambiguity from the development team. This is enhanced with activities such as TDD, BDD and Model Based as shown below in Figure 1. I don’t like the old V model, but if you can imagine it is cycled through daily or faster you will get the idea.
Figure 1
What does happen here is that there are a number of types of testing, and the creation of the tests for these have all moved to the left. Tests effectively replace requirements. This removes imprecise language such as “The System Shall ….” and replaces it with language such as “Given, When, Then”
Using tests as requirements makes the language much tighter and allows automation of these tests, before any business logic is created. There are a number of well known frameworks for this type of automation such as Cucumber or FitNesse and a number at the unit level.
What about Shifting Right, if testing comes left what moves over to make room for it? In fact by bringing all these activities to the left, are we just becoming a waterfall from a different perspective by having to have these ready earlier?
This is why there are types of tests. For example Unit tests are written just in time. We create the Unit test as part of the business logic creation process. All the other test types are used to feed other activities, also in a just in time manner.
We should focus on the fact that tests are very much about the what of software. What will it do under various conditions. This is good because we leave the how to those who are best at it, the team. In fact the how is what is moving to the right. Consider three main factors for a requirement. Why, What and How. Why is something that is considered earlier and the why forms a vision which is then communicated. This vision is what enables later and local decisions within the team.
Armed with the Why and the evolving What the team can now work out the How. The How is the part that is moving to the right, in fact it is moving to the latest responsible moment. But we should be doing everything at the latest responsible moment because that is when we have the best knowledge.
Figure 2
The picture above shows a simplified path though a simple development. User Requirements are Why and What. The Architectural model is a What and How, where-as the Unit work is all about the How. But wait, this isn’t right either, where is the feedback and learning?
Let’s try again.
Figure 3
Similar picture which is stretching my graphical skills. The point I am trying to make is that the each horizontal slice is iterative. For example we may have a number of User Requirements Tests, but we don’t wait to finish writing them all before starting the architectural model. And the architectural model is the same story. So starting with one or a few tests we can drill down into the architectural level of abstraction, and then once a few of these tests are known we can start building the Units of product.
This sets up a series of feedback loops which are all active. Learning is being carried out at a number of levels, and refactoring is the response to some of these learnings. But doing this helps with making decisions once the most amount of information is available. In other words at the latest responsible moments. But we have moved the test activities to the left of each horizontal level.
Normally Figure 2 would be seen as a typical model for value stream mapping, but we now see it as being too simple. The reality is that our Value Stream does in fact have a number of feedback loops going on. When we describe a value stream we usually measure, processing time, wait time and percent complete and accurate. In this case we now need to include the time taken for the feedback loops, and reducing them in time could be the objective of continuous improvement.
These thoughts bring us to the small batch size discussions as a follow up from the latest responsible moment and shift left ones. Oh what a tangled web we weave. Don’t forget to join up the dots.
Leave a Reply