What specific types of software applications are best suited for end-to-end testing?

Also called “e2es”, this type of testing verifies your entire software application to ensure that it functions correctly and meets all user requirements. In the “world” of testing, we all know that the “User requirements” are a textbook for the entire application. Everything starts with a product owner who understands the user requirements, shifts the knowledge to the developers who build the app based on them, and then we (the testers) come into the spotlight.

At Zenitech, we use different testing techniques to take the developers’ work and compare it with the “bible”, aka “user requirements”. Every tester needs some help; therefore, it’s either a pair/team of QA’s that test the entire software or a single QA helped by a machine concept, also known as automation. 

At Zenitech, based on our client’s requirements, we usually use a single QA tester per team (if the project is significant). From Zenitech’s perspective, a fully “grown” tester has to be able to perform three things: Manual Testing, Automation Testing and Business Analysis. 

The fun part starts with helping your mind to understand the manual testing concept. Creating test scenarios will later serve for both manual and automation testing, which is why I believe that the two do not exclude one another. The Business analysis part will help you prioritise the testing scenarios based on the user’s needs. 

So going back to where we’ve started, e2es are used for helping testers encapsulate in a small amount of time several testing techniques while simulating actual user behaviour.

At Zenitech, we believe that e2es are “testers’ little helpers” that use happy flows to run some of the created scenarios implying that there will be no reason for manually rerunning them.

How does Zenitech manage the trade-off between the benefits and disadvantages of using end-to-end testing?

Like all things in life, end-to-end tests have benefits and disadvantages. Here are some benefits that we encountered in our company:

  • We’ve expanded the testing coverage of our software team. We could add more convoluted scenarios used previously by the unit and functional tests.
  • Our project ran smoothly when executing test cases rooted in the end user’s behaviour.
  • We could reduce the number of critical issues on our project as e2e’s were used and executed repeatedly before releasing.
  • We could detect a significant number of issues before release.
  • It was easy to write.
  • We could constantly enhance user experience.

And some disadvantages:

  • It took a great deal of time to write the e2e’s and simulate actual user behaviour.
  • The most challenging part was ensuring that tests weren’t flaky and running them locally and in a CI pipeline.

Now, after understanding the advantages and disadvantages of the end-to-end testing technique, we can dive in even more profound. 

Horizontal vs. vertical testing

There are two types of end-to-end testing, whether manual or automated: horizontal and vertical. Hence, the flat type covers the entire application, while the vertical type breaks it into several layers. The vertical type is usually performed before the horizontal one because of its granularity, quickly identifying bugs. Both of them are wielded differently depending on the application that is under development. In our project, we used the vertical type. 

We broke down our extensive application into layers, each tested separately. This way, we covered the entire project by giving each part of it a place in the spotlight.

Our best practices

Through time we’ve discovered several best/standard practices that we continue using in our company:

  1. Upon writing test cases, test like the user. Try to develop a mindset for someone less tech-savvy using your software application for the first time; therefore, everything must be user-friendly and displayed clearly.
  2. We design test cases using acceptance testing documentation(if any); otherwise, we use the PO’s user stories to understand the customer’s point of view. 
  3. Take your time to learn the entire app by testing it manually. It will help you design test cases faster, learn weaknesses and spot differences. By learning the app first, your test cases will be based on instinct –  an instinct developed by understanding both the app and the user’s needs. Discipline your mind to understand the user’s point of view.
  4. Use e2e’s to test the most vulnerable part of the app, otherwise called the amount that will generate the most issues. 
  5. Use the “waiting” steps in your code. It will make the test cleaner and let the automated tool “take a break” between degrees. 
  6. If you got more than one e2e test for a feature, run them one after another; this way, you create an e2e flow that will also work in the pipeline.
  7. Avoid using e2es to test corner cases. For that, you can use integration tests. Use e2es to create common test cases.
  8. Run unit and integration tests in the beginning, to solve problems early.
  9. Create a constants file for each feature and keep it clean.
  10. Avoid copy-pasting e2es code from one feature to another; the best will be to create a generic code file where you write more generic steps that can be used for a bunch of e2es. 
  11. Each test should be able to run independently (i.e. not rely on another for setup).
  12. ‘Tear down’ at the end so that your data/app is back where it started before moving on to the next test.

Tools and frameworks

Regarding tools, each company adapts to the needs of the application under test. 

At Zenitech, we used the Cucumber tool and that helped a lot. Cucumber supports behaviour-driven development while keeping an ordinary language parser named Gherkin in the spotlight. It allowed us to write our testing scenarios in English and transform them into coding language. 

Earlier, we used to utilise Puppeteer, but its most significant downside was that it was only built for Chrome; for us to test on several browsers, we’ve “upgraded” to Cypress. 

Currently, for our business platform client, we use Cypress. The best part of it is the debugging. After a test is executed, a video of it is saved locally, which makes debugging very easy. By watching the video, we can see where the test failed. This also helps with the flaky tests by debugging them step by step. 

Cypress is a modern-web testing tool that helps us write our tests clearer and simpler while the async/await functions are not needed anymore to wait for commands and assertions.

Zenitech’s employee benefits platform uses Selenium and Java mainly because Selenium supports cross-browser testing and also different coding languages.

Key takeaways

Zenitech employs end-to-end software testing (e2es) as an essential method to validate the functionality and effectiveness of its software applications. It involves utilising manual testing, automation testing, and business analysis, usually conducted by a single QA tester per team, to cater to the client’s needs. The benefits of e2es are extensive, including expanded testing coverage, smoother execution of test cases, reduced critical issues, and an improved user experience. Nevertheless, some obstacles exist, such as the time involved in writing the e2es and the difficulty in ensuring tests aren’t flawed. Prioritising a vertical approach, Zenitech breaks its application into layers for a more manageable and efficient testing process.