Evaluating Automated Testing on an Open-Source Web Application Using Cypress

Evaluating Automated Testing on an Open-Source Web Application Using Cypress Quoc-Binh Nguyen Faculty of Information Technology Ton Duc Thang University Ho Chi Minh City, Viet Nam nguyenquocbinh@tdtu.edu.vn Ngoc Hong Tran Computer Science Program Vietnamese-German University Ho Chi Minh City, Viet Nam ngoc.th@vgu.edu.vn

Abstract—End-to-end automated testing is increasingly used in web software development to ensure system quality and shorten response times during development. However, the true effectiveness of automated testing depends on many factors including execution time, stability of test results, and maintainability of the test suite as the application continues to evolve. In this paper, we evaluate the effectiveness of end-to-end automated testing using the Cypress framework for an opensource web application. We deployed the experiment with 27 test cases. The test’s effectiveness is measured by execution speed, reliability, and maintainability. The experimental results show that the Cypress-based end-to-end test suite has short and stable execution times. It suits frequent runs during software development. The majority of test cases achieved consistent results across multiple runs, while flakiness only occurred in a few tests which involve complex interactive functions. Furthermore, the study highlights the impact of element locator strategies and Page Object Model (POM) architecture on test suite maintainability, demonstrating that resilient data-cy attributes significantly reduce maintenance overhead when UI changes occur. Keywords—automated testing, end-to-end testing, cypress, software test

I.

INTRODUCTION

In the modern digital era, the software quality is not an option but an essential part for both business corporations and economic stability. However, maintaining this quality faces unprecedented challenges in terms of expense and technique. Research from the National Institute of Standards and Technology (NIST) pointed out that inadequate infrastructure of software testing caused damage to the US economy at approximately 59.5 billion dollars annually [1]. This number has reached trillions of dollars due to the increasing complexity of software. The fundamental reason is the “error cost curve”. If an error is identified during the operating period, it can cost up to 100 times more than if it were detected early on [2]. The transition to accelerated development frameworks such as Agile [3] and DevOps [4] has exerted significant strain on the quality assurance (QA) process. Manual testing has become a constraint due to its inability to keep pace with the constant deployment of new features [5]. In open-source contexts, the contributions are made by volunteers without a dedicated QA department, so the absence of an efficient automated testing mechanism frequently results in a deterioration of software quality over time [6].

Truc-Ly Phan Nguyen Computer Science Program Vietnamese-German University Ho Chi Minh City, Viet Nam 18715@student.vgu.edu.vn Dung Hai Dinh* Business Information System Program Vietnamese-German University Ho Chi Minh City, Viet Nam *Corresponding author: dung.dh@vgu.edu.vn

Under above motivation, in this paper, we evaluated the effectiveness of Cypress through a case study on an opensource web application. The goal is to examine whether this tool can realistically address the long-standing trade-off between development speed and software reliability. Although automated testing is often presented as a practical solution, its actual benefits remain uncertain in many realworld projects. In practice, automated test suites are frequently affected by issues such as flakiness and high maintenance overhead, especially when user interface (UI) changes occur [19]. These challenges can reduce their reliability and limit their usefulness over time. To investigate this further, we apply Cypress to the open-source real world project and conduct an empirical evaluation of its performance. Beyond replacing manual testing efforts, this work explicitly evaluates how different element locating strategies (traditional vs. data-cy attributes) combined with a Page Object Model (POM) architecture impact the long-term maintainability of the test suite. This paper is organized into 6 sections. The problem statement and contribution are presented in Section I. The fundamental software testing is presented in Section II. Section III presents the automated testing. The experimentation is stated in Section IV, and the result findings are described in Section V. Eventually, the conclusion and future works are presented in Section VI. II.

SOFTWARE TESTING

