During Threat Modeling and during the testing of the architecture with for example “residuality theory”
Thinking about problems wider then the current state or view.
When testing architecture instead of just looking at the architecture picture and telling whats wrong or right, you can add the question:
What if our competitors are going under our price
Barry uses the example: what if a regular car parks at a electric charger parking spot ‘I won’t make money on it’ – how do we solve this?
You can basically solve it by installing a camera with license plate recognition and still charge a fee.
What happens when a tsunami hits our city?
These are things to keep an eye out for and to be able to play into when it’s needed and then your architecture needs to support it.
Systems thinking shows us that customers are part of the system. This tells me that I need to understand customers and bring customers issues into how I test.
When there are relationships. Small talk is just one of them. If a tester is not sure whether a module needs to be prioritized for testing he could take the developers word “This is a very complex module” a bit seriously.