Technical Aspects of implementing the Shift Left Approach

This presentation at the EuroSTART Testing Conference shows you how a company is applying the Shift-Left-Testing approach from a technical perspective.

Transcript

2. DISCLAIMER THIS PRESENTATION SHOWS HOW A COMPANY IS TRYING TO IMPLEMENT THE SHIFT-LEFT APPROACH FROM A TECHNICAL PERSPECTIVE. THIS WILL SHOW OUR APPROACH, STRUGGLES AND WHAT WE CAN SEE IS A GOOD PRACTICE BASED ON OUR CONTEXT.
3. Focus
4. Traditional Shift-Left Testing Image from https://www.katalon.com/resources-center/blog/shift-left-testing-approach/
5. Traditional Shift-Left Testing Image from https://www.katalon.com/resources-center/blog/shift-left-testing-approach/
6. How are we organized
7. How are we organized https://less.works Backend Engineers Frontend Engineers Quality Engineers TWO PAIRS OF SPECIALIZED ENGINEER PER TEAM DELIVERING CLOUD-NATIVE APPS
8. What we are trying to achieve
9. What we are trying to achieve What • Fast feedback Why • To deliver a reliable product How • Verifying all the stages automatically
10. What we are trying to achieve Actual We run our release in Waves because we have dependencies with different internal microservices. The “base” microservices are tested first, following the most used ones by the customer perspective in 3 different waves: • Wave 1: base microservices • Wave 2: most important microservices from the customer perspective • Wave 3: other microservices + frontend Release time: 1 week
11. What we are trying to achieve What we want We want to get rid of the Release Waves process by applying the Shift-Left Testing approach in all the possible ways. • No more 1-week testing • main branch deliverable any time • Fully continuous testing
12. Tests we do, and automate • Unit (backend, frontend) • Integration (backend, frontend) • Database testing • data migration • database upgrade • API • functional • e2e • Web
13. Previous approach Tests we do, and automate Unit Integration Database API Web Backend | Frontend Engineer Backend | Frontend Engineer Quality Engineer Quality Engineer Quality Engineer
14. Non-technical steps
15. Non-technical steps: be present • 3 amigos • “Heavy” refinements sessions • DoD of the User Stories • Fully tested in all required levels
16. Non-technical steps: be present User Story Acceptance Criteria e2e Integration Unit Shared decision to place the AC in the right level Acceptance Criteria
17. Non-technical steps: quality engineering • Quality Advocates • Works closely within the other technical + business roles • Technical Role • Coder in 4 different languages (Java, Typescript, Groovy, Bash) • Expertise in multiples technical areas • DevOps • Frontend • Backend
18. Automate first approach
19. Automate first approach • We write test automation for all the acceptance criteria (yes, all) • We choose the right level to automate • Heavy focus and coverage on the API layer • Anything manual become an automation script • Automation by the Quality Engineer in parallel with the backend | frontend engineers
20. Constant refactoring
21. Constant refactoring By analyzing the total test execution time, we do changes in the test automation framework to speed it up • Fast data ingestion • Smart use of base test classes • Avoiding unnecessary steps
22. Surrounding areas
23. Pipelines • Everything is a “pipeline” • Regular CI/CD pipeline • Execution of any manual steps/commands • Reaggregated test suite executions
24. Ephemeral environments • We have implemented the Ephemeral environment approach using Kubernetes • Spin up a full environment based on certain conditions • It allows us to create an environment based on: • any past version • the current in-development version • based on branches where we generate a docker image
25. Same process, some changes… Unit Integration Database API Web Backend | Frontend Engineer Backend | Frontend Engineer Quality Engineer Quality Engineer Quality Engineer Current approach
26. Current approach Same process, some changes… Unit Integration Database API Web Backend | Frontend Engineer Backend Engineer Frontend Engineer Quality Engineer Automatically done Quality Engineer Quality Engineer Yes, the Quality Engineers also write Integration Tests (API) moving the API Functional testes to the Integration layer
27. Current approach Same process, some changes… Unit Integration Database API Web Backend | Frontend Engineer Backend Engineer Frontend Engineer Quality Engineer Automatically done Quality Engineer Quality Engineer Automatically done in a pipeline that runs data migration and database upgrade during the merge process
28. Current approach Same process, some changes… Unit Integration Database API Web Backend | Frontend Engineer Backend Engineer Frontend Engineer Quality Engineer Automatically done Quality Engineer Quality Engineer Faster test suites by architectural changes in the testing framework + moving tests to the integration layer
29. What is our target
30. Our target Shift-Left Testing result Backend | Frontend Engineers push their changes Quality Engineers works in different levels, in parallel Multi Pipelines to test all the levels before merge
31. Are we there?
32. Are we there? NO! • Definition of OKRs to technical improvements • The environment is still a problem, but less troubled • Constant technical coach/mentoring in the Quality Engineers
33. LinkedIn | Twitter | GitHub. @eliasnogueira Blog. eliasnogueira.com Scam Me!