Simple End-To-End Testing

What Is End-To-End Testing?

End-to-End (E2E) testing is software testing that exercises the application and its integration with external systems. It falls into the testing and integration phase of the software development life cycle (SDLC). 

E2E testing also validates the processing of incoming and outgoing data. This testing commonly occurs after system and functional testing. The goal is to simulate production-like scenarios using data and environments configured to mimic production.

Why Do End-To-End Testing?

Today’s applications are complex and have contracts with multiple subsystems. The risk of software failure grows with each dependency. This interconnectivity calls for a more rigorous testing regimen.

The benefits of end-to-end testing are numerous. They give us insight into application health. We will find out if the application functions as expected. E2E testing expands our test coverage beyond functional testing. We are now testing the system holistically instead of modularly. Finally, with this increased inspection, end-to-end testing provides an opportunity to uncover catastrophic failures.

End-To-End Testing Prerequisites

There are several activities you’ll need to complete before getting started with end-to-end testing:

• Identify and review the requirements that will be validated during E2E testing. This is a great opportunity to reach out to the lead analyst and developer to help solidify your understanding of the requirements.
• Review the System Flow Diagram to understand where your inputs will be coming from and where your outputs will be going. 
• Define the system and subsystem processes. This is helpful in identifying where data validation should occur.
• Describe the roles and responsibilities of all systems. Think of this as a contextual narrative to the system flow diagram.
• Define the testing methodologies and standards that will be used. More often than not, your end-to-end testing will be across a transaction of some sort. Sign up for a newsletter; receive an email with a call to action (CTA); click CTA link (possibly with tracking); get directed to the landing page; finally, opt out of future communications.
• List the input and output data expected for each system. This is the data you will validate in each of the respective subsystems.

Create End-To-End Test Cases

It is time to tackle the “how” of end-to-end testing, now that the concerns of what it is, why it is important, and the activities needed to get started have been addressed. The good news is that most of the heavy lifting is done. The exercise now is to organize everything into logical pieces. This design exercise has three distinct parts that build upon the other:

• Build a list of user functions using the information gathered on all of the system and subsystem features. Combine that with the relevant input data, actions, and output data needed for each function. Now is a great opportunity to sort functions to discover which can be reused. Borrow the don’t repeat yourself, or DRY, principle of programming here.
• Determine the conditions that need to exist in order to test the user functions. Is there a particular sequence and cadence in a CRM email campaign? Is the system expected to handle duplicate data?
• Build a list of test scenarios and test cases for each of the user functions

Watch this space for an example. I’m thinking about using some of Barry Williams’ data. Check out some of my other post in the meantime.