Software testing has been an activity intertwined with the history and development of the digital computing industry. It is considered an essential method for evaluating and determining the quality of a software system before it goes into operation. In reality, testing activities typically account for 40% to 50% of total project development resources, and this figure increases for systems requiring high stability and reliability [7]. According to E. Dustin et al. [8], investing significant resources in testing is a strategic necessity to control risk and ensure product sustainability throughout its development cycle. Software testing contains a series of activities, which is called the Software Testing Life Cycle (STLC) presented in Fig. 1. A. A typical STLC process Including 6 following stages:

9th International Conference on Research in Engineering and Technology (RET 2026)

1

Nguyen et al.

Evaluating Automated Testing on an Open-Source Web Application Using Cypress

1) Requirement analysis: The testing team studies the requirements documents to identify testable features and nonfunctional requirements. 2) Test Planning: This is the most important stage, determining the testing strategy, selecting tools (such as Cypress), and estimating resources and risks. 3) Test Case Development: Engineers create detailed test scenarios, test data, and automation scripts. 4) Test Environment Setup: Hardware, software, and network conditions are prepared to ensure the test environment closely resembles the user's real-world environment.

can be a significant drawback when unforeseen circumstances and changes arise during the project [10]. 2) Agile. emerges as an ideal solution to the limitations of Waterfall, emphasizing flexibility and collaboration in order to meet client expectations and adapt to changing market circumstances [10] (see Fig. 3). In this model, testing is no longer a phase but a continuous activity throughout the development lifecycle [11]. By breaking the development down to short iterations, Agile encourages constant feedback loops, allowing teams to discover and address issues early on, hence lowering the expense and effort needed to address problems later in the lifecycle [10]. Moreover, since testing tasks appear in every sprint, automated testing becomes an ultimate solution against regression. III. AUTOMATED TESTING While manual testing relies on human observation and interactions, Automated testing is the technique of controlling test execution and comparing actual results with expected results using software that is distinct from the software being tested [8]. There are three levels of automated testing (see Fig. 4). At the bottom, unit test concentrates on testing a singular

Fig. 1. Software Development Life Cycle

5) Test Execution: Tests are run, and bugs are recorded for the development team to fix. In the CI/CD model, this phase is often fully automated to provide rapid feedback. 6) Test Cycle Closure: The team summarizes the results, reports on test coverage, and draws lessons learned to improve the process for the future. A well-structured implementation of STLC closely connects testing activities with the overall Software Development Cycle (SDLC). As a result, the software delivery process gets more stable and less risky. B. Testing in Modern Software Development 1) Waterfall. is the most well-known and traditional method of developing software, in which the software processes are separated into different phases, and each phase follows each other in an irreversible straight line [9]. In this model (see Fig. 2), the testing phase is placed at the end of

Fig. 2. Waterfall model

the development lifecycle as the terminal gatekeeper. However, this model contains a systematic flaw in terms of risk management. Since the approach is sequential, each phase in the model is “signed off”, meaning the next phase can only be started after the previous one is completed. This

Fig. 3. Agile Methodology

Fig. 4. Testing pyramid [12]

component in the application, such as separated methods and code functions, thus it provides specific data and errors with high precision. At the middle level, service test checks the interactions between components and makes sure they work together without any problems. At the top of the pyramid, End-to-End test (E2E) simulates the end-user experience across the whole application. It ensures that different layers of the system, from frontend to backend, database, and integrations, work as intended. E2E can be performed both manually and automatically. In addition, automated testing plays a strategic role as a pillar in the quality assurance process, especially for projects operating under Agile and DevOps models. Test automation is a great candidate for regression testing. “Any tedious or repetitive task involved in developing software is a candidate for automation” [13]. As the application gets bigger after every short iteration, the time of the test also grows longer, sometimes exponentially depending on the application under test (AUT). Furthermore, automated testing is an integral component of Continuous Integration and Continuous Delivery (CI/CD) [14]. Integrating tests into the deployment pipeline provides fast feedback, allowing the team to detect and address errors as soon as they arise. Running a full test suite automatically saves the team a lot of time, produces more accurate results, and frees people from exhausting tasks [13]. A. Cypress framework Cypress is a Javascript based testing framework introduced in 2015 by Cypress.io under the MIT license [15]. Designed specifically as a frontend testing tool for modern web

