X
BLOG

Preguntas y respuestas con Max Saperstone de Coveros: Tercera parte: éxito y fracaso con la automatización de pruebas

Preguntas y respuestas con Max Saperstone de Coveros: Tercera parte: éxito y fracaso con la automatización de pruebas Tiempo de leer: 5 minutos

En esta tercera parte de mi conversación (lea Primera parte y La segunda parte) con Max Saperstone, Director de Automatización de Pruebas en Coveros, discutimos los éxitos y fracasos que ha experimentado con la automatización de pruebas.

Max encontró una experiencia similar a la que vemos en el mercado: una planificación deficiente y la falta de aceptación en todos los niveles no es un buen entorno para el éxito. Sin embargo, cuando el ROI de la automatización está bien articulado, es más probable que tenga éxito. Echemos un vistazo a las experiencias de Max en esta área.

Automatización de pruebas: éxito y fracaso

Mark Lambert: Terminemos esta discusión con dos últimas preguntas. La primera pregunta es, dame un ejemplo en el que ingresaste a una organización para ayudarlos con la automatización de pruebas y fue un éxito. ¿Cuál fue la razón por la que salió bien y algo que abrió los ojos en un momento de bombilla?

Max Saperstone: Interesante pregunta. Uno de los ejemplos que se me viene a la mente es cuando fui a una organización que estaba haciendo un montón de pruebas manuales. Mucho de lo que realmente probaron fue ingresar datos y hacer validación de formularios. Su desafío era pasar semanas probando su sistema debido a la complejidad y las diferentes combinaciones de entradas necesarias para probar la aplicación. Incluso sabían que no estaban cubriendo todo.

Nos sentamos con ellos y hablamos de requisitos y todo lo que buscaban. Dijeron: “¿Sabes qué? Honestamente, no lo sabemos ". Parte de lo que estábamos haciendo era ingresar manualmente los códigos postales y la aplicación informaba a los diferentes usuarios. Para cada usuario que se devolvió, necesitaban hacer otra consulta para asegurarse de que la información fuera correcta.

Creamos y ejecutamos algunos guiones para ellos y lo que resultó fueron, creo, tres cuartos de millón de combinaciones diferentes. Se necesitaron aproximadamente ocho horas una noche para ejecutar todas estas pruebas. Miraron los datos y les preguntamos: “Está bien. Bueno, ¿qué hacemos con esto? " Dijeron: "No tenemos ni idea".

Sabíamos que todo esto estaba en su base de datos, pero no teníamos forma de probarlo. Entonces, alguien realmente se sentó con estos datos y probablemente les tomó más de un mes. Finalmente regresaron y dijeron: “Revisamos todo y analizamos todos estos datos. No todo es correcto ". Encontraron 30 o 40 discrepancias diferentes, pero el hecho de que nunca las hubieran detectado antes, esencialmente estaban haciendo un muestreo aleatorio.

Lo que pudimos hacer fue tomar ese conjunto de datos y, en lugar de programar esos resultados, los convertimos en pruebas. Todavía tardó toda la noche en ejecutarse, pero no pasaron semanas analizando resultados con mala cobertura. Estas nuevas pruebas verificaron que todos los resultados eran realmente correctos y que la organización pudo continuar agregando nuevos clientes a su base de datos con menos trabajo involucrado en probar los resultados.

No solo encontramos errores, esta nueva automatización hizo posible que el cliente realizara un seguimiento de todo. Para mí, fue un gran éxito. La combinación de la automatización y el esfuerzo manual inteligente liberó una gran cantidad de tiempo y esfuerzo. Además, otro éxito fue encontrar errores que tendrían absolutamente un impacto en los resultados de la empresa si terminaban en el producto final.

Mark Lambert: Entonces, ¿obtuvieron una cobertura de prueba completa al aprovechar un conjunto de datos completo? En lugar de tomar muestras al azar para tratar de encontrar defectos.

Max Saperstone: Bastante. Nuevamente, fue una cobertura completa de un área de la aplicación. Pero fue el uso de la automatización lo que fue genial de ver. Sin embargo, esta fue una empresa costosa y si un cliente realmente quiere que arrojemos todo lo que tenemos al problema, lo haremos. En este caso, fue un gran impulso para nuestro cliente y, al final, valió la pena, lo cual fue bueno.

