The coronavirus pandemic’s effect on the software development industry was not as devastating as for, say, arts and tourism. In fact, the industry demonstrated significant resilience. According to Statista, only about a third of IT specialists worldwide have reported either a significant impact on their work/studies or job losses. 

To adapt to the pandemic crisis, development teams had to reconsider their expenses and reduce cost whenever possible. Software testing often makes a top candidate for such reductions. According to the WQR 2020-21, the QA budget was reduced to 22% of the overall project cost. But is it possible to lower the cost of testing by focusing on select testing types only, without slashing it altogether? We’ll look into the matter.

Integration testing vs. E2E testing 

As we know, excessive testing increases the cost and time required. So how much testing is enough? Some experts believe it’s enough to have a 95% coverage. In other measurement units, the size of code for testing should include twice as many lines as that of the solution under test. On the other hand, experts argue that they may have efficient testing with only 85% of the solution covered. But in any case, going down the same road twice is far from being efficient. And this is how performing both integration and E2E testing may feel. 

Indeed, the two types of testing bear certain similarities. Integration testing checks the connectivity and communication between the solution modules responsible for a particular functionality. As a rule, integration testing targets two modules that need to interact to fulfill some function stipulated by the requirements. In practice, this effort boils down to checking if the query delivers the expected result. 

Unlike integration testing, E2E testing immediately checks how the entire system works. It allows testers to check the application subsystems and layers from the UI right to the database. Besides, there are two basic approaches to run an E2E test: vertical and horizontal. Vertical E2E is complex technically. This type of testing makes sure that the data travels across all solution components (the UI, API, and database) unhindered. Horizontal E2E recreates user stories from start to finish. Sounds familiar? It resembles integration testing very much. So is it possible to skip the latter and get down to comprehensive E2E testing right away? 

Are E2E and integration testing interchangeable?

Not really. Though the two testing types are alike, they offer a different focus. Thus, integration testing checks how two modules interact with one another or third-party solutions if project requirements call for it. As we can see, this is a purely technical matter, which makes this testing type a fine candidate for test automation. What’s more, in the present situation, software created by only one developer is a rare thing. It’s mostly the brainchild of dozens of developers scattered across several countries. Logically, developers differ in their skills and style of work. These differences may hamper module integration. In this case, integration tests work like a health check that identifies pain points to address. 

As for E2E testing, it is a testing type that automatically simulates user experience when working with the tool relying on the so-called user stories. Besides, as a rule, integration testing features only one process at a time. E2E testing may involve several processes and even the entire application if that is required by the user story. 

The power of E2E testing has gained recognition among all SDLC specialists. Some experts even argue that it can effectively replace the majority of other testing types. However, others state that such an approach may present a challenge by inverting the testing pyramid needlessly. This may result in additional time and effort required to set the testing part of a project back on track.

A useful tip 

As we can see, both testing types we discussed are needed as they cover different aspects of the software in question, and letting those bugs reach end-users may hurt the end results. So are there no optimization routes for those two testing types? Actually, there are. Let’s look at the testing pyramid again.

The pyramid describes the correlation between the three testing types—unit, integration, and E2E testing. Back in 2015, Google drafted a smart bottom-up combination granting 70% to unit tests, 20% to integration tests, and only 10% to E2E tests. But is it really a rule set in stone? The practice has shown it’s not. The proposed combination is effective for some projects and useless for others. Nowadays testing experts accept different variants of the testing pyramid. It may be normal, inverted with the minimal percentage of tests going to unit tests, and hour-glass-shaped where the minimal share of tests is allocated to integration testing. The choice of the type of pyramid fully depends on the specifics of the solution under test. 

Summing up

Integration and E2E testing types are not oppositional. They both check if implementing scripts helps yield the expected results. Hence, the two complement each other and help validate the quality of code in full.

Though neither of the two testing types is disposable, the team can choose their combination in accordance with their project’s specifics. This way they may save time and resources effectively.