9th International Conference on Research in Engineering and Technology (RET 2026)

2

Nguyen et al.

Evaluating Automated Testing on an Open-Source Web Application Using Cypress

applications, Cypress provides solutions for E2E testing, component testing, UI testing, and many more. Cypress products include Cypress app, an open-source app for writing and running tests locally, Cypress Cloud which is a paid service for recording test results and providing test analytics, Cypress Accessibility as a premium solution for accessibility checks, and UI Coverage for visual overview of test coverage across web pages and components. B. Cypress vs Selenium While traditional testing tools like Selenium rely on communication between Web driver protocol and Document Object Model (DOM) across HTTP request, Cypress works directly within the browser environment by utilizes a universal driver that is compatible with modern web browsers like Firefox, Edge, Chrome and other Chromium browsers [16]. By operating test inside browser runtime, Cypress allows users to interact with application under test in real time.

includes Node.js v22.14.0, Electron 138 (headless) browser, Cypress version 15.8.2 test framework, Conduit RealWorld open-source web application under test, and Headless browser execution mode. Before each execution, the application state and test data were reset to a known baseline to ensure consistency. B. Data Processing Pipeline In this paper, we adopt an empirical, evaluation-oriented case- study process to assess the effectiveness of automated E2E testing using Cypress. Case study is “an empirical method aimed at investigating contemporary phenomena in their context” [17]. A case study research method is selected because the phenomenon under investigation (the E2E automated testing) is tightly coupled with the context in which it is applied. In real-world software system, test automation behaviour cannot be isolated from user workflows, application structures and executed environment. The aim of this work is to evaluate the performance of an existing automation solution within a realistic software development context. The process is demonstrated in Fig. 6.

Fig. 6. Data Process Pipeline

Fig. 5. Comparison between Selenium and Cypress Framework

The first step is to plan the case study objectives of what are expected to be achieved in the case study, build research questions, and choose metrics. After that, procedures and protocols for data collection are defined. The third step includes executing the test and collecting data, then the data is analyzed in step 5. The final step is reporting the result and writing conclusion. All data are recorded in Google Sheet.

This architecture also allows Cypress to reduce timing issue, which often arise in traditional testing tool because the commands must travel through multiple layers. This architecture also has an inherent advantage because it incorporates automatic waiting methods that synchronize test execution with application events, including network requests or DOM updates. On the other hand, in order to handle asynchronous action, Selenium-based tests frequently call for explicit or implicit waits. Additionally, using a universal driver guarantees that tests run consistently in various browsers. Regardless of the browser in which they are run, Cypress test cases adhere to a consistent format and behavior. By using the same test suite on newly supported browsers, QA engineers and developers can increase cross browser testing efforts without having to make major modifications to the current tests. The below figure shows the difference in architecture between Selenium and Cypress. While test execution takes place outside the browser in Selenium, Cypress test is executed inside the browser [16]. Although Cypress supports only test development in JavaScript and Typescript, which limits the language flexibility compared to Selenium, it aligns well with contemporary frontend development techniques.

Fig. 7. Homepage of Conduit RealWorld

IV. EXPERIMENTATION A. Set-up Environment We deploy the experiment using a local machine equipped with Intel Core i7 processor and 8GB RAM, running the Windows operating system. The software environment 9th International Conference on Research in Engineering and Technology (RET 2026)

3

Nguyen et al.

Evaluating Automated Testing on an Open-Source Web Application Using Cypress

C. Web application The case study is conducted on Conduit RealWorld, which is a medium-sized social blogging platform (i.e. a Medium.com clone) designed to demonstrate typical

personal information. This open-source web application is selected due to being a full-stack application with relatively complex UI and workflows, providing an excellent environment for E2E testing research. D. Test cases The E2E test suite consists of 27 test cases covering the core functional workflows of the Conduit platform. These cases are distributed across six main features: Authentication (Sign up/Sign in), Article CRUD operations, Favorite/Unfavorite articles, Follow/Unfollow authors, Comment management (Create/Read/Delete), and User Settings update. The list of 27 test cases is described in Appendix A. E. Evaluation metrics There are 3 requirements for performance measurement when we run the experiments. That is,

