TOAD is Testing, Observability And Devops. We think these three things are related. What would happen if we took each of the three aspects of TOAD and put strong emphasis on each in turn? What happens if we take our testing effort as far as it can go, and "dial it to 11"? Observability to 11? Devops to 11? The meaning of "dial to 11" will be different for different organizations: it might mean hiring staff, or investing in tools, or even just emphasizing the mission more than before.
If we dial testing to 11, I think two things will result. For one thing, the number of observable incidents in production will likely go down, because the emphasis on testing means that more problems will be found and fixed before deploying to prod. I also think that rate of deployments (Devops) could potentially increase, because the decrease in observable incidents will make deployments safer. So: increase the T in TOAD to decrease the O and increase the D.
With testing at 11, now we can dial Devops to 11. We can increase the rate that we deploy code to production, because testing has made deployment safer. With D at 11, what happens to T and O? I suspect the number of observable incidents will increase. We reduced the number of problems we deploy to prod, but now we are deploying more often, so it makes sense that the number of problems in production will increase.
With Devops at 11, now it is clear that we need to dial our Observability to 11. With more frequent deployments, it stands to reason that we would have more incidents to observe. We probably also have trickier and more sophisticated problems in production too, because our testing has been at 11 for a while now. So now we invest in observability because it makes sense.
So all of TOAD is dialed up to 11 now. Or is it? We know from our observability efforts that the number of observable incidents in production has increased. Clearly it is now time to revisit our Testing, because we can see it is no longer at 11, Observability and Devops have left it behind.
Invest in Testing to make better Devops possible while reducing Observable problems.
Then invest in Devops to get better features to production faster.
Then invest in Observability because the deploy rate is much faster.
Then repeat the cycle because improvements in any one area mean that the other areas will need to keep pace. In practice, I think we can dial all the parts of TOAD as high as they will go more or less simultaneously, but I think it is helpful to consider the effects of changing any one of Testing, Observability And Devops on the other two practices.