Mark Lambert: Bien, última pregunta. ¿Qué tal un ejemplo en el que el proyecto salió totalmente mal? ¿Qué fue lo que provocó que esa implementación fallara? ¿Cuáles fueron las lecciones aprendidas?

Max Saperstone: Estaba trabajando con una empresa diferente en ese entonces y un cliente nos trajo y dijo: “Realmente necesitamos que automatice nuestras pruebas. Tenemos todos estos probadores manuales que pasan semanas haciendo sus pruebas de regresión. Lo que realmente necesitamos es automatizar estas pruebas y acelerar el tiempo de prueba ".

Esto fue hace un tiempo, e ingenuamente, dije: "Claro". Comencé a analizar el problema, a escribir algunas pruebas y a hablar con los evaluadores manuales para averiguar en qué dedicaban la mayor parte de su tiempo. Después de un mes o dos, tuve un conjunto decente de pruebas y se las entregué a los probadores.

Le dije: “Aquí tienes. Ya no tiene que ejecutar pruebas manuales. Estas pruebas automatizadas investigarán algunas de las áreas de la aplicación por usted ".

Lo que sucedió es que los evaluadores no estaban ejecutando estas pruebas automatizadas, o las ejecutarían, pero luego las volverían a ejecutar manualmente. Como aprendí, parte de la razón por la que no los estaban ejecutando era que a los probadores no les importaba ejecutarlos. No necesariamente confiaban en ellos. No vieron el valor que estaban obteniendo de la automatización. Además, la forma en que se construyeron las pruebas, no eran pruebas completas de extremo a extremo a las que los probadores estaban acostumbrados a ejecutar. Las pruebas ejercieron partes de la aplicación que necesitaban, pero los evaluadores aún tuvieron que ejecutar muchos otros pasos para obtener la cobertura necesaria.

Al final, dijeron: "Bueno, si voy a tener que ejecutar estas pruebas manuales, no estamos ahorrando tanto tiempo". El cliente simplemente no vio este valor que se les estaba agregando. Creo que el tema principal de este proyecto fue realmente la comunicación. Descubrimos en qué dedicaban la mayor parte del tiempo los probadores, pero no les hablamos sobre cómo probaron el software y qué les gustaría poder automatizar. Necesitábamos preguntarles: "Si pudieras hacer absolutamente cualquier cosa, ¿qué sería?"

Nos centramos demasiado en las mejores prácticas. El problema era que estas prácticas y las pruebas que automatizamos no encajaban en su flujo de trabajo de calidad general, que era lo que realmente necesitaban para poder aliviar parte del tiempo de control de calidad.

Creo que deberíamos haber hablado de más estrategias de alto nivel y tener una mejor idea de lo que podríamos haber hecho para reducir de inmediato el número de pruebas manuales. Deberíamos haber preguntado qué podíamos hacer para que los probadores realmente se entusiasmaran con intentar usarlo. O incluso, ¿qué creen que tiene sentido automatizar y con qué tecnología se sentían cómodos?

Resultó que algunos de los probadores ni siquiera querían hacer clic en "Ir" en su máquina para ejecutar una prueba automatizada. Sin embargo, otros se sentían cómodos con la automatización y recibían un informe por correo electrónico todas las mañanas que decía: "Esto se ejecutó, esto se hizo". Desafortunadamente, estas discusiones no se tuvieron al principio.

Entonces, volvimos y reiteramos este proyecto. Pero definitivamente hubo un gran esfuerzo por adelantado que podría haberse ahorrado con más discusiones sobre esta estrategia de prueba de alto nivel. Y eso se remonta a ese primer comentario del que hablábamos.

Mark Lambert: Entonces, sin planificación, sin la participación de los equipos, no hay confianza ni valor percibido. Saltar a ciegas a la automatización de pruebas realmente no ayudó.

Max Saperstone: Exactamente. Se trataba de realizar la automatización de pruebas por el bien de la automatización de las pruebas en lugar de determinar realmente cuál es el valor real y cómo podemos aprovecharlo al máximo.

Mark Lambert: Genial. Bueno, muchas gracias, Max. Realmente aprecio el tiempo con esto. Creo que esta fue una gran discusió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