No content

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.

Focus

Traditional Shift-Left Testing Image from https://www.katalon.com/resources-center/blog/shift-left-testing-approach/

Traditional Shift-Left Testing Image from https://www.katalon.com/resources-center/blog/shift-left-testing-approach/

How are we organized

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

What we are trying to achieve What • Fast feedback Why • To deliver a reliable product How • Verifying all the stages automatically

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

Previous approach Tests we do, and automate Unit Integration Database API Web Backend | Frontend Engineer Backend | Frontend Engineer Quality Engineer Quality Engineer Quality Engineer

Non-technical steps

Non-technical steps: be present • 3 amigos • “Heavy” refinements sessions • DoD of the User Stories • Fully tested in all required levels

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

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

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

Surrounding areas

Pipelines • Everything is a “pipeline” • Regular CI/CD pipeline • Execution of any manual steps/commands • Reaggregated test suite executions

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

What is our target

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?

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

LinkedIn | Twitter | GitHub. @eliasnogueira Blog. eliasnogueira.com Scam Me!