X
BLOG

Preguntas y respuestas con Max Saperstone de Coveros: Primera parte: Introducción a la automatización de pruebas

Preguntas y respuestas con Max Saperstone de Coveros: Primera parte: Introducción a la automatización de pruebas Tiempo de leer: 5 minutos

En este conjunto de tres publicaciones de blog, obtenemos una visión interna de cómo construir una estrategia de prueba efectiva y cómo usar la automatización de pruebas como parte de esa estrategia. Entrevisto a Max Saperstone, Director de Automatización de Pruebas en Coveros. Max es un ingeniero de pruebas experimentado con un enfoque en la automatización de pruebas dentro del proceso CI / CD. Él echa una mano a varios clientes para ayudarlos a poner en marcha sus esfuerzos de automatización y pruebas. Max también es un desarrollador ágil con experiencia y certificado y es buscado para participar en conferencias de desarrolladores ágiles y de pruebas. Tenemos la suerte de contar con la experiencia de Max en este momento para discutir temas cercanos a nuestros corazones aquí en Parasoft.

Esta es la primera parte de una serie de tres partes que analiza los pensamientos de Max sobre cómo comenzar con la automatización de pruebas. Una cosa está clara, a Max le gusta ayudar a sus clientes a dar un paso atrás y considerar el panorama general antes de sumergirse en la automatización de pruebas. Ayudar a sus clientes a responder preguntas importantes como "¿por qué estoy automatizando las pruebas?" para que puedan establecer metas claras para sus esfuerzos. También charlamos brevemente sobre las pruebas de API y Max parece estar en la misma página que nosotros: las pruebas de API son de suma importancia. Veamos lo que Max tiene que decir:

Introducción a la automatización de pruebas

Mark Lambert: Hola Max, es genial estar contigo de nuevo. Sé que su rol en Coveros consiste en ayudar y asistir a los clientes con estrategias efectivas de automatización de pruebas. ¿Puede decirnos cuál cree que es una estrategia de automatización de pruebas eficaz? ¿Dónde debería empezar un equipo?

Max Saperstone: Hola Mark, ¡es una gran pregunta! Es interesante porque, como saben, mi especialidad es la automatización y, a pesar de eso, cuando un equipo está comenzando, mi consejo suele ser: "No se sumerja en la automatización".

Realmente, el mejor lugar para comenzar es mirar el control de calidad como un todo. Entonces, lo primero que debe comprender es qué significa “calidad en su conjunto” para su proyecto y cómo lo va a verificar. Solo después de conocer la respuesta a esas preguntas, podrá realmente sumergirse en decidir qué automatizar y qué no quiere automatizar.

Para mí, este es siempre uno de los mayores desafíos. Veo que muchos equipos se lanzan para comenzar a escribir scripts de Selenium o scripts de QTP, y tienen un montón de "cosas". Pero, en última instancia, ¿cómo se utilizan esas cosas? ¿Cómo maneja los resultados de las pruebas? ¿Cómo decide cuándo enviar el producto?

Por lo general, mi recomendación es dar un paso atrás y averiguar qué necesita verificar y cómo hacerlo. Existe un método realmente genial llamado MSCW.

Mark Lambert: ¿Qué es el método MSCW?

Max Saperstone: El método MSCW es en realidad solo un acrónimo. Que es MSi automatiza, ¿qué S¿Deberías automatizar, qué C¿Debería automatizar y qué WNo lo automatices. La idea es realmente dedicar algo de tiempo y reflexión a su estrategia de automatización, para descubrir dónde está el mayor beneficio por su inversión.

Para mí, eso siempre se remonta al ROI. ¿Cuáles son las pruebas que se ejecutan de forma constante? ¿Cuáles son las áreas de gran valor de su aplicación en las que no puede permitir que nada salga mal? ¿Qué impactará más a los usuarios? Empiece con lo que siempre estará dentro de sus "deberes" y siempre estará dentro de sus "deberes".

Luego, ingresa a otras áreas de sus "posibilidades" y "deseos". Por ejemplo, probar la usabilidad es algo realmente difícil y difícil de automatizar: ¿cómo le dices a una máquina lo que se siente bien y lo que no?

Otra área que es difícil de automatizar son las integraciones de terceros. Por ejemplo, digamos que tiene una integración de FitBit, es posible que eventualmente pueda automatizarla. Pero eso llevará semanas o meses. ¿Realmente vale la pena esa cantidad de tiempo para automatizar eso?

Cuando estoy escribiendo una estrategia de prueba, dedico tiempo a averiguar mi plan de prueba a este alto nivel. ¿Cuáles son las áreas de la aplicación que realmente me importan? ¿Cuáles son las áreas que serán fáciles de automatizar? Normalmente empiezo con eso.

