Then, of course, there are bugs when things just go out of date. For example, legislation changes for sales tax, a third-party API or library becomes defunct, a third-party service such as a Content Distribution Network is impacted, or people's tastes change to prefer touch/verbal interaction as technology advances. 

These may seem like the group of bugs that are least in our control. Dependence on a third party always causes issues that can involve a degree of disconnection and stretch the time these bugs take to resolve.

To some degree, third-party integration issues, such as deprecated methods, should be handled by notifications from the third party. However, I've known many instances where this hasn't happened. 

The key thing to mitigate the change around the boundaries of the system is to build a degree of resilience, sometimes known as graceful degradation of service, and to automate tests which look specifically for any change, for example, by automating notifications to flag a problem when integration with third-party software changes.

To do this, we have to run integration tests against the live third-party system. In some cases, this can be expensive to perform continuously for tests that we run in our development environment. I'm thinking both in terms of the time it takes to run, but also regarding cost—banks, for example, often have to pay per transaction.

In this instance, it's best to adopt a phased approach to integration testing by simulating the integration tests you run regularly with the third party. The trick with this approach is to re-record the transaction simulation against the live system when changes in the interface are noticed. 

In a phased approach, where we're trying to keep costs of running tests down, we can adopt the strategy that only the last set of tests in our CI/CD pipeline is run against the actual live system. If a change is noticed, we send a notification and stop the deployment.