Fig. 8. Article detail page

architecture and functional patterns in modern web applications. The list of general features include:       

Authenticate users via JWT User state and session CRUD Articles CR-D Comments on articles List of articles pagination Favorite articles Follow other users

RQ1. To what extent does Cypress-based end-to-end automated testing achieve execution velocity that supports iterative development in an open-source web application? For RQ1, we use formulas 1 and 2 to reason for execution velocity. 1) Average Execution Time: is average value of the total test run time across n executions. This index helps eliminate random variables and establish a stable representative number for each method. 𝑇=

∑

(

,

, )

(1)

Where (tend,i - tstart,i)is the execution time of the ith run, n is the total number of experimental runs. 2) Time reduction percentage. measures the effectiveness of automated testing compared to manual testing, expressed as the percentage of time saved per iteration. ∆𝑇 =

× 100%

(2)

where 𝑇 is average execution time of manual testing, 𝑇 is average execution time of automated testing. Fig. 9. Article editor page

Fig. 7 displays the main Homepage of the application with User Feed and Global Feed of articles. Fig. 8 displays a typical article detail page where user can view article content and perform comment action. Fig. 9 displays the article edit page where users can create a new article or edit their article. Fig. 10 displays the user settings where users can edit their

RQ2. How reliable and stable is Cypress-based automated testing across repeated executions, particularly in terms of test flakiness and false failure rates? For RQ2, we use formula 3 to reason the reliability. 3) Flakiness frequency. measures the frequency of discrete test failures that are not caused by changes in the application under test. A test case is considered flaky if it passes in one execution and then fails in another execution under the same condition. 𝐹 = × 100% (3) RQ3. How does the use of best practice element locating strategies affect the maintainability of Cypress test suites when the application interface changes? For RQ3, we use formula 4 to infer the maintainability. 4) Time to repair. is the time required to restore a failing automated test suite to a passing state after an application change. The time is measured using wall-clock time, starting from the moment a test failure is first observed after an

Fig. 10. Settings page

9th International Conference on Research in Engineering and Technology (RET 2026)

4

Nguyen et al.

Evaluating Automated Testing on an Open-Source Web Application Using Cypress

application change, until the test suite passes again after the necessary test code modifications. 𝐸=𝑇 −𝑇 (4) In addition, to evaluate execution time and stability metrics in RQ1 and RQ2, the test suite is executed repeatedly 20 times under the same condition. This repetition is designed to account for environmental variability and to identify flakiness. By executing 20 times, our work can calculate a stable mean execution time and observe the consistency of the pass rate. Therefore, the results are not influenced by isolated performance spikes or temporary system latencies. Manual testing for RQ1 is executed 3 times to mitigate potential measurement outliers (such as manual stopwatch delays or minor human distractions) while avoiding the confounding effects of human fatigue which would arise from excessive repetition. Application state is reset to a known baseline before each execution, the full Cypress suite is executed headlessly in the terminal, and the result of each execution is recorded automatically by the Cypress test runner. Total execution time, pass/fail status and individual outcomes of each test are recorded.

368𝑠 − 88𝑠 × 100% ≈ 76.08% 368𝑠 When comparing Cypress's test time (averaging 1 minute 28 seconds) to manual execution time (6 minutes 8 seconds), we can see a reduction in execution time of approximately 76.08%. The results indicate clearly the implementation of automation testing has made a great impact on the testing effort. In a workday where programmers are constantly updating code, and product is deployed in short development cycles, it makes a huge difference in workflows. With manual testing, we cannot afford to retest 27 different scenarios every time when a line of code is changed. Instead, we often have to wait for many changes to be accumulated before we test them all at once. This method inadvertently leads to error accumulation and makes it harder to find the root cause. However, with Cypress's speed, running tests after each commit becomes feasible and helps us enter the domain of continuous deployment in Agile’s short cycle. Furthermore, when we do manual testing, the first testing might be very fast, but after that, the fatigue will reduce speed and accuracy. Therefore, using Cypress is not just about being faster but ∆𝑇 =

