To ensure a good automated checks strategy without ending up with an inverted pyramid, we need to become more technical, we need to understand the architecture of the system we're testing.

The test pyramid concept was introduced to fix this problem that we keep seeing even today in the industry where all the testing and automated checks efforts are done through the UI. Even so, it is still a lot easier to add an UI test instead of understanding where a specific test would be ideally placed.

This session should give an example of a customised test pyramid (customised for our specific needs) consisting of unit tests, service layer tests (contract tests, service behaviour tests, services integration tests) and then the high level UI tests, where we should only have a handful number of personas exercising the system into an integrated environment. Presenting the architecture of our system, we'll see examples on how we've split it into multiple sub-systems so we can focus our checking efforts, ensuring we only run the impacted tests whenever we make a change in a specific area.

At the end, we should have a starting point of understanding better the scope of our automated checks - understanding the architecture of the system we're trying to verify.