I have explained in the previous section how important synchronisation with our partners was.
Basically, it’s all about defining who tests what. To move forward, we had to define the testing scope of everybody, and to apply these tests in the proper order. Some would call that defining a testing strategy.
The point is that it doesn’t make sense to send a release candidate for validation to a partner if we haven’t finished our own checks. This has been seen over and over and over: we are confident in our work (and sometimes, in a hurry to get over with it) and so we throw it to the partners before we finished running our own non-regression tests. Virtually every time one of the following two cases happen:
- We find issues that need to be fixed, but our partner has already wasted time validating the release candidate and will have to start it all over once we have fixed the issues and deployed a new release candidate
- Our partner finds bugs and we realize that we would have find them by ourselves if we had finished running our own tests before asking for the partners to start validating the release candidate
In both cases, it will degrade our relationship with our partners as it will send the signal that we don’t value their time. One direct consequence is that it will be harder to book their time to perform the validation of our release candidates in a timely fashion. Which will lead in turn to a bottleneck in our release pipe, thus slowing us down.
Trying to go faster by rushing and not following the process will lead to a slow-down. You simply cannot get ahead of yourself.
Smart risk mitigation