Breaking things on purpose: A guide for efficient end-to-end QA Testing

By Delia Stanescu, QA Lead, and Rares Petric, QC Engineer, Cognizant Softvision

Have you ever run into issues when testing out your shiny new digital product? From errors visualizing content to buttons that don’t click, and even full-on crashes, there’s lots that can go wrong in testing. And unless you have experience in QA testing, there’s a good chance that when you do identify an error, that’s only the beginning of the journey to identify and fix it.

In this article, we will show you some of the most common potential sources for the issues you may encounter when testing. We’ll show you what measures we take as QA engineers to identify bugs, and what it takes to solve issues on both the front and backend.

What is frontend testing?

The “frontend” refers to any part of a software application that a user directly interacts with: think of a website you like to visit. The frontend is the part you see: content, images, menus, buttons, forms, and more.

Frontend testing is the technique through which we validate Graphical User Interface (GUI) functionality and usability. The objective of frontend testing is to check the user interface against designs with the purpose of ensuring the end product online meets UI specifications.

For example, QA testers always check whether input fields accept the right characters, that forms can only be submitted after the required fields are filled, that navigation tools work seamlessly, that pages load quickly, and so on.

What is backend testing?

The “backend,” in contrast to the public-facing front, refers to any part of a software application that the user interacts with indirectly: the parts they need, but never see. This includes the functions that translate and then pass data from a browser to database (XML or JSON), or that connect directly with a database (SQL) using queries.

Backend testing is the technique through which we validate service functionality. The purpose of backend testing is to ensure services that power the user interface are working properly and interacting well with each other. In order to perform backend testing, we do not require any GUI (Graphical User Interface).

Backend testing consists mainly of API testing and Database testing, but in this article we will be focusing on API Testing.

API testing is the technique that allows QA to verify if an Application Program Interface (API) meets expectations for functionality, performance, security and reliability. API testing requires making API calls, receiving output, and verifying that the input parameters in the response (HTTP status codes, data correctness, data format, error codes) are all correct.

Differences between frontend testing and backend (API) testing

Frontend testing validates the HTML, JS, CSS, images, and user experience whereas API testing validates the logic, functionality, and reliability of the programming interface.

Frontend testing:

• Validates whether the application is looking & working according to the designs & requirements.
• Analyzes the overall capabilities of the application.
• The understanding of requirements is necessary in order to execute the frontend testing.
• Knowledge about GUI & Functional testing is required

Backend API testing:

• Validates whether the application functionalities are working properly with different kinds of inputs.
• Analyzes the potential data corruption or data loss.
• The understanding of the API calls is essential to execute the API backend testing.
• Knowledge about API testing is required

Frontend & backend testing in real life

If you work in an agile environment, you’ll want to start testing as soon as possible in the development lifecycle. Often, this means testing the backend before the frontend is ready, or the frontend prior to launching backend services. But agile testers can perform key tests independently:

• When only the backend is ready, QA can perform API testing
• When only the frontend is ready, QA can perform GUI testing using mock data
• When both frontend and backend are ready, QA can test the integration between them

Backend availability (API)

When only the backend is ready for an upcoming feature launch:

• You will need to know what kind of requests the APIs can make, and also their limitations. This information can be found in the API documentation that is usually provided by the developer in a Swagger (a suite of tools that allows anyone to visualize and interact with the API resources without having any of the implementation logic in place, making it easy for backend implementation and client-side consumption).
• The Swagger should contain information about (and not limited to):
  — Available endpoints
  — Required fields
  — Responses codes for Passed/Failed requests
  — Error messages that come with failed requests
• Consider negative flows as well, such as empty values for required parameters and invalid input for fields / body

A good reason to start testing the backend using the APIs as soon as it’s available is to identify potential bugs in the code at a very early stage, allowing the development team to fix them in advance. By validating that APIs are working well, the risk of problems when integrated with the frontend is significantly reduced.

Frontend availability (GUI)

When only the frontend is ready for review and testing, you should use the time to validate the visual part of the website; verifying screens and controls like buttons, images, icons, menus, error messages, fonts, and text alignment of text. Most commonly, QA testers will refer back to designs and annotations that showcase how the feature should look in different states.

A common problem at this point in the development process is that GUI changes are quite common when designs are put into production. For this reason, it’s important that all GUI changes are well documented, so that QA can verify and identify whether a change in the application is a bug or an enhancement.

One of the reasons why GUI testing is imperative is that it allows QA to verify a feature from a user’s point of view. This is important because a user only has access to the frontend interface of the application. Thus, as QAs, we need to think and behave as real users in order to understand the implications of the look, feel and design of the application. Ensuring the application is easy to understand will determine whether a user will use it more frequently.

A good reason to start testing the user interface as soon as it’s available is to identify potential frontend issues in advance and allow the development team to fix them before the integration with backend.

Backend and frontend availability (E2E)

As soon as both the frontend and backend parts are ready, you should test “end-to-end” integration. E2E testing allows the QA to verify and make sure the application behaves as expected simulating a real-world scenario. For example, on a booking platform that requires entering the customer’s name, phone number, and email address in order to finalize the reservation, you can expect a user to perform one or more of these actions:

• Enter a blank name, phone number, and email address
• Enter a valid name, phone number, and email address
• Enter an invalid name, phone number, and email address

Using end-to-end testing you can validate that all these actions work as a user might expect.

End-to-end testing is important because it:

• Ensures the whole application works correctly
• Increases test coverage
• Catches issues before releasing the application to end users
• Offloads testing to the QA team, allowing devs to work on adding new features

Besides the benefits, end-to-end testing also comes with big challenges. For example, the QA team will always require knowledge of the systems and any interconnected subsystems. It is time-consuming and difficult to design test cases that simulate a real-world behavior, especially for large user bases accessing complex software products with many potential user paths.

But with the right testing team working on production-ready E2E agile environments, qualified QA teams can identify most potential issues early in the development lifecycle, and ensure that new features work perfectly before an end user ever logs in to discover them.