V. RESULT FINDINGS A. Evaluating the Execution Speed for Iterative Development (RQ1) To answer the question of the iterative development capabilities of automated test suites, our work recorded the execution time of 27 E2E scenarios on the Cypress platform over 20 consecutive runs and compared it to the standard manual execution time. The results are presented in Table I. Experimental results showed that the completion time of the automated test suite fluctuated steadily between 1 minute 20 seconds and 1 minute 39 seconds, with an average value of 1 minute 28 seconds (88 seconds). Meanwhile, the average time for manually executing the same scenario was 6 minutes 8 seconds (368 seconds) (see Table II). According to the formula, the execution time reduction rate is

TABLE I. RESULTS OF 20 EXECUTIVE RUNS OF 27 TEST CASES Execut ion ID

Passing rate

[E-1] [E-2] [E-3] [E-4] [E-5] [E-6] [E-7] [E-8] [E-9] [E-10] [E-11] [E-12] [E-13] [E-14] [E-15] [E-16] [E-17] [E-18] [E-19] [E-20]

97% 100% 100% 97% 100% 93% 100% 97% 93% 93% 97% 100% 100% 97% 97% 93% 97% 93% 97% 97%

Time of execution (min) 1:20 1:24 1:27 1:29 1:35 1:28 1:26 1:23 1:30 1:34 1:39 1:28 1:27 1:23 1:25 1:25 1:31 1:38 1:29 1:26

Case failure ID #17 #18 #17, #18 #17 #17, #18 #17, #18 #18 #17 #17 #17, #18 #17 #17, #18 #18 #18

Fail feature Favorite Article Favorite Article Favorite Article Favorite Article Favorite Article Favorite Article Favorite Article Favorite Article Favorite Article Favorite Article Favorite Article Favorite Article Favorite Article Favorite Articl

TABLE II. RESULTS OF 3 TIMES MANUAL TESTING Execution ID [M-1] [M-2] [M-3]

Passing rate 100% 100% 100%

Time of execution 6:12 6:08 6:03

Case failure ID -

Fail feature -

about freeing human effort. It saves time to more important tasks while the system is thoroughly tested. B. Evaluating the Reliability and Stability (RQ2) TABLE III. COMPARISON RESULTS BETWEEN SUITE 1 AND SUITE 2

ID CE1 CE2 CE3 CE4 CE5

Modification Type Text content modification Attribute value change CSS class refactoring DOM structure modification Element replacement

Suite 1 129,5s 126,78s 132,6s

Suite 2 0s 0s 0s

154,7s

0s

159,4s

0s

