Razones del error en las pruebas automatizadas del lado web
Los fallos iniciales de las pruebas automatizadas se deben a expectativas poco realistas. He observado esto muchas veces en mi carrera: una vez que obtienes la automatización del control de calidad o de los empleados, la gerencia quiere que automaticen las pruebas de todo. Si bien esto suena delicioso, es imposible. No se pueden lograr pruebas 100% automatizadas ya que hay varios aspectos que deben verificarse manualmente. Una de estas áreas puede estar relacionada con la accesibilidad de las aplicaciones web.
Por ejemplo, si está realizando pruebas automatizadas en varios navegadores, los scripts automatizados para las pruebas de Selenium mostrarán la página en diferentes navegadores o sistemas operativos. Sin embargo, para determinar si el sitio web se presenta según lo diseñado, si el diseño es apropiado y si el texto es apropiado, es mejor realizar una evaluación manual
Muchas organizaciones se dan cuenta de que el planteamiento del problema espera 100%. pruebas automatizadas, pero a menudo encuentran las siguientes preguntas. ¿Cuánta automatización, si no 100, podemos automatizar para productos web?
No existe un porcentaje o una aproximación perfecta de cobertura de pruebas de automatización que funcione para todas las organizaciones. Todo depende de la aplicación web que esté entregando y diferentes organizaciones tienen diferentes necesidades. Naturalmente, habrá expectativas únicas sobre qué porcentaje de pruebas de automatización se puede lograr realmente. El alcance de las pruebas automatizadas varía desde aplicaciones web de comercio electrónico hasta aplicaciones web estáticas, dinámicas o animadas. Entonces, si se pregunta por qué las pruebas automatizadas fallan en su organización. Entonces le recomiendo que evalúe la cantidad de pruebas automatizadas necesarias según el tipo de aplicación web que esté entregando.
He sido víctima de una mala gestión desde que comencé mi carrera en TI como tester de automatización. Estaba trabajando para una empresa de servicios y me asignaron mi primer proyecto. El proyecto lleva dos años funcionando y cuando me uní, me entregaron una serie de scripts de automatización de pruebas. Los miembros superiores del proyecto estaban a punto de abandonar la empresa y la dirección estaba ocupada con la próxima fase de sprint y no consideró un curso completo de transferencia de conocimientos por parte de los probadores superiores de automatización que se marchaban. ¿Qué mala escena pasó después de que se fueron? Mi gerente concluyó la audiencia diciendo que esta interrupción nos tomó por sorpresa, que yo acababa de comenzar a trabajar y tenía poca comprensión de cómo los diversos procesos de entrada y salida se veían afectados por numerosos scripts automatizados. Sin embargo, también he visto equipos donde solo unos pocos miembros eran responsables de implementar la automatización y el resto no tenía idea de lo que estaba pasando.
¿Crees que no es realista obtener resultados mágicos a partir de pruebas automatizadas cuando la mitad de los miembros del equipo carecen de visibilidad? Dado que la automatización debe ser un esfuerzo colaborativo, es importante que cada miembro del equipo comprenda las herramientas y los procesos involucrados, especialmente si es nuevo en esto. Puede hacerlo celebrando reuniones de equipo y conferencias para discutir herramientas, tendencias y prácticas relacionadas con la automatización.
Otro motivo por el que falla la automatización de pruebas puede ser la falta de habilidades de prueba manuales o de pruebas exploratorias, lo que puede resultarle un poco sorprendente. La automatización de los scripts de prueba no significa que los miembros del equipo puedan holgazanear. Hasta ahora, hemos aprendido que un enfoque automatizado no puede cubrirlo todo, y ahí es donde radica el desafío. Porque ahora tienes que profundizar en tu aplicación web para encontrar escenarios de prueba críticos que los miembros de tu equipo aún no han descubierto.
La automatización es una forma de ahorrar esfuerzo de prueba. Las empresas de software deberían utilizar esto para minimizar la duplicación y tratar de automatizar elementos que no se modifican fácilmente. Una vez que se completa la automatización, las empresas deben asignar recursos para realizar pruebas manuales exhaustivas o pruebas exploratorias para descubrir casos de prueba únicos.
La automatización parece ser un objetivo para reducir la carga de trabajo. Pero antes de desarrollar scripts de automatización de pruebas, debe pensarlo detenidamente. Además, la ejecución de pruebas automatizadas puede llevar mucho tiempo. La flexibilidad del marco y las herramientas de automatización de pruebas juega un papel crucial en el tiempo necesario para desarrollar escenarios de script.
Dado que cada escena es diferente, hay que guionizarla.
No importa lo bien que lo pienses, si no escribes un guión, todo será en vano. Asegúrese de que las habilidades de codificación del ingeniero de pruebas coincidan con la complejidad de la prueba. Las pruebas complejas requieren mucho tiempo para automatizarse. Como resultado, a menudo no tienen la oportunidad de detectar errores de regresión cuando desarrollan funciones completamente nuevas. Antes de escribir un escenario de prueba, asegúrese de tener en cuenta estas consideraciones.
" ¿Por qué falla la automatización de pruebas en su empresa? La razón más común detrás de esto es que las personas no saben cuándo automatizar y cuándo no. Por ejemplo, se pueden automatizar diferentes funciones web. Pero mediante pruebas No es una buena idea automatizar la evaluación de relleno, imágenes, etc. Si usa coordenadas para determinar la posición del elemento, puede causar diferencias cuando se ejecuta en diferentes resoluciones y tamaños de pantalla.
El uso de la automatización es. No es factible cuando se están produciendo muchos cambios en el proyecto. Si está probando entidades estables, entonces la automatización es el camino a seguir. Básicamente, las tareas comunes que requieren que ciertas acciones se realicen repetidamente son las más adecuadas para las pruebas de automatización. La automatización de pruebas simplifica el proceso de pruebas de regresión.
Existe una idea errónea común en la industria de TI de que la automatización de pruebas requiere habilidades específicas para diseñar, configurar e implementar. El evaluador que realiza la automatización debe saber cómo comunicar ideas. entre gerentes, desarrolladores y clientes también debe tener una comprensión clara de las tendencias de desarrollo y saber hacia dónde se dirige el equipo de desarrollo.
Los ingenieros de pruebas de automatización son el talento más difícil pero más importante de reclutar. Para iniciar varios proyectos de automatización, es fundamental contratar probadores con sólidos conocimientos técnicos. Todo el equipo debe saber lo que está sucediendo, no solo una persona o varias personas, aunque la inversión en contratación de personal técnico es alta. , las recompensas valen la pena
Dado que las pruebas automatizadas son un fenómeno relativamente nuevo, las posibilidades de falla son altas. Hay muchos experimentos nuevos por realizar, por lo que es muy importante que los evaluadores escriban detalles. informes de prueba después de realizar las pruebas. Pero esta es la razón por la que la automatización de pruebas falla. Si se realiza incorrectamente, el análisis puede provocar fallas desatendidas y pérdida de tiempo, recursos y esfuerzo.
En las pruebas automatizadas, algunas pruebas tienen éxito. algunas fallan. Por lo tanto, consulte los informes de las pruebas. Es importante desglosar y analizar por qué fallan ciertas pruebas. Es mejor realizar el análisis manualmente para descubrir problemas ocultos y asegurarse de que no queden enmascarados por otros problemas y pasen desapercibidos. p>
Establecer los verdaderos objetivos de la automatización parece perfecto en el papel. Sin embargo, los miembros del equipo sufren de una grave falta de claridad a la hora de ejecutar los pasos. El mayor problema es su falta de precisión y claridad. No se puede obtener ningún valor real de la automatización. Lo que hacen la mayoría de las empresas es comenzar a automatizar cosas muy complejas y terminar refactorizando todo el marco. Como resultado, el equipo termina perdiendo mucho tiempo, dinero y esfuerzo. >
Puede eliminar la incertidumbre comenzando poco a poco y aumentando gradualmente la complejidad. Después de seleccionar una función estable y automatizarla, recopile comentarios para determinar qué salió mal. Una vez que sus pruebas alcancen coherencia, podrá pasar a otras funciones. Los diferentes entornos de proyectos pueden tener requisitos diferentes, por lo tanto, utilice un enfoque personalizado para probar la automatización.
Existen tantos tipos de herramientas de automatización que a veces resulta muy complicado elegir la mejor. Nuestro objetivo final es mejorar el procedimiento de prueba general y cumplir con los requisitos del mundo real. Pero la mayoría de los equipos no empiezan desde cero ni eligen las herramientas que mejor se adaptan a sus necesidades de prueba. No hay duda de que las pruebas automatizadas dependen en gran medida de la herramienta que decida seguir utilizando. Cada herramienta tiene funciones específicas. Sin embargo, el equipo carecía del nivel de experiencia necesario para aprovechar al máximo estas capacidades.
Además, las empresas pueden verse atraídas por el revuelo que rodea a una herramienta en particular. Pero después de elegir, descubrieron que la herramienta no ofrecía todo lo que esperaban.
Además, cada equipo tiene un presupuesto y, a veces, el coste de las herramientas supera el presupuesto. Antes de elegir una herramienta operativa, describa cuidadosamente sus requisitos. Luego, determine sus expectativas para la herramienta. Sea muy específico al establecer objetivos y compárelos con los criterios de aceptación del usuario del producto. También puede consultar a un experto que tenga experiencia en el uso de estas herramientas.
Este es un problema al que se enfrentan casi todas las organizaciones. Una vez que el conjunto de pruebas automatizadas esté en funcionamiento, la administración puede comenzar a relajarse. Comienzan a relajarse en un análisis en profundidad de la ejecución de las pruebas porque creen que sólo las comprobaciones de pasa/falla son suficientes. ¡Pero esa es exactamente la razón por la que la automatización de pruebas hace que fallen!
A veces los sistemas funcionan fundamentalmente bien. Sin embargo, el script de automatización no refleja esto. Sus representaciones no se corresponden con la realidad, lo que da lugar a escenarios falsos positivos. Por tanto, esto crea una situación confusa y desperdicia tiempo, energía y recursos. ¡He visto de primera mano lo frustrante que puede ser para un equipo de pruebas intentar encontrar algo que no existe!
Cada elemento web debe tener un ID para realizar pruebas válidas. Pero a veces, los desarrolladores no asignan ID a todos los elementos web y es por eso que falla la automatización de pruebas. En este caso, el script de automatización debe encontrar estos elementos web, lo que puede llevar mucho tiempo. Además, si el script no puede encontrar estos elementos dentro del tiempo especificado, la prueba fallará. Por lo tanto, para garantizar una sincronización adecuada de los scripts, el equipo debe asignar ID únicos a todos los elementos web.
Así que, en última instancia, todo lo que desees automatizar quedará automatizado. Con el tiempo, tendrás un conjunto de pruebas enorme y recién ahora estás empezando a chocar contra una pared. La ejecución de estos complejos conjuntos de pruebas puede tardar más de lo esperado. Esto comienza a entrar en conflicto con la calidad de las colas de prueba en el respectivo marco de automatización de pruebas del entorno de desarrollo integrado. Como resultado, los casos de prueba se detendrán repentinamente debido a problemas de tiempo de espera de la cola, todo porque intenta ejecutarlos secuencialmente. La ejecución secuencial de casos de prueba es otra razón por la que falla la automatización de pruebas de aplicaciones web.
A diferencia de ejecutar pruebas de forma secuencial, la ejecución en paralelo le permite ejecutar múltiples pruebas simultáneamente en diferentes entornos. Sin embargo, las pruebas automatizadas pueden provocar interacciones de código inesperadas. Depurar la causa de una falla es difícil, por lo que necesita un mecanismo de informes integral que proporcione detalles de la ejecución de su prueba.
No importa qué negocio ejecute en línea, el retorno de la inversión estará en la agenda de cada reunión de la junta directiva. Los accionistas exigen mayores retornos. Y no importa cuánto tiempo y esfuerzo dedique a preparar su conjunto de automatización de pruebas, si no generan el retorno de la inversión que espera, serán mucho menos importantes de lo que espera.
Al calcular el ROI de la automatización de pruebas, puede haber muchas métricas a considerar, como el mantenimiento de las pruebas, los costos involucrados en la compra de las herramientas de automatización de pruebas necesarias, los recursos de incorporación, etc. Para muchas organizaciones, la planificación de un retorno de la inversión poco realista puede resultar problemática y provocar fallos en la automatización de las pruebas.
Muchas organizaciones tienen la impresión de que la automatización de pruebas es sencilla. Puede automatizar el flujo de trabajo de prueba de su aplicación web con solo unas pocas líneas de código. ¡Eso es todo! No tiene que preocuparse en absoluto por planificar y escribir sus scripts de automatización de pruebas. ¡Pero ese no es el caso!
Es necesario evaluar los efectos dominó. Su aplicación web contendrá muchos scripts de automatización de pruebas diseñados para probar diferentes módulos y procesos. Si un script de prueba no se ejecuta correctamente, otros scripts también pueden provocar fallas en la automatización de pruebas. No sólo eso, sino que también debes tener en cuenta los efectos en cadena al planificar tus recursos.
Supongamos que tiene un recurso senior que solía escribir guiones pero que ahora dejó la empresa. Lo que quizá no se le ocurra es que su dimisión podría tener un efecto dominó en el progreso futuro de los proyectos de automatización. Por lo tanto, es importante documentar cada detalle de cada script de prueba automatizado en su sistema. Este documento debería servir como estándar tanto para los probadores de automatización nuevos como para los experimentados.
Otro motivo por el que la automatización de pruebas falla en su organización puede ser un conjunto de pruebas inadecuado.
Muchos evaluadores de automatización crean conjuntos de pruebas estáticas que no son flexibles a la hora de ampliar su negocio. Cada vez que la plataforma crece, terminan reescribiendo todos sus scripts de prueba automatizados. Este es un mal hábito porque estás perdiendo tiempo, recursos y dinero. Además, este es el proceso incorrecto. Asegúrese de escribir conjuntos de pruebas que puedan crecer y adaptarse a medida que se expande su plataforma.
Otra forma de evitar fallos en la automatización de pruebas es mejorar su conjunto de pruebas. Ahora bien, esto puede parecer obvio, pero no se practica en muchas organizaciones. La razón es que una vez que diseñan un conjunto de pruebas y descubren que funciona, comienzan a automatizar nuevas áreas. No pretendo criticar los esfuerzos por permitirse o explorar nuevas fronteras de la automatización. Sin embargo, no está de más administrar un período de tiempo en el que usted y su equipo puedan revisar los fragmentos de código existentes y encontrar formas de optimizarlos aún más. Intente siempre utilizar conjuntos de pruebas para mejorar su trabajo.
Con la adopción global de metodologías SDLC (ciclo de vida de desarrollo de software) modernas, como software ágil, software Kanban y más, la colaboración se ha convertido en un elemento clave para implementar aplicaciones web en el mercado más rápidamente.
Este es un proceso de desarrollo de software multidimensional en el que todos los equipos desarrollan aplicaciones web simultáneamente. Un grupo de desarrolladores es responsable de diseñar el front-end, otro grupo es responsable del back-end y otro grupo es responsable de las actividades del middleware. Como evaluador, necesita saber qué equipo es responsable de qué módulo. Debe mantenerse informado sobre las mejoras realizadas en el producto por diferentes equipos y realizar cambios relevantes en los scripts de automatización para garantizar que la automatización de la prueba no falle.
El objetivo principal de las pruebas automatizadas es ahorrar tiempo minimizando el estrés de las pruebas manuales repetitivas. Esto suena abstracto, pero quienes realizan la automatización de pruebas deben reconocer la dificultad de configurar la infraestructura adecuada para realizar la automatización de pruebas internas. A menudo veo a los evaluadores actualizar todo el conjunto de automatización de pruebas antes de ejecutar un nuevo script para evitar cualquier ambigüedad en el script. Pero eso no significa que todo el proceso de prueba automatizado falle, ¿verdad?
Por ejemplo, si está realizando pruebas automatizadas en varios navegadores utilizando una cuadrícula interna de Selenium para probar su sitio web para los sistemas operativos macOS y Windows, Google Chrome y los navegadores Safari. Ahora, es posible que tengas que lidiar con la molestia de configurar un nuevo sistema operativo cada vez antes de ejecutar el script Selenium.
Esta es una razón común por la que fallan las pruebas de automatización empresarial. Especialmente cuando se acerca la fecha límite. Su departamento de pruebas continuará ejecutando numerosos conjuntos de pruebas en el mismo entorno de prueba sin borrar el caché de los scripts de automatización de pruebas ejecutados previamente. Esto puede dar lugar a evaluaciones de pruebas erróneas y los informes de sus pruebas pueden verse afectados porque experimentará más falsos negativos y falsos positivos.
Por ejemplo, supongamos que necesita probar una aplicación web para diferentes ubicaciones geográficas. Al realizar la orientación geográfica en un entorno de prueba estático. Google puede poner a prueba tu script y exigirte que demuestres que no eres un robot. Esto hará que falle el script de automatización de pruebas.
Esta es la razón para utilizar una nueva máquina virtual con el caché limpio, para que pueda obtener resultados precisos para sus scripts de prueba automatizados en varios navegadores.
Hacer que la automatización funcione en diferentes entornos de prueba requiere mucha planificación. Debe realizar pruebas en un entorno de prueba para asegurarse de que su código se ejecute sin problemas cuando lo mueva a su canal de producción. Sin embargo, a menudo sucede que los scripts de automatización de pruebas para cambios de código se ejecutan sin problemas cuando se prueban en un entorno de prueba, pero tienen problemas cuando se trasladan a producción. Puede haber muchas razones detrás de estos problemas, como la falta de monitoreo continuo, la incapacidad de los entornos escénicos para crecer en conjunto con los entornos de producción, la falta de tráfico en tiempo real, etc.
Pero no menos importante. Si hemos cubierto todos los puntos hasta ahora y su automatización de pruebas sigue fallando, el único lugar que necesita repensar es en sus propios scripts de automatización de pruebas.
Asegúrese de que no haya errores de tiempo de compilación y de ejecución en ningún script de prueba que involucre a lo largo del proyecto.
Si su organización necesita aumentar la productividad, las pruebas automatizadas son el camino a seguir. Es uno de los procesos más efectivos necesarios para mejorar la calidad del producto. La automatización de pruebas también puede mejorar la solidez del software. Sin embargo, se debe tener precaución en la implementación y el retraso. No puede haber prisa, ya que ninguna empresa puede permitirse el lujo de perder enormes cantidades de dinero. Por otro lado, demasiado miedo también puede impedirle aprovechar los enormes beneficios de las pruebas automatizadas.
¡¡¡Gracias por leer atentamente mi artículo!!!!
Si puede utilizar la siguiente información, puede obtenerla directamente:
1. El código fuente completo del proyecto y el entorno necesario para desarrolladores o evaluadores autodidactas
2. Todas las plantillas para el trabajo de prueba (planes de prueba, casos de prueba, informes de prueba, etc.).
2. Todas las plantillas en el trabajo de pruebas (planes de prueba, casos de prueba, informes de prueba, etc.)
3. Preguntas clásicas de la entrevista sobre pruebas de software
4. Práctica de pruebas automatizadas de Python/Java. pdf
5. Un conjunto completo de vídeos sobre las pruebas de la interfaz Jmeter/postman
5. Pruebas de la interfaz Jmeter/postman
Personalmente compilé algunos de los vídeos que Materiales técnicos compilados durante mis muchos años de carrera en pruebas de software, que incluyen: libros electrónicos, módulos de currículum, varias plantillas de trabajo, guías de entrevistas, proyectos de autoaprendizaje, etc.
He recopilado personalmente algunos materiales técnicos que he recopilado durante mi carrera de pruebas de software en los últimos años, que incluyen: módulos de currículum, varias plantillas de trabajo, guías de entrevistas, proyectos de autoaprendizaje, etc. Si lo necesitas ponte en contacto conmigo