Las pruebas automatizadas fallan mientras que las pruebas manuales pasan. ¿Confía en su estrategia de pruebas?

Automated and manual testing serve different purposes and operate under different conditions. Automated tests are typically designed to be repeatable and consistent, running the same set of operations under predefined conditions. In contrast, manual testing is often more flexible and can adapt to real-time conditions and observations made by the tester. When automated tests fail while manual tests pass, it might be due to several reasons: 1.Environment Differences 2.Timing Issues 3.Test Data Variability 4.Test Script Issues 5.Flaky Tests

Confirm that the environment in which the automated tests are running is consistent with the environment used for manual testing. Differences in configurations, dependencies, or data can cause variations in test results.

Yes testing strategy is good as might be chance to have environmental or some configuration issue while running the automation test cases. Might on control environment browser might act differently rather than on manual environment. First verify covering same manual scope/functionality in automation test cases. Also verify covering same flow in automation. If still issue persist verify configuration and validate environmental been correctly setup. If still getting issues on running automation test cases need to verify functionality with requirement/BA/Developer

Segun desde mi experiencia en logrado observar que las pruebas automatizadas se rajan mientras que las manuales pasan sin problema. Esto puede ser porque los entornos de prueba son distintos. Las pruebas automatizadas suelen hacerse en ambientes muy controlados, casi como en una burbuja, mientras que las pruebas manuales se hacen en condiciones más parecidas a la realidad. Cosas como la configuración de la red, los datos y el hardware pueden causar esas diferencias. Para evitar esos líos, es clave que el entorno de las pruebas automatizadas sea lo más similar posible al de producción. Así se reducen las diferencias y se puede confiar más en los resultados.

In addition to the great 7 points, I want to mention the caching problem which may cause automated test flakiness, you need to disable the cache in the automation test environment and use an incognito browser. You have to start every test run in a clean environment.

Review the test cases to ensure that both automated and manual tests cover the same functionality and edge cases. Gaps in test coverage can cause automated tests to fail. Ensure that the assertions in automated tests are correct and reflect the expected outcomes accurately. Check if automated tests depend on specific data or states. Fluctuating data or states can lead to inconsistent test results.

Test Design also important as here we decides way of execution and end to end flow it can also hamper the performance of execution

Diseñar los casos de prueba es una de las tareas más importantes ya que el criterio de que un flujo sea éxitoso que de como resultado esperado lo que el usuario requiere es necesario que la documentación (historia de usuario, documentos de requerimientos, caso de uso, etc.) sea precisa, después de relizar la identificación escenarios y de casos de prueba si es necesario se debe realizar una reunión para aclarar toda duda del flujo. El diseño de un mal caso de prueba puede implicar pasos insuficientes o pasos extra además de no cumplir con el objetivo de la prueba

Automated test data could be using different set data so ensure test cases cover the same functionality and edge cases. Implement wait and retries condition in automate test so to make them more resilient.Design automation within the Page Object Model (POM) structure to eliminate reliance on any hardcoded values, ensuring alignment with manual test cases in both coverage and precision.

Automatic test are provided with predictive results needed to pass the test. When anomalies occurs, manual test is needed to investigate what when wrong.

This is the inherent problem of traditional test automation frameworks, or the ones working on unreliable XPath/CSS locators. You need to change the way you identify your UI elements, else these flaky tests will eat up your time, effort, and money. Use intelligent test automation tools that do not work on XPath/CSS locators. These tools use AI to identify an element, so even if a button's property changes, e.g., the button is renamed to 'Login' instead of 'Sign-in,' the tool will still be able to recognize the element without any break in the test execution. testRigor is one such tool (AI agent) that lets you write/generate (using AI) test cases in plain English or any other natural language and has self-healing capabilities.

