Not too long ago, it was standard practice to have a very large team of Quality Assurance (QA) analysts. This department would act as a gate for new features going into production. Typically, the department would have a very long list of standard user actions and business requirements that would be retried upon any change to the code base. This was an effective way of mitigating feature regression and catching any missed business requirements.
More modern approaches to QA took these business requirements lists and allowed computers to do what they do best: execute a sequence of tasks. The introduction of automated testing allowed these QA teams to move from manual testing to writing automated test suites.
The most recent approach to QA has seen a lot of companies opt out of a QA department altogether (Shopify, Facebook, Spotify) and focus on automation engineers. Automation engineers are standard developers within a project squad. They can perform regular development tasks, help with planning, and ultimately understand the business and technical requirements of a project. The advantage of these automation engineers is that they can write automated test suites as part of each project.
At Humi, we rely heavily on test automation, specifically in the area of E2E testing. Although each individual application is tested at a unit, functional, and integration level, testing multiple applications together provides us a level of confidence in our changes we previously never had. Ensuring each application does not break contract with other applications, and ensuring critical workflows remain functional to the user, allows us to ship faster and ship often.
Cypress uses a syntax similar to document.querySelectorAll(), allowing the ability to find nested elements within your DOM structure.
Cypress provides the most common element interactions you may want to perform including clicking and typing to drag and drop, and file upload support.
Cypress also solves the "wait until something happens" problem in many E2E testing frameworks by leveraging blocking assertions.
The above code will look for a <button> element in our .container element and continue to wait until that specific element exists in the DOM (asserting it exists as part of our test).
One of the primary advantages of cypress is its ability to orchestrate running many tests in parallel. By providing the Cypress test runner with multiple instances/resources to run on, using our github actions, we can distribute our E2E tests in the quickest way possible. Cypress will continue sending un-run tests to available resources until all test have completed.
Cypress also allows us to review and debug test results in their dashboard. We have configured Cypress to capture videos of all failing tests and report failures directly to our pull requests during the review process. We can use their analytics to identify flakey tests, common points of failure, and monitor the size and speed of our tests suite.
At the end of the day, Cypress ensures the level of quality that the engineering team is known for remains high. End-to-end testing ensures that we do not introduce any feature regression, across a very large product with many moving parts. Matching end-to-end tests with user stories as part of our project process helps team members validate functionality, and gives us peace of mind that our happy paths remain intact for our end user.