The end of end-to-end testing

Blog!

It is time for a paradigm shift: end-to-end testing has come to an end, it is time for a new test standard. What should this new test approach look like? In this blog Peter and Serghei explain why and how they have replaced end-to-end testing with their own method.

For years, the focus has been on end-to-end testing. But hasn't the expiration date of this test approach long since passed? Because the more Micro Services are developed and the more dependencies arise between these services, the more complex end-to-end testing has become. Can't we test in a faster, simpler and more autonomous way? 

It is time for a paradigm shift: end-to-end testing has come to an end, it is time for a new test standard. What should this new test approach look like? In this blog Peter and Serghei explain why and how they have replaced end-to-end testing with their own method.

The cracks in end-to-end
DevOps is the new standard in software development. In today's agile world, new functionality is quickly being put on the table in bite-sized chunks. This also directly requires the short-cycle test and small pieces of functionality. However, that is becoming increasingly difficult, because the different Micro Services that you want to test are used by various applications. All these services are connected in one integrated, comprehensive network in which every small change has an impact on other aspects. That makes end-to-end testing always complex and time-consuming.

No ownership and test data 
DevOps and the increasing complexity of integrated Micro Services also have a negative impact on other test facets. There is less and less ownership over applications and associated testing, which means that there is increasingly no up-to-date test data available. The lack of ownership also leads to poor coordination between departments, support teams, tribes and other stakeholders.  With the ultimate result that as an IT organization you lose control over testing.

How do you regain control?
You often see that IT departments minimize the number of end-to-end tests. If that does not have the desired effect, they will see if they can test in another way. For example, by making both a 'shift right' and a 'shift left '. In that case, they will test earlier in the development chain and monitor later in the chain. "In itself a good solution, by moving to the right and left, but with this you still have the end-to-end test. We go a step further by completely removing the end-to-end test.

The new way of testing

CBT

It should be clear: end-to-end testing is no longer suitable for the current testing challenges. But how should you test? Autonomy has to be central. Teams must be able to decide for themselves what and when they test. This way, as an organization, you can also quickly release new software. Focus on Contract Based Testing, which should be a central part of the testing process. Other components such as end-to-end testing and system integration testing can be omitted.   

The benefits? 
The new approach regarding testing  has different business and IT advantages. You create autonomous, stable systems. That is one of the important advantages. In addition, you are able to test on a small scale, locally. This allows you to identify and solve issues at an early stage. Another big advantage is the time savings: you no longer have to perform all those end-to-end tests. And the experience is that with this approach you sometimes win weeks!

But…
Before you start, think about the following questions:

  • How do you set up the test process with Behavior Driven Development and Test Driven Development?
  • Where in the process will the user- and acceptance tests be done?
  • How do you use stubs to test and accelerate?
     

Published: 4 January 2023

Authors:  Peter Geurtsen
                   Serghei Pogodin

 

 

 

 

 

CBT