You're debating the frequency of regression tests with your team. How do you find common ground?

- Agreed, prioritizing regression tests based on risk is essential for resource optimization. - High-risk areas like financial transactions indeed need frequent testing. - Reducing test frequency for low-risk changes is a practical approach. - Team discussions on bug impacts can enhance understanding and prioritization. - Overall, this strategy ensures efficient and effective testing.

To find common ground on regression test frequency, discuss the team's priorities and risks, highlight the benefits of frequent testing for stability, and agree on critical scenarios that require more attention while balancing resource efficiency.

Agreed, Regression should be based on the potential impact of the feature introduced and its relative module to access the likelihood of defects and to avoid bug leakage in final prototypes of the application.

Whenever the module gets repetitive it is best to create an automation script for the regression purpose. In real time it helps the project team to focus on completion of the active sprint without worrying much about the past sprints. Also it helps in finding bugs related to release change, deployment errors etc..

For a large project involves multiple modules and workflows, the manual test effort for executing the regression will be time consuming and repetitive. So it would be better to have an automation framework which involves the regression test scripts, so that we could save total test execution time and utilise the manual effort on the feature more effectively. And if the application or its flows are changing continuously, it is important to have a resource dedicated to update the regression test scripts with the changes happening in the application.

- I believe it’s not a good approach using automation for regression testing. Cause if in future you add or delete modules to your product it will be hard for testing team to use the same old script for regression or even if you do versioning of script still you required a batch of script as per scenarios. So, I believe it could be more time taking than manual regression. - The good approach is use automation testing for unit testing to identify single units are functioning expectedly and perform regression testing manually.

Agreed that test automation is the best way to execute the feasibile regression test cases. One thing I have found helpful is grouping the automated regression test cases according to the Priority levels. Modularizing the huge regression set into multiple smaller subsets and executing one or more subsets based on time, risk and team capacity. With the well designed automation suite, it is much easier and time saving to run the same tests repeatedly on multiple environments without too much of hassle.

Here are some key points to help you reach consensus with your team, Project Needs: Consider app criticality (e.g., finance) & release schedule. More critical apps or frequent releases might require more testing. Team Capacity: Assess available resources for running tests and how much of the suite is automated (faster, less manual effort). Strategy: Start with a baseline frequency (e.g., before releases) and adjust based on needs. Run comprehensive tests regularly (e.g., weekly) with critical tests running more often (e.g., after each commit).

Automating scripts for only stable features of the application can help reduce testing efforts by larger. While critical/newly added feature should be testing by manual practices to avoid bug leakage.

Continuous Integration (CI) is a software development practice where code changes are automatically built, tested, and integrated into a shared repository on a frequent basis. The goal of CI is to detect integration errors early in the development process, ensuring that software components work together smoothly. Developers regularly commit code to a version control system, triggering automated builds and tests. CI pipelines typically include compiling code, running automated tests (unit tests, integration tests), and deploying applications to test environments. By implementing CI, teams can improve collaboration, streamline development workflows, and deliver software updates more reliably and efficiently.

- Integrating regression tests into CI ensures consistent and automated testing. - Helps maintain high testing frequency without manual effort. - Promotes team agreement on testing standards. - Enhances reliability and quality of code integration.

- Acknowledging team capacity is essential when setting test frequency. - Overloading the team can cause burnout and lower test quality. - Open discussions on workload help balance testing efforts. - Sustainable practices ensure effective, long-term testing without straining resources. - Prioritizing team well-being is crucial for success.

Automation for stable features alone can helps in regression in case of frequent changes going live. And continuous development of scripts should be done once new features once they stabilizes.Risk assessment helps to reduce the scope of regression testing based on which resource allocation can be done

As we approach the project launch, it is imperative to conduct frequent regression testing, especially in high-risk areas. Each time a new build is deployed, it is crucial to run your test cases in the Continuous Integration (CI) system to ensure everything operates as expected. Inform your team that we are nearing the launch date and any issues arising on the client side will reflect on the entire team.

- Project stage greatly affects regression test frequency. - Early development stages require more frequent testing due to significant changes. - As the project stabilizes, testing frequency can be reduced. - Team discussions ensure testing strategy adapts to project evolution. - Flexibility is key to effective testing.

Regression tests are often hectic and sometimes mind altering for instance as the code gets integrated continuously sometime somewhere something might break and its tedious to find out what went wrong if there are numerous components in play One thing i have observed is if there is an underlying issue which could not be reproduced in further regression tests then the dev team might assume that it somehow got fixed magically but in reality The bug exists, its hiding in plain sight and when somewhere sometime something goes wrong Its all interdependent on various factors like Quality of test cycles , Frequency of Integrations, Build and CL issues etc