The Shift-Left Testing and the Saga to the Continuous Delivery
Every year we are trying to improve the development process in the context we are working on, with one main goal: to deliver a reliable application, as fast as we can, to the customers. One of the approaches many companies follow is Continuous Delivery, which will allow us to deliver continuously, with confidence, what we've developed. One of the key aspects is to check the application, which means testing it, at different moments, to make the application reliable.
In the context I'm inserted, a group of engineers (me included) has worked hard to create an approach based on our challenges, which include: how to deliver Java cloud-native applications asynchronously and bug-free?
This presentation will share the old process, the problems we were facing, and the approaches, tools, and techniques we used to test the Java applications on different levels (unit, integration, database, API functional, and e2e tests) reducing the full product validation from days to hours.
- Learn Java-focused tools to achieve the Continuous Delivery process
- Learn different levels to apply testing for a Continuous Delivery process
- Hear a real experience history containing not only wins but failures
We have modified the way of working since the requirements creation will be the last testing stage. Technically speaking we had implemented:
- parallel integration test execution for different databases using TestContainers
- transform quality engineers tests (mostly at the end of the process) into integration tests
- data and database automatic upgrades
- custom docker image generation to run e2e API tests in an ephemeral environment
Testing is one of the key aspects to apply the Continuous Delivery approach but can be hard to apply if now done in a smart way. How we can balance the different test types and levels is the main challenge we have. Discover how a group of smart engineers is shaping it to deliver Java cloud-native applications for different banks around the world.
The presentation can focus more on the experience we had applied the shift-left testing approach, problems, and solutions (no code involved during the presentation) or can show the technical implementation done in the code + infrastructure (more code involved)