Una guía completa para iniciar el Test de Automatización en su proyecto:
¿Qué es la prueba de automatización?
La prueba de automatización es una técnica de prueba de software para probar y comparar el resultado real con el resultado esperado. Esto se puede lograr escribiendo scripts de prueba o utilizando cualquier herramienta de pruebas de automatización. La automatización de pruebas se utiliza para automatizar tareas repetitivas y otras tareas de prueba que son difíciles de realizar manualmente.
¿Quieres empezar las pruebas de automatización en tu proyecto pero tienes problemas con los pasos más básicos que se mencionan a continuación:
- ¿Cómo introducir la automatización en tu proyecto?
- ¿Cómo seleccionar la mejor y correcta herramienta de automatización?
- ¿Cómo desarrollar scripts de manera efectiva?
- ¿Cómo ejecutar y mantener los scripts de prueba?
- Y, finalmente, ¿cuáles son las mejores prácticas que debe seguir para el éxito de las pruebas de automatización?
- ¿Qué es el Testing de Automatización?
- Automatización – Un método rentable para las pruebas de regresión
- Escenarios que requieren automatización
- Pruebas correctas para la automatización
- ¿Qué NO automatizar?
- #1) Pruebas negativas/pruebas de recuperación de fallos
- #2) Pruebas ad hoc
- #3) Pruebas con preconfiguración masiva
- Ejemplo sencillo de automatización de pruebas
- What are Assertions?
- Conclusión
Hoy, hemos planeado enriquecer su conocimiento con una serie de tutoriales sobre «Introducción a las pruebas de automatización». Esta serie de tutoriales de automatización responderá a todas las preguntas anteriores de una manera paso a paso con ejemplos sencillos.
¡Vamos a echar un vistazo a la serie de tutoriales sobre el inicio de la automatización en su proyecto!
Proceso de automatización de principio a fin:
Tutorial #1: La mejor guía para empezar la automatización en tu proyecto
Tutorial #2: Tipos de pruebas automatizadas y algunos conceptos erróneos
Tutorial #3: 10 pasos para introducir la automatización en tu proyecto
Tutorial #4: La guía de la A a la Z para seleccionar la mejor herramienta de automatización
Tutorial #5: Desarrollo de scripts y marcos de automatización
Tutorial #6: Ejecución y reporte de la Automatización
Tutorial #7: Mejores Prácticas y Estrategias de Automatización de Pruebas
Consejos de Automatización:
Tutorial #8: 10 Consejos que debes leer antes de automatizar tu trabajo de pruebas
Tutorial #9: ¿Cómo difiere la planificación de pruebas para proyectos manuales y de automatización
Tutorial #10: ¿Cuándo optar por la automatización?
Tutorial #11: Desafíos de las Pruebas de Automatización
Tutorial #12: Guía para Implementar Pruebas de Concepto (POC) en Automatización
Tutorial #13: Cómo Seleccionar los Casos de Prueba Correctos para la Automatización
Tutorial #14: Cómo Traducir los Casos de Prueba Manuales en Scripts de Automatización
Carrera de Automatización:
Tutorial #15: Consejos para Convertirse en un Mejor Tester de Automatización
Tutorial #16: Automatización de Pruebas – ¿Es una Carrera Especializada? ¿Pueden los testers normales hacer automatización también?
Herramientas de automatización populares:
Tutorial #17: Tutoriales de Selenium 31+ Los mejores tutoriales gratuitos de formación en Selenium
Tutorial #18: QTP Tutorials
Tutorial #19: SoapUI Web Services Testing Tool
Tutorial #20: HP LoadRunner for Performance Testing
Framework de Automatización:
Tutorial #21: Por qué necesitamos frameworks para la automatización
Tutorial #22: Frameworks de automatización más populares
Automatización en Agile:
Tutorial #23: Cómo implementar una automatización eficiente en el mundo Agile
Otras herramientas de automatización:
Tutorial #24: Mejores herramientas de pruebas de automatización
Tutorial #25: Herramienta de automatización Sikuli GUI
Tutorial #26: PowerShell: Desktop Application UI Automation With PowerShell
Tutorial #27: Katalon Automation Recorder (Selenium IDE Alternative)
Tutorial #28: Geb Tool: Automatización del navegador usando Geb Tool
Tutorial #29: AutoIt: Cómo manejar las ventanas emergentes usando AutoIt
Tutorial #30: Cucumber: Automatización con la herramienta Cucumber y Selenium
Tutorial #31: Herramienta de pruebas Protractor para el testeo de extremo a extremo de aplicaciones AngularJS
Testeo de automatización móvil:
Tutorial #32: Tutorial práctico de Appium Studio
Tutorial #33: Tutorial de Appium para principiantes
Tutorial #34: Tutorial de Selendroid: Android Mobile Automation Framework
Tutorial #35: Tutorial de Ranorex: A Powerful Desktop, Web, and Mobile Testing Tool
Ejemplos de Automatización Específicos de un Dominio:
Tutorial #36: Automatización de Aplicaciones JAVA/J2EE
Preparación de Entrevistas para Trabajos de Automatización:
Tutorial #37: Preguntas de Entrevistas de Pruebas de Automatización
Tutorial #38: Preguntas de Entrevistas de Selenium
¡Exploremos el primer tutorial de la serie «The Ultimate Guide to Automation Testing»!
¿Qué es el Testing de Automatización?
Si un software puede hacer cualquier cosa entonces, ¿por qué no puede un software probar un software?
¿Le suena lógica esta afirmación?
Si es así, enhorabuena, ahora estás pensando en la Automatización de Pruebas, que es el punto central que vamos a tratar en esta serie de tutoriales informativos.
Imagínate n el primer día en tu trabajo como SQA. Se te presenta una aplicación para ser probada. Es una aplicación ERP que contiene 100s de formularios y miles de informes. Comienzas tus pruebas exploratorias abriendo un formulario que contiene alrededor de 50 campos diferentes.
Intentas introducir datos al azar en este formulario, lo que te lleva alrededor de 20 minutos. A continuación, pulsa enviar. ¡¡¡Wolla!!! Se muestra un mensaje de error que parece una excepción no manejada. Te pones muy contento. Anotas con orgullo los pasos y reportas el error en tu sistema de gestión de errores. Gran esfuerzo, te sientes muy confiado y lleno de energía. Continúas con las pruebas hasta el final del día y encuentras algunos errores más. «Increíble primer día», piensas.
Ahora llega el día siguiente, el desarrollador ha solucionado el problema y lanza una nueva versión de la compilación. Pruebas el mismo formulario con los mismos pasos y descubres que el fallo está solucionado. Lo marcas como solucionado. Gran esfuerzo. Has contribuido a la calidad del producto identificando ese fallo y como este fallo está corregido, la calidad ha mejorado.
Ahora llega el tercer día, un desarrollador ha vuelto a publicar una versión más nueva. Ahora de nuevo tienes que probar ese formulario para asegurarte de que no se encuentra ningún problema de regresión. Los mismos 20 minutos. Ahora te sientes un poco aburrido.
Ahora imagina que dentro de 1 mes, las nuevas versiones se liberan constantemente y en cada lanzamiento, tienes que probar este largo formulario más 100 de otros formularios como este, sólo para asegurarse de que no hay regresión.
Ahora te sientes enojado. Te sientes cansado. Empiezas a saltarte pasos. Rellenas alrededor del 50% del total de los campos. Tu precisión no es la misma, tu energía no es la misma y definitivamente, tus pasos no son los mismos.
Y un día, el cliente te reporta el mismo error en el mismo formulario. Te sientes patético. Ahora te sientes sin confianza. Crees que no eres lo suficientemente competente. Los gerentes están cuestionando tu capacidad.
Tengo una noticia para ti; esta es la historia del 90% de los probadores manuales que hay. Tú no eres diferente.
Los problemas de regresión son los más dolorosos. Nosotros somos humanos. Y no podemos hacer lo mismo con la misma energía, velocidad y precisión todos los días. Esto es lo que hacen las máquinas. Para eso se necesita la automatización, para repetir los mismos pasos con la misma velocidad, precisión y energía con la que se repitieron la primera vez.
¡Espero que me entiendas!!!
Cuando se presente una situación así, debes automatizar tu caso de prueba. La automatización de pruebas es tu amiga. Te ayudará a centrarte en la nueva funcionalidad mientras te ocupas de las regresiones. Con la automatización, puedes rellenar ese formulario en menos de 3 minutos.
El script rellenará todos los campos y te dirá el resultado junto con capturas de pantalla. En caso de fallo, puede señalar el lugar donde el caso de prueba falló, ayudándole así a reproducirlo con facilidad.
Automatización – Un método rentable para las pruebas de regresión
Los costes de automatización son realmente más altos inicialmente. Incluye el coste de la herramienta, luego el coste del recurso de pruebas de automatización y su formación.
Pero cuando los scripts están listos, pueden ser ejecutados cientos de veces repetidamente con la misma precisión y con bastante rapidez. Esto ahorrará muchas horas de pruebas manuales. Así que el costo disminuye gradualmente, y en última instancia se convierte en un método rentable para las pruebas de regresión.
Escenarios que requieren automatización
El escenario anterior no es el único caso en el que necesitará pruebas de automatización. Hay varias situaciones, que no se pueden probar manualmente.
Por ejemplo,
- Comparar dos imágenes píxel a píxel.
- Comparar dos hojas de cálculo que contienen miles de filas y columnas.
- Probar una aplicación bajo la carga de 100.000 usuarios.
- Benchmarks de rendimiento.
- Probar la aplicación en diferentes navegadores y en diferentes sistemas operativos en paralelo.
Estas situaciones requieren y deben ser, probadas por herramientas.
Entonces, ¿cuándo automatizar?
Esta es una era de metodología ágil en el SDLC, donde el desarrollo y las pruebas irán casi en paralelo y es muy difícil decidir cuándo automatizar.
Considera las siguientes situaciones antes de dar el paso a la automatización
- El producto puede estar en sus etapas primitivas, cuando el producto ni siquiera tiene una UI, en estas etapas debemos tener claro qué queremos automatizar. Hay que recordar los siguientes puntos.
- Las pruebas no deben ser obsoletas.
- A medida que el producto evoluciona debe ser fácil recoger los scripts y añadirlos.
- Es muy importante no dejarse llevar y asegurarse de que los scripts son fáciles de depurar.
- No intente la automatización de la UI en las etapas iniciales ya que la UI está sujeta a cambios frecuentes, lo que hará que los scripts fallen. En la medida de lo posible opte por la automatización a nivel de API/no de UI hasta que el producto se estabilice. La automatización de la API es fácil de arreglar y depurar.
- Reducir el esfuerzo de prueba.
- Encontrar Bugs en etapas anteriores.
- Inicio de sesión del usuario.
- Búsqueda y selección de artículos.
- Opción de pago – esto cubre las pruebas del extremo frontal.
- Gestión de pedidos de backend (implica la comunicación con múltiples socios integrados, la comprobación de las existencias, el envío de correos electrónicos al usuario, etc.) – esto ayudará a la integración de pruebas de las piezas individuales y también el quid del producto.
Cómo decidir los mejores casos de automatización:
La automatización es una parte integral de un ciclo de pruebas y es muy importante decidir qué queremos conseguir con la automatización antes de decidirnos a automatizar.
Los beneficios que parece proporcionar la automatización son muy atractivos, pero al mismo tiempo, una suite de automatización mal organizada puede estropear todo el juego. Los testers pueden acabar depurando y arreglando los scripts la mayor parte del tiempo, lo que se traduce en una pérdida de tiempo de pruebas.
Esta serie te explica cómo se puede hacer una suite de automatización lo suficientemente eficiente como para recoger los casos de pruebas correctos y producir los resultados adecuados con los scripts de automatización que tenemos.
También he cubierto las respuestas a preguntas como Cuándo automatizar, Qué automatizar, Qué no automatizar y Cómo hacer una estrategia de automatización.
Pruebas correctas para la automatización
La mejor manera de abordar este problema es llegar rápidamente a una «Estrategia de automatización» que se adapte a nuestro producto.
La idea es agrupar los casos de prueba para que cada grupo nos dé un tipo de resultado diferente. La Ilustración dada a continuación muestra cómo podríamos agrupar nuestros casos de prueba similares, dependiendo del producto/solución que estemos probando.
Ahora vamos a profundizar y entender lo que cada grupo nos puede ayudar a conseguir:
#1) Hacer una suite de pruebas de toda la funcionalidad básica Pruebas positivas. Esta suite debe ser automatizada, y cuando esta suite se ejecuta contra cualquier build, los resultados se muestran inmediatamente. Cualquier script que falle en esta suite conduce a un defecto S1 o S2, y esa build específica puede ser descalificada. Así que hemos ahorrado mucho tiempo aquí.
Como un paso adicional, podemos añadir esta suite de pruebas automatizadas como parte de BVT (pruebas de verificación de la construcción) y comprobar los scripts de automatización de QA en el proceso de construcción del producto. Así que cuando la construcción está lista los probadores pueden comprobar los resultados de las pruebas de automatización, y decidir si la construcción es adecuada o no para la instalación y el proceso de prueba adicional.
Esto logra claramente los objetivos de la automatización que son:
#2) A continuación, tenemos un grupo de pruebas End to End.
En soluciones grandes, probar una funcionalidad end to end tiene la clave, especialmente durante las etapas críticas del proyecto. Deberíamos tener unos cuantos scripts de automatización que toquen las pruebas de la solución de extremo a extremo también. Cuando se ejecuta esta suite, el resultado debe indicar si el producto en su conjunto funciona como se espera o no.
La suite de pruebas de automatización debe indicar si alguna de las piezas de integración está rota. Esta suite no necesita cubrir todas y cada una de las pequeñas características/funcionalidades de la solución, sino que debe cubrir el funcionamiento del producto en su conjunto. Cada vez que tenemos una alfa o una beta o cualquier otra versión intermedia, entonces estos scripts son útiles y dan un cierto nivel de confianza al cliente.
Para entender mejor vamos a suponer que estamos probando un portal de compras en línea, como parte de las pruebas de extremo a extremo debemos cubrir sólo los pasos clave involucrados.
Como se indica a continuación:
Así que cuando se ejecuta un script de este tipo da una confianza de que la solución en su conjunto está funcionando bien.
#3) El tercer conjunto son las pruebas basadas en características/funcionalidades.
Por ejemplo, podemos tener la funcionalidad de examinar y seleccionar un archivo, así que cuando automatizamos esto podemos automatizar casos para incluir la selección de diferentes tipos de archivos, tamaños de archivos, etc, de modo que se hace la prueba de características. Cuando haya algún cambio/adición a esa funcionalidad esta suite puede servir como suite de Regresión.
#4) Lo siguiente en la lista serían las pruebas basadas en la UI. Podemos tener otra suite que pruebe las funcionalidades basadas puramente en la interfaz de usuario, como la paginación, la limitación de caracteres del cuadro de texto, el botón de calendario, los desplegables, los gráficos, las imágenes y muchas otras características centradas en la interfaz de usuario. El fallo de estos scripts no suele ser muy crítico a no ser que la UI esté completamente caída o que ciertas páginas no aparezcan como se espera!
#5) Podemos tener otro conjunto de pruebas que sean sencillas pero muy laboriosas de realizar manualmente. Las pruebas tediosas pero sencillas son las candidatas ideales para la automatización, por ejemplo introducir los detalles de 1000 clientes en la base de datos tiene una funcionalidad sencilla pero extremadamente tediosa para ser llevada a cabo manualmente, dichas pruebas deberían ser automatizadas. Si no, la mayoría de las veces terminan siendo ignoradas y no probadas.
¿Qué NO automatizar?
A continuación se presentan algunas pruebas que no deben ser automatizadas.
#1) Pruebas negativas/pruebas de recuperación de fallos
No deberíamos intentar automatizar las pruebas negativas o de recuperación de fallos, ya que para estas pruebas los probadores necesitan pensar de forma analítica y las pruebas negativas no son realmente sencillas para dar un resultado de aprobado o suspenso que pueda ayudarnos.
Las pruebas negativas necesitarán mucha intervención manual para simular un escenario real de recuperación de desastres. Sólo para ejemplificar estamos probando características como la fiabilidad de los servicios web – para generalizarlo aquí el objetivo principal de tales pruebas sería causar fallos deliberados y ver lo bien que el producto se las arregla para ser fiable.
Simular los fallos anteriores no son sencillos, puede implicar la inyección de algunos stubs o utilizar algunas herramientas en el medio y la automatización no es la mejor manera de ir aquí.
#2) Pruebas ad hoc
Estas pruebas pueden no ser realmente relevantes para un producto en todo momento y esto puede ser incluso algo que el probador podría pensar en esa etapa de inicio del proyecto, y también el esfuerzo para automatizar una prueba ad hoc tiene que ser validado contra la criticidad de la característica que las pruebas tocan.
Por ejemplo, un probador que está probando una característica que se ocupa de la compresión / encriptación de datos podría haber hecho intensas pruebas ad-hoc con la variedad de datos, tipos de archivo, tamaños de archivo, datos corruptos, una combinación de datos, utilizando diferentes algoritmos, a través de varias plataformas, etc.
Cuando planificamos la automatización es posible que queramos priorizar y no hacer una automatización exhaustiva de todas las pruebas ad hoc sólo para esa característica, y terminar con un poco de tiempo para la automatización de las otras características clave.
#3) Pruebas con preconfiguración masiva
Hay pruebas que requieren unos enormes requisitos previos.
Por ejemplo, podemos tener un producto que se integra con un software de 3ª parte para algunas de las funciones, como el producto se integra con cualquier sistema de colas de mensajería que requiere instalación en un sistema, configuración de colas, creación de colas, etc.
El software de terceros puede ser cualquier cosa y la configuración puede ser compleja en la naturaleza y si tales secuencias de comandos están automatizados, entonces estos serán siempre dependientes de la función / configuración de ese software de terceros.
Los requisitos previos incluyen:
En la actualidad, las cosas pueden parecer simples y limpias, ya que ambas configuraciones laterales se están haciendo y todo está bien. Hemos visto en numerosas ocasiones que cuando un proyecto entra en la fase de mantenimiento el proyecto se traslada a otro equipo, y terminan depurando dichos scripts donde la prueba real es muy simple pero el script falla debido a un problema de software de terceros.
Lo anterior es sólo un ejemplo, en general, ten cuidado con las pruebas que tienen preconfiguraciones laboriosas para una prueba simple que sigue.
Ejemplo sencillo de automatización de pruebas
Cuando estás probando un software (en la web o en el escritorio), normalmente utilizas un ratón y un teclado para realizar tus pasos. La herramienta de automatización imita esos mismos pasos utilizando scripts o un lenguaje de programación.
Por ejemplo, si estás probando una calculadora y el caso de prueba es que tienes que sumar dos números y ver el resultado. The script will perform the same steps by making use of your mouse and keyboard.
The example is shown below.
Manual Test Case Steps:
- Launch Calculator
- Press 2
- Press +
- Press 3
- Press =
- The screen should display 5.
- Close Calculator.
Automation Script:
//the example is written in MS Coded UI using c# language.public void TestCalculator(){//launch the applicationvar app = ApplicationUnderTest.Launch("C:\\Windows\\System32\\calc.exe");//do all the operationsMouse.Click(button2);Mouse.Click(buttonAdd);Mouse.Click(button3);Mouse.Click(buttonEqual);//evaluate the resultsAssert.AreEqual("5", txtResult.DisplayText,”Calculator is not showing 5);//close the applicationapp.Close();}
The above script is just a duplication of your manual steps. The script is easy to create and easy to understand as well.
What are Assertions?
The second last line of the script needs some more explanation.
Assert.AreEqual(«5», txtResult.DisplayText,»Calculator is not showing 5);
In every test case, we have some expected or predicted result at the end. In the above script, we have an expectation that «5» should be shown on the screen. The actual outcome is the result that is displayed on the screen. En cada caso de prueba, comparamos el resultado esperado con el resultado real.
Lo mismo ocurre con las pruebas de automatización también. La única diferencia aquí es que, cuando hacemos esa comparación en la automatización de pruebas, entonces se llama de otra manera en cada herramienta.
Algunas herramientas lo llaman como «Aserción», otras lo llaman como «punto de control» y otras lo llaman como «validación». Pero básicamente se trata de una comparación. Si esta comparación falla, por ejemplo, una pantalla está mostrando 15 en lugar de 5, entonces esta aserción/punto de control/validación falla y su caso de prueba se marca como fallido.
Cuando un caso de prueba está fallando debido a una aserción, entonces eso significa que ha detectado un error a través de la automatización de pruebas. Debe informar de ello a su sistema de gestión de errores al igual que lo hace normalmente en las pruebas manuales.
En el script anterior, hemos realizado una aserción en la penúltima línea. 5 es el resultado esperado, txtResultado. DisplayText es el resultado real y si no son iguales, se nos mostrará un mensaje de que «La calculadora no muestra 5».
Conclusión
A menudo los testers se encuentran con plazos de proyectos y mandatos para automatizar todos los casos para mejorar las estimaciones de las pruebas.
Hay algunas percepciones «erróneas» comunes sobre la automatización.
Son:
- Podemos automatizar todos los casos de prueba.
- La automatización de las pruebas reducirá enormemente el tiempo de prueba.
- No se introducen errores si los scripts de automatización se ejecutan sin problemas.
- Es la prueba que se realiza de forma programada.
- Utiliza la herramienta para controlar la ejecución de las pruebas.
- Compara los resultados esperados con los resultados reales (Aserciones).
- Puede automatizar algunas tareas repetitivas pero necesarias (Ej. Sus casos de prueba de regresión).
- Puede automatizar algunas tareas que son difíciles de hacer manualmente (Ej.g. Escenarios de pruebas de carga).
- Los scripts pueden ejecutarse rápida y repetidamente.
- Es rentable a largo plazo.
Deberíamos tener claro que la automatización puede reducir el tiempo de prueba sólo para ciertos tipos de pruebas. Automatizar todas las pruebas sin ningún plan o secuencia conducirá a scripts masivos que suponen un gran mantenimiento, fallan a menudo y necesitan también mucha intervención manual. Además, en productos en constante evolución los scripts de automatización pueden quedar obsoletos y necesitar algunas comprobaciones constantes.
Agrupar y automatizar los candidatos adecuados ahorrará mucho tiempo y dará todos los beneficios de la automatización.
Este excelente tutorial se puede resumir en sólo 7 puntos.
Pruebas de automatización:
Aquí, la Automatización se explica en términos simples, pero eso no significa que sea siempre simple de hacer. Hay desafíos, riesgos y muchos otros obstáculos involucrados en ella. Hay numerosas formas por las que la automatización de pruebas puede ir mal, pero si todo va bien, entonces los beneficios de la automatización de pruebas son realmente enormes.
Los próximos en esta serie:
En nuestros próximos tutoriales, vamos a discutir varios aspectos relacionados con la automatización.
Estos incluyen:
- Tipos de pruebas automatizadas y algunos conceptos erróneos.
- Cómo introducir la automatización en tu organización y cómo evitar los errores más comunes al realizar la automatización de pruebas.
- El proceso de selección de herramientas y comparación de varias herramientas de automatización.
- Desarrollo de scripts y marcos de automatización con ejemplos.
- Ejecución e informes de automatización de pruebas.
- Mejores prácticas y estrategias de automatización de pruebas.
.