Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Climbing the testing pyramid


Published on

In a company that was used to test the features in a more manual way, the continuous growth and the evolution to continuous delivery makes that the test mindset had to change. The way we were used to perform testing changed to adapt to the new needs of Continuous Delivery, where we need to be fast to validate the increasing number of builds while not losing confidence on the quality of the delivery.

We adopt the "shift left" strategy to testing and increase automation to fit to the CD strategy with a series of pipeline stages where we exercice different parts of the software increasingly so that when we reach the end we have very few validations to be made manually.

Starting to think on which types tests I should use for one given User Story and in wich levels of the pipeline should I use them introduce a challenge for our testers that were not used to think on testing this way.

So if you want to know the kind of gear you need to climb the testing pyramid in a CD environment keep in touch :)

Published in: Software
  • Be the first to comment

Climbing the testing pyramid

  1. 1. Climbing the Testing Pyramid Cristiano Cunha
  2. 2. Cristiano Cunha Started as a developer Worked in MobiComp, Maincheck, Blip and Farfetch Work in tests for 7 years Lead Automation Tester @Farfetch Who am I?
  3. 3. Main Features Dev01 Hotfix Release Branch strategy
  4. 4. Monotonous release process of deliveryIncrease
  5. 5. Evolution from agile
  6. 6. Continuous Delivery Building software in such a way that it can be released to production at any time. Martin Fowler ... Safely and quickly in a sustainable way. Jezz Humble
  7. 7. What major changes are needed? • Everything is in source control, E V E R Y T H I N G! • Everyone commits to main • Retrocompatibility • Independence of applications • Build generated automatically • Build deployed automatically • Reliable and stable environments: • Closest to live as possible (in terms of architecture, applications versions, configurations and databases) • Closed, nobody can do manual changes or access these environments • Dedicated, while the validation of a new application • Stable, possible to revert changes in a heartbeat • Defined process of update for applications, data and other software • Automated tests • Easy ways to understand what went wrong (reports, logs, monitorization) • Mindset change across all teams
  8. 8. Team Team Team Automation PerformanceSecurity Team Team Team Team Team Team Team Team Team Team
  9. 9. The Automation (Testing) Pyramid
  10. 10. Test Stages Component Tests Mock Tests System Tests Acceptance Tests
  11. 11. Component Tests Component Unit Unit Component
  12. 12. • ScopeSc Mock Tests Test Application under test Service 2Service 1 Mock Server
  13. 13. System Tests Target environment App 1 Service 1 Service 2 DB Test Machine Test 1 Test 2 DB
  14. 14. Acceptance Tests
  15. 15. How does it work in the pipeline?
  16. 16. Reports
  17. 17. Visibility
  18. 18. Follow evolution
  19. 19. Tools
  20. 20. Ready to climb? Thank you! C r i s t i a n o . c u n h a @ f a r f e t c h . c o m h t t p s : / / p t . l i n k e d i n . c o m / i n / c r i s t i a n o - c u n h a - 3 3 5 2 8 2 2 @ M e l i o t h