Some of the strategies that I use: 1.Isolate the Test Environment: Flaky tests often result from the inconsistent state of the application. Using test harnesses or fixtures helps create a controlled state before each test. 2.Review Pipeline Schedules: Running the same tests simultaneously can lead to conflicts. Using strategies like concurrency groups (e.g., in GitHub Actions) can prevent overlapping test executions. 3.Clearly Define Test Boundaries: Minimize external dependencies to improve test stability. Eg: for dev UI tests, mock backend calls or find ways to bypass the login process to reduce variability. 4.Use Robust Locator Strategies for UI Tests: Collaborate with developers to establish locators that are less likely to change

Para abordar la descamación en las pruebas automatizadas, implemente prácticas como la sincronización adecuada, el uso de mocks y stubs para eliminar dependencias externas, y la revisión y ajuste regular de los tiempos de espera en las pruebas. Establezca un proceso para analizar y documentar los fallos intermitentes, facilitando la identificación de patrones y la resolución de problemas. Capacite al equipo en técnicas avanzadas de depuración y mantenga una comunicación constante sobre las mejores prácticas y lecciones aprendidas para mejorar continuamente la fiabilidad del conjunto de pruebas.

1. Flaky test case can create uncertainty and generate challenges for software development teams. This requires the test cases to be isolated in such a way that the test does not depend on or impact any external factors or other tests. 2. Use modular, reusable and maintainable code. 3. Reset or clear the state before and after each test case is executed. 4. Retries, timeouts or waits should be used efficiently to avoid page loading issues due to network or performance factors. 5. Another important task is to regularly review the test cases and test scripts and adapt them to the testing environment.

Flaky tests are a common issue in automated testing where tests fail intermittently without consistent reasons. These failures can undermine confidence in your testing strategy, as they may pass under manual inspection. The causes of flaky tests include unstable test environments, timing issues, dependencies on external systems, and improper test design. Addressing flaky tests involves stabilizing the environment, refining test design, and implementing robust error handling and retries. Ensuring reliability in automated tests is crucial for maintaining confidence in the overall testing strategy.

I value the balance between automated and manual testing. While automation handles repetitive tasks efficiently, my manual testing brings in human insight and adaptability, crucial for identifying nuanced issues.

This is true, that is, the difference between manual tests, which are influenced by the intuition and observation power of the tester, versus automated tests, which are fixed and repetitive. Of course, a balance is required between the two, and several criteria are included in it. The cost of programming and completing automated tests, and the cost here means the cost of time and reviewing them. Reconsidering some scenarios and manual test cases and whether it is really worth converting them to automated tests. The difficulty and complexity of manual test cases may indicate the need to convert them from manual to automated. Data cleaning and preparing the environment for tests, and how much does this process cost in both cases?

Continuous Integration (CI) is a software development practice where developers regularly merge their code changes into a central repository, often multiple times a day. Each merge triggers automated builds and tests to detect integration errors as early as possible. CI helps teams deliver software more frequently, with improved quality, by automating the process of validating code changes and ensuring that they work well together in the shared codebase. It promotes collaboration among team members and reduces the risks associated with integrating new features or fixes into the main branch of the project.

Yes As CICT is now a days very effective way of Continnous enablig of testing automation after every deployment and also overnight jobs those helps in early bug detection without much human manual intervention.

One crucial aspect of maintaining confidence in your testing strategy is establishing effective feedback loops. Automated tests may fail while manual tests pass due to various issues like flaky tests, environmental inconsistencies, or incorrect assumptions in test scripts. Implementing continuous feedback loops allows teams to quickly identify and address these discrepancies. By consistently reviewing test outcomes and updating both automated and manual test cases, teams can ensure that automated tests are as reliable as manual ones, leading to improved software quality and a more robust testing strategy.

Also we need to consider ,high iteration testing is possible through automation but not manually. Sometimes issues / bugs could be seen in s/w or h/w when these HI tests are run which may not be seen upon manual testing.

Consideration of integration testing can also be a good practice. While you are going to integrate a new components or subsystem in your system it is crucial to do integration testing at the same time which can save your time to get later bugs .