This modern end-to-end testing framework simplifies the creation of automated tests for web applications. Unlike other tools, Cypress is designed specifically for modern web environments, providing a faster, more reliable, and user-friendly testing experience.

Explore the key advantages of Cypress and how it can enhance your software testing workflow.

What is Cypress?

Cypress is a testing tool designed to streamline the process of writing, running, and debugging tests. It enables developers to write tests in JavaScript, leveraging an intuitive API that facilitates software development.

Additionally, it offers an interactive interface that enables real-time test visualization, enhancing the overall testing process. This feature enables QA analysts to track test scripts as they run, facilitating the identification of areas requiring adjustments.

Why use Cypress?

Choosing the appropriate tool for automated testing is essential for enhancing speed and operational efficiency. Cypress is a leading option for several reasons:

• Simple installation & Easy learning curve: even novice developers can swiftly initiate test development.
• Fast execution: it runs directly in the browser environment, eliminating unnecessary delays.
• Interactive interface: it facilitates debugging by allowing developers to view and fix issues in real-time.
• User interaction simulation: ensures the proper functioning of all application components.

It also boasts a strong community and comprehensive documentation. It provides extensive resources and support for developers and QA professionals.

What language does Cypress use?

Cypress utilizes JavaScript for test development, ensuring seamless compatibility with contemporary web applications. Given the prevalence of JavaScript in the development of front-end applications, Cypress enables developers to utilize the same language for both development and testing, thereby streamlining the workflow.

Cypress vs. Selenium: key differences

The primary distinction between Cypress and Selenium lies in their architecture:

• Cypress operates directly within the browser, providing a faster, more integrated experience.
• Selenium is a conventional testing framework that interacts with the browser via APIs and supports multiple programming languages.

While Selenium boasts greater flexibility in terms of browser and language compatibility (Java, C#, Python, Ruby), Cypress excels in speed, ease of use, and debugging efficiency with its JavaScript-based API and real-time feedback.

Types of tests you can perform with Cypress

Cypress facilitates a range of software tests to ensure seamless functionality, including:

1. Integration testing
2. UI testing
3. Performance testing
4. Regression testing
5. Accessibility testing
6. Security testing

1. Integration testing

Integration testing checks that the different parts of the application work together. For example, Cypress can be used to test communication between the database layer and the user interface layer.

2. User Interface testing

Cypress is used to test the user interface and ensure that users can interact with the application without navigation problems.

3. Performance testing

Cypress is useful for testing application performance and identifying bottlenecks that can affect the user experience, such as loading speed.

4. Regression testing

Try using Cypress to check that planned new features won’t negatively impact existing features.

5. Accessibility testing

You can also test the application to ensure that it complies with web accessibility guidelines.

6. Security tests

Cypress also helps identify vulnerabilities that can be exploited by hackers.

Technologies compatible with Cypress

Cypress seamlessly integrates with several technologies and frameworks, including:

• Node.js: this allows developers to use JavaScript for both application logic and testing.
• Testing Frameworks: Cypress supports Mocha, Jasmine, and Jest for test structuring.
• Build Automation Tools: Cypress can be used with Grunt and Gulp to streamline build and test execution.
• CI/CD Tools: Jenkins, Travis CI, and CircleCI facilitate automated test execution and deployment.

By integrating Cypress within a CI/CD pipeline, test execution can be automated on the occurrence of code changes, thereby ensuring continuous quality assurance.

How to install and use Cypress for automated testing

Want to see how Cypress works in practice? Check out our step-by-step installation and configuration guide!

Installing Cypress

To install Cypress in your development environment using npm (Node.js package manager), run the following command:

Configuring Cypress

Now you need to configure it for use in your automated tests. To do this, you need to create a configuration file in your project, and simply run the following command in your terminal.

This will cause Cypress to open in your browser and create the cypress.json file in the project – this file is responsible for storing the Cypress settings.

Next you need to define the URL of your web application in baseUrl within the cypress.json file. For example:

This defines the base URL for your web application at http://localhost:3000.

Best practices for Cypress project structure

To maintain an efficient testing workflow, follow these best practices:

• Tests folder: organize test files by application functionality for easy navigation.
• Fixtures folder: store reusable test data files in JSON format.
• Plugins folder: extend Cypress functionality by managing plugins in a separate directory.
• Support folder: maintain shared configuration files and helper functions.
• Environment variables: store sensitive information (e.g., credentials, API keys) securely using environment variables instead of hardcoding them.

Use of environment variables

Using environment variables is a good way to keep your credentials and sensitive information out of the source code. Use environment variables to store information such as URLs, login credentials and other sensitive information.

You may have noticed that the most important thing is to keep your files organised in a way that makes sense to your development team and makes it easier to maintain tests over time.

To use Cypress correctly, there are a few aspects of its structure you need to remember, such as:

• The test files are usually in the integration folder;
• The js file is in the support folder – this is the file that stores the path to your screen element, e.g. locators.js;
• The commands file is used to create commands for your project;
• The fixture folder contains the .json files used in the tests.

In the example below we have the following folders and additional files:

Essential Cypress commands

Learn about some of the main Cypress commands that will make the framework easier to use:

To find elements on screen:

• GET: cy.get(‘[data-cy=name]’)
• CONTAINS: cy.contains(“Register”)

To interact with screen elements:

• Type: used for typing. Example: cy.get(‘[data-cy=name]’).type(“Joaozinho”);
• Click: used to click on the selected element, such as cy.get(locators.CADASTRO.btnCadastrar).click();
• Select: used to select an element. Example: cy.get(Loc.CADASTRO.campoUF).select(“RS”);
• Check/Uncheck: used to apply the check – cy.get(‘[type=“checkbox”]’).check().

Assertions for our tests:

• Should: cy.get(locators.MENU.nameLoggedUser).should(“contain.text”, “Joaozinho”);
• Expect: expect(response.body).has.property(“id”).

Front-end test example

Let’s look at two test cases: the first checks whether an error message is displayed if the user’s credentials are incorrect. The second checks whether the user is redirected to the dashboard if the credentials are correct.

To do this, before each test we use the cy.visit() command to visit the login page. Next, we use cy.get() and .type() to fill in the email and password fields, and cy.get() and .click() to click on the login button. Finally, the cy.url() command is responsible for checking that the user is redirected to the correct page after logging in. It’s worth noting that the tests can be adapted to the specific needs of your application.

Optimizing testing with locators

You can use a JSON file to store CSS selectors, which is particularly useful for large projects where there are many locators to manage, as it allows for easier organisation and maintenance.

Below is an example of how to create a JSON file with locators and use it with Cypress:

In the example above, we have a locators.json file that contains the locators organised by page. To use these locators in the test, simply import the JSON file and use the cy.get(nameOfLocator) syntax to locate the element on the page.

Using a JSON file to store the locators simplifies code maintenance by allowing the locators to be updated centrally in a single file.

Back-end test example

Below is an example where we use the cypress-axios plugin to make HTTP requests to the API. We also use the cypress-aliases plugin to create an alias to the base API URL that can be referenced by @api in the tests.

In the first test, we’ll check that the API responds correctly by making a GET request to the API’s base URL.

In the second test, we’ll check that the API returns the expected response. We’ll do this by making a GET request to the API’s /hello route.

And the third test is to check that the API returns valid XML by making a GET request to the API’s /xml route and validating the XML returned.

It’s important to remember that back-end testing with Cypress is more limited than front-end testing because there is no user interaction with the application.

However, it is still possible to check the API response and validate the expected behaviour of the application. See the figure below:

Here’s an example of a request file:

See an example of a payload file:

Functional test example

Below is an example of a functional test in Cypress. In the first block, we perform the interactions of a registration; in the second, we click on the registration button which calls the post method; in the last, the test validations.

Conclusion

Cypress is a powerful end-to-end testing tool with an intuitive JavaScript API, easy installation, interactive debugging and strong community support. Its fast execution and integrated browser experience make it an excellent choice for modern web applications.

Looking for expert guidance? Meet our nearshore development teams and improve your software testing strategy and effectively mitigate risk.

Frequently asked questions

Here are the answers to the main questions about Cypress:

O post Cypress: step-by-step guide to getting started apareceu primeiro em SoftDesign.

In the first article in this series, we explored the profiles, roles, and expertise needed by a product team. In the second, we addressed the importance of Product Owners (POs), followed by content that explored the role of Designers. In the last article published on our blog, we talked about Software Engineers.

Is there a difference between a Quality Assurance Engineer and a Test Analyst?

A few years ago, the professional known as Test Analyst worked focused on the quality of the software product. Currently, this person is expected to act more broadly, as a Quality Assurance Engineer, validating not only the product’s quality but also its entire creation process.

In short, the Quality Assurance Engineer focuses on ensuring that the product has the best possible quality, participating from the discovery to the delivery of digital solutions. In the book Software Quality: The Framework for Success in Software Development, Sanders (1994) emphasizes, “a software product has quality depending on the degree of satisfaction of customer needs in all aspects of the product”. For this, the professional analyzes the creation cycle and the way of working of the squads that participate in the development.

According to Douglas Souza, QA at SoftDesign, this more global view helps to maximize results, as it is possible to find errors at the beginning of the process: “If this professional did not exist, the errors could remain uncorrected until the product is delivered. This avoids wasting time and money.”

What Does a Quality Software Engineer Really Do?

As we have already mentioned, the Quality Software Engineer person has the role of analyzing the entire development cycle of a digital product. This professional is able to guarantee the correct functioning of the programs and review the prerequisites of the software, reporting faults to the development team. To achieve this, the QA uses functional and non-functional tests, carried out through Manual and Automated Testing techniques. It also helps in the creation of strategies, test plans, and assessment of results.

According to Raphael Rodrigues, Agilist at SoftDesign, while in the software factory model, the objective is to find faults to report to the customer, in the agile model it is to build a product and generate knowledge, thinking, and validate hypotheses throughout the process. “That’s why it’s important to understand what is considered value for the customer and the user. Sometimes what appears to be a problem can turn into an opportunity. There is no such thing as a perfect product; after all, we are talking about something that is under permanent construction. Therefore, a more critical look is essential”.

Moreover, the Quality Software Engineer thinks through scenarios that could critically affect the product. This person is responsible for anticipating possible usability problems and system behaviors that could lead to faults, such as the incorrect use of a screen element. Therefore, its role is also to work on reducing possible critical errors. Remember that adversities will always exist; however, they cannot be serious enough to compromise the operation of the application.

Manual Vs. Automated Testing

As the construction of digital products happens faster, the feedback of hypotheses and experimentation also needs to reach a faster pace. In this sense, Automated Testing has become essential to be able to perform all the necessary tasks.

Rodrigues emphasizes that Automated Testing serves to accelerate the feedback of what was built, that is, it verifies the existence of possible problems and impacts. In Manual Testing, the full attention of the person conducting this verification process is required. “After the QA does the manual work, he is expected to automate what is considered repetitive or critical in order to find out more quickly if the application is still working or not”.

Manual and Automated Testing is generally performed by the same person. However, in some cases, this can be a challenge, since programming knowledge becomes necessary. “To work with Automated Testing it is necessary to deal with code. Therefore, considering the volume of work and the need for quick feedback, I believe that Manual and Automated Testing should complement one another throughout the development journey”, the Agilist explains.

Continuous Delivery

With the agile methodology, we seek to develop and deliver new features and products quickly, efficiently, and with quality. To achieve this, the squads are constantly looking for ways to improve the product, in order to maximize the value of deliveries to the customer in relation to the development time. One approach used to achieve these goals is CI/CD, where knowledge of Automated Testing is crucial.

According to Matheus Zanon Nunes, QA at SoftDesign, in a team that applies Continuous Integration (CI) and Continuous Delivery (CD), it is necessary to present new features to the customer quickly. “Automated Testing is critical for us to fulfill this flow, as it is not possible to automate continuous deliveries if the testing stage is manual and slow. Therefore, in order to make CD viable, we applied the previous stage, which is CI. CI is responsible for integrating and monitoring all changes to the software, as well as triggering automated routines to verify the quality and stability of this new code. That’s where Automated Testing comes in as a prerequisite stage for the execution of CD”.

Therefore, Automated Testing, in its various categories (Unit, Integration, End-to-End, Performance, etc.) has become a crucial stage to ensure that before, during, and after Software Development all requirements are met with quality and focus on delivery.

How does the Quality Assurance Engineer Interact with the Product Team?

The Quality Assurance Engineer interaction with the product team must occur from the initial planning of the construction of the solution because, during the refinement of the functionalities, it is very important to understand its objective. This will help the professional define what types and levels of tests will be required. In addition, that person can also contribute with suggestions for the application’s capabilities.

The main skills of a Quality Assurance Engineer that contribute to the success of the product are critical thinking and a detail-oriented vision, which enable the early identification of different scenarios according to the business context. This considerably reduces the number of faults in the software, also allowing the types of tests to be identified.

Most common and necessary types of tests:

• Functional, which aims to ensure that the developed features correspond to the business specifications made by the Product Owner;
• Usability Testing, which aims to validate user journeys and screens defined by the Designer;
• Regression Testing, which ensures that previously implemented features remain intact after new implementations.

Depending on the application needs, Integration, Load, Performance, and Security testing can also be performed. For Denise Viegas, interactions with POs and Designers are critical when creating functionality and user journeys. “In addition, the partnership between the Developer and the Quality Assurance Engineer is also essential during the specification stage, especially during the delivery cycle. This collaboration is decisive in the delivery of product quality, as it is where all ideas and definitions come to fruition”, she highlights.

Trends for the coming years

The Quality Assurance Engineer role is constantly changing. Currently, this person works between the business area and product development, so in addition to interpersonal skills, this person also needs developing knowledge.

With the Quality Assurance Engineer participating from the beginning of the process and being involved with Software Engineers and Product Owners in defining the solution, this professional can contribute by mapping test scenarios to be used by developers. In addition, the QA can indicate tools for certain types of tests in a simulation environment, among other possibilities.

For Denise, former QA at SoftDesign, the trend is that these professionals will increasingly acquire technical skills, aiming at more automated testing flows in continuous integration environments. “This allows for more agility in the early identification of faults, as well as greater ability when evaluating the feasibility of the technical solutions implemented”, she emphasizes.

QA at SoftDesign

From the moment we started to look more at people’s knowledge, their roles naturally evolved in order to consolidate critical thinking. With Agile Methods, we no longer have a person focused only on the quality of the software to expand this view to the entire process, and it is through this holistic view that SoftDesign Testers work in product teams.

If you need help developing quality digital solutions, please contact us using the form below. Together, we will seek differentiation by launching products that make good first impressions when they reach the end-user.

O post The Quality Assurance Engineer Role In The Product Team apareceu primeiro em SoftDesign.