To answer the question about the stability and reliability of Cypress-based automated testing across repeated executions, our work recorded the total times of failures and detail of which cases failed (see Table I). Based on the recorded data, the undetermined error rate of the entire system was calculated as follows: 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑓𝑙𝑎𝑘𝑦 𝑐𝑎𝑠𝑒𝑠 × 100% 𝑡𝑜𝑡𝑎𝑙 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑐𝑎𝑠𝑒𝑠 2 = × 100% ≈ 7.4% 27 Over 20 consecutive cycles, the Cypress test suite demonstrated that while 92.6% of the scenarios remained stable, the Favorite Article function (test cases #17 and #18) showed fluctuating results which were sometimes passing and failing without any pattern. Thus, the failures are likely influenced by timing or shared state dependencies. Therefore, they are common causes of flakiness in end-to-end testing. As the Favorite Article functionality involves backend update 𝐹

=

9th International Conference on Research in Engineering and Technology (RET 2026)

5

Nguyen et al.

Evaluating Automated Testing on an Open-Source Web Application Using Cypress

operations and asynchronous UI rendering, the observed instability is acceptable and reflects the complexity of the functionality. It also stemmed from limitations of the testing framework. Therefore, the overall results show that Cypressbased automated testing performs stably for most functionalities when executed repeatedly. At the same time, the occurrence of a few flaky tests underscores the importance of careful test design and attention to stability, especially when functionalities with complex interactions are tested, as test instability can undermine the core value of automated testing [19]. C. Evaluating the Maintainability (RQ3) To answer question about how the use of best-practice element locating strategies affects the maintainability of Cypress test suites, our work used two test suites with the same testing logic but different element locating strategies. The first test suite uses traditional locators based on text content, HTML attributes, CSS classes, and DOM structure [18]. The second test suite uses a robust locator based on the data-cy attribute. The table III presents the data collected from the experiments. The results show that test suites using traditional locators are affected by all types of interface changes surveyed [18]. Even small changes, such as changes to text content or attribute values, cause tests to fail and require manual correction. In contrast, utilizing the robust locator is isolated from the user interface updates, and the test suite remains unaffected by any interface change. The fact that these locators are not dependent on the structure or presentation of the interface, which helps the test suite to continue functioning normally without modification. Although the repair time per case for traditional test suites only takes a few minutes due to the organization of test structure in Page Object Model, this result shows that maintenance costs can accumulate significantly when the number of test cases is large or when the interface changes frequently. Therefore, it is particularly important in the context of E2E testing, as tests frequently cover lengthy business flows and rely largely on user interfaces. The robust locators significantly reduce the effort required to maintain the test suite over the long term, even when the application continues to evolve and change. D. Threats to Validity There are several threats to the validity of this study. First, the evaluation was conducted on a single open-source web application (Conduit RealWorld), which limits the generalizability of the results to applications of different sizes or architectures. Second, the flakiness observed in end-to-end testing can be influenced by external factors such as network latency or backend state changes that cannot be completely isolated. Finally, the evaluation of maintainability based on repair time may be subject to the tester's experience bias. VI. CONCLUSION Our work is to evaluate the effectiveness of end-to-end (E2E) automated testing on an open-source web application, through a case study using the Cypress framework. The effectiveness of automated testing is considered in three main aspects: execution time, stability, and maintainability of the test suite. Nevertheless, the effectiveness is heavily dependent on the test suite's design and maintenance, automated testing cannot totally eliminate concerns such as flakiness or

maintenance expenses. However, when it is done correctly, it can add significant value to the software development process. For the future works, we will examine projects with different sizes, domains, and architectural styles in order to improve the generalizability of the results. We will incorporate backend log analysis, network delay evaluation, or test execution order control to gain a deeper understanding of the factors contributing to flakiness in E2E testing. We plan to conduct experimental comparisons between Cypress and other E2E frameworks like Selenium or Playwright, to examine differences in execution efficiency, test stability, and maintenance effort across various development contexts. REFERENCES [1]

Tassey, G., The economic impacts of inadequate infrastructure for software testing (Planning Report 02-3), National Institute of Standards and Technology, 2002, https://www.nist.gov/system/files/documents/director/planning/report 02-3.pdf, last accessed on 26/04/2026 [2] H. Krasner, The cost of poor software quality in the US: A 2022 report, Consortium for Information & Software Quality (CISQ), 2022, https://www.it-cisq.org/wp-content/uploads/sites/6/2022/11/CPSQReport-Nov-22-2.pdf, last accessed on 26/04/2026 [3] T. Dingsøyr, S.Nerur, V. Balijepally, N. B. Moe, A decade of agile methodologies: Towards explaining agile software development, Journal of Systems and Software, Volume 85, Issue 6, 2012, Pages 1213-1221, https://doi.org/10.1016/j.jss.2012.02.033 [4] L. Bass, I. Weber, L. Zhu, DevOps: A software architect’s perspective, Addison-Wesley, 2015 [5] V. Garousi, M. Felderer, M. V. Mäntylä, The need for multivocal literature reviews in software engineering: complementing systematic literature reviews with grey literature. In Proceedings of the 20th International Conference on Evaluation and Assessment in Software Engineering (EASE '16). Association for Computing Machinery, New York, NY, USA, Article 26, pp. 1-6, 2016, https://doi.org/10.1145/2915970.2916008 [6] B. Ray, D. Posnett, V. Filkov, P. Devanbu, A large scale study of programming languages and code quality in github, in Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE 2014). Association for Computing Machinery, New York, NY, USA, pp. 155-165, 2014, https://doi.org/10.1145/2635868.2635922 [7] L. Luo, Software testing techniques: Technology maturation and research strategy (Technical report). Carnegie Mellon University, 2001, https://www.cs.cmu.edu/~luluo/Courses/17939Report.pdf, last accessed on 26/04/2026 [8] E. Dustin, T. Garrett, B. Gauf, Implementing automated software testing: How to save time and lower costs while raising quality, Pearson Education, 2009. [9] I. Sommerville, Software engineering (10th ed., Global ed.), Pearson Education Limited, 2016 [10] S. Pargaonkar, A Comprehensive Research Analysis of Software Development Life Cycle (SDLC) Agile & Waterfall Model Advantages, Disadvantages, and Application Suitability in Software Quality Engineering. International Journal of Scientific and Research Publications. 13. 120-124, 2023, https://doi.org/10.29322/IJSRP.13.08.2023.p14015 [11] C. S. Pareek, Agile vs. Waterfall: A comprehensive analysis of software testing methodologies. International Journal of Innovative Research and Creative Technology, vol. 5, no. 5, pp. 1–12, 2019, https://doi.org/10.5281/zenodo.14282022 [12] M. Cohn, Succeeding with agile: Software development using Scrum, Addison Wesley, 2010 [13] L. Crispin, J. Gregory, Agile testing: A practical guide for testers and agile teams, Addison-Wesley Professional, 2009. [14] M. Shahin, M. Ali Babar, L. Zhu, Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices, IEEE Access, vol. 5, pp. 3909-3943, 2017, https://doi.org/10.1109/ACCESS.2017.2685629 [15] Cypress, Cypress documentation: Cloud and open source testing, 2025, https://docs.cypress.io, last accessed on 26/04/2026

9th International Conference on Research in Engineering and Technology (RET 2026)

6

Nguyen et al.

Evaluating Automated Testing on an Open-Source Web Application Using Cypress

[16] W. Mwaura, End-to-end web testing with Cypress: Explore techniques for automated frontend web testing with Cypress and JavaScript, Packt Publishing Ltd., 2021. [17] P. Runeson, M. Höst, Guidelines for conducting and reporting case study research in software engineering, Empirical Software Engineering, vol. 14, pp. 131–164, 2009, https://doi.org/10.1007/s10664-008-9102-8 [18] Luca et al. 2024 - De Luca, M., Fasolino, A. R., & Tramontana, P. (2024). Investigating the robustness of locators in template-based Web application testing using a GUI change classification model. The Journal of Systems & Software, 210, 111932. https://doi.org/10.1016/j.jss.2023.111932 [19] S. Habchi, G. Haben, M. Papadakis, M. Cordy and Y. L. Traon, "A Qualitative Study on the Sources, Impacts, and Mitigation Strategies of Flaky Tests," 2022 IEEE Conference on Software Testing, Verification and Validation (ICST), Valencia, Spain, 2022, pp. 244-255, https://doi.org/10.1109/ICST53961.2022.00034

9th International Conference on Research in Engineering and Technology (RET 2026)

7

Nguyen et al.

Evaluating Automated Testing on an Open-Source Web Application Using Cypress APPENDIX A: 27 TEST CASES

9th International Conference on Research in Engineering and Technology (RET 2026)

8

Related documents

• Multi-SWT-Bench: A Multilingual Benchmark for Reproduction Test Generation#1129010
• Multi-SWT-Bench: A Multilingual Benchmark for Reproduction Test Generation#1108830
• COVID-19 Screening Program#1087540
• A Comprehensive Study of Native Code Bugs in Python Applications#622459
• Interactive Parallelization of Embedded Real-Time Applications Starting from Open-Source Scilab & Xcos#464047