Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Technical Aspects of implementing the Shift Left Approach

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.

Baaa72bd2671a244ba9211e015f72d28?s=128

Elias Nogueira

September 30, 2021
Tweet

Transcript

  1. None
  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!