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

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