Mark Lambert: Entonces, ¿cómo organizas esto?

Max Saperstone: Por supuesto, esto realmente todavía está hablando desde un nivel funcional. Tan pronto como dé un paso atrás y considere su estrategia en términos de la pirámide de pruebas y los diferentes roles involucrados en la calidad, porque no se trata solo de probadores. Los desarrolladores deben escribir pruebas de unidad e integración en la parte inferior de la pirámide de pruebas. En cierto punto, los probadores toman el control, como la punta de un iceberg. Debajo de la superficie, desea asegurarse de que todo ese código se pruebe con pruebas unitarias; asegúrese de que el código haga lo que el desarrollador dice que debería hacer. La siguiente capa son las pruebas de integración, que aseguran que las diferentes partes de la aplicación realmente funcionen de la manera en que las otras partes creen que van a hacerlo. Finalmente, tienes a los probadores, se sientan en la parte superior del iceberg y realmente quieren asegurarse de que la aplicación en su conjunto haga lo que el cliente final realmente quiera.

Si no tiene esas dos partes subyacentes hechas correctamente, donde la automatización vale la pena y es rápida y fácil en estos niveles bajos, los errores en el nivel superior son difíciles de depurar y corregir. No tienes idea. “¿Es un problema funcional? ¿Es un problema de componentes? ¿O es un problema de código? " Pero si sabe que todas esas otras cosas funcionan correctamente, será muy fácil perseguir estos problemas.

Sin embargo, si sabe que todas las pruebas de unidad e integración han pasado, es más rápido diagnosticar las fallas como probables problemas funcionales. La situación opuesta, con una estrategia de automatización deficiente, es una lucha para identificar la causa raíz, mucha depuración. Una buena estrategia de automatización, triaging de problemas mucho más simple.

Prueba de API

Mark Lambert: Aquí en Parasoft, hemos estado hablando de las pruebas de API durante casi dos décadas, sin embargo, la adopción de las pruebas de API es todavía nueva para muchas personas. Esto puede deberse a la naturaleza oculta de las API, está en la capa entre la interfaz de usuario y el código y muchas personas no lo ven. ¿Cuál crees que es el camino a seguir? ¿Cómo aprovechan las organizaciones las pruebas de API de la forma más eficaz posible?

Max Saperstone: Esa es una gran pregunta. Me encantan las pruebas de API porque viniendo de un evaluador, que no necesariamente tiene acceso a todo el código, es una excelente manera de realizar muchas pruebas desde la perspectiva de una caja negra. El hecho de que no sepa lo que hace el código no significa que no tenga una buena visión de la API.

Con suerte, puedo ver qué entradas espera una API y qué resultados genera, ya sea que haya un documento WSDL o swagger asociado. Las pruebas de API me permiten realizar pruebas de una manera muy rápida porque se basan en datos en ese momento. Tengo un punto final, lanzo tantas combinaciones diferentes de entradas que creo que son válidas y verifico todas las diferentes salidas. Realmente no necesito saber mucho sobre código y hay un montón de marcos realmente buenos que manejan eso por mí.

Entonces, desde la perspectiva de un evaluador, esa es absolutamente la razón por la que me encantan las pruebas de API. Además, son rápidos y, por lo general, no frágiles. Si tiene una organización que establece contratos y tiene puntos finales bien definidos, que no se cambiarán con frecuencia, hay muy poco mantenimiento que se debe realizar en las pruebas de API y le brindan mucha información sobre el sistema.

Mark Lambert: Creo que lo que acaba de mencionar, acerca de que las pruebas de API son rápidas y estables, es realmente la razón por la que se han vuelto tan valiosas. Además, son un gran mecanismo de comunicación entre los probadores y los desarrolladores dentro de una organización.

Max Saperstone: Absolutamente. Por lo general, cuando hablo de pruebas de integración para organizaciones, las pruebas de API son una gran parte de ellas. Son rápidos, te brindan mucha información realmente valiosa y son mucho más estables que las pruebas de IU.

En la siguiente publicación, hablamos con Max sobre la construcción de una estrategia de prueba y su opinión sobre la pirámide de prueba.

Escuche más de Max Saperstone en nuestro Webinar sobre cómo ser más eficaz en la entrega de software de alta calidad con desarrollo impulsado por el comportamiento (BDD). Más información.

Escrito por

Mark Lambert

Mark, vicepresidente de productos de Parasoft, es responsable de garantizar que las soluciones de Parasoft brinden un valor real a las organizaciones que las adoptan. Mark ha estado con Parasoft desde 2004, trabajando con una amplia variedad de clientes de Global 2000, desde implementaciones de tecnología específicas hasta iniciativas de mejora de procesos SDLC más amplias.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft