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.
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.
How are we organized https://less.works Backend Engineers Frontend Engineers Quality Engineers TWO PAIRS OF SPECIALIZED ENGINEER PER TEAM DELIVERING CLOUD-NATIVE APPS
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
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
Tests we do, and automate • Unit (backend, frontend) • Integration (backend, frontend) • Database testing • data migration • database upgrade • API • functional • e2e • Web
Non-technical steps: be present User Story Acceptance Criteria e2e Integration Unit Shared decision to place the AC in the right level Acceptance Criteria
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
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
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
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
Same process, some changes… Unit Integration Database API Web Backend | Frontend Engineer Backend | Frontend Engineer Quality Engineer Quality Engineer Quality Engineer Current approach
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
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
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
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
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