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.

Elias Nogueira

September 30, 2021
Tweet

More Decks by Elias Nogueira

Other Decks in Programming

Transcript

  1. View Slide

  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.

    View Slide

  3. Focus

    View Slide

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

    View Slide

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

    View Slide

  6. How are we organized

    View Slide

  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

    View Slide

  8. What we are trying to achieve

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  12. Tests we do, and automate
    • Unit (backend, frontend)
    • Integration (backend, frontend)
    • Database testing
    • data migration
    • database upgrade
    • API
    • functional
    • e2e
    • Web

    View Slide

  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

    View Slide

  14. Non-technical steps

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  18. Automate first approach

    View Slide

  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

    View Slide

  20. Constant refactoring

    View Slide

  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

    View Slide

  22. Surrounding areas

    View Slide

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

    View Slide

  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

    View Slide

  25. Same process, some changes…
    Unit Integration Database
    API
    Web
    Backend | Frontend Engineer Backend | Frontend Engineer Quality Engineer
    Quality Engineer
    Quality Engineer
    Current approach

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  29. What is our target

    View Slide

  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

    View Slide

  31. Are we there?

    View Slide

  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

    View Slide

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

    View Slide