Functions As Designed

Many customers have different requirements or requirements that change backwards and forwards over time, especially in an early stage of the project. The developer's weapon against such ping-pong requirement changes are :

make it all configurable

Whatever the customer sets is what he gets, even if the settings don't make any sense in their combination.

It is awkward if you have changes to existing behavior without noticing the parties concerned.
Testers raise defects whereas the symptoms are more a result of new features implemented and activated by default rather than actual defects.

We have an unwritten law that guarantees customers don't need to adapt their configuration files just to ensure existing functionality doesn't get changed due to some (unwanted) new features or restrictions in the use of some old existing features.

It is not only unpleasant for the customer, our test scripts won't work either. Well, that's the good thing of test automation. We wouldn't have detected those anomalies at the same speed as if we had done this test manually. However, we still struggle with a straight reaction to the findings. There are still some roadblocks to master.