X
BLOG

Preguntas y respuestas con Max Saperstone de Coveros: segunda parte: creación de una estrategia de prueba

Preguntas y respuestas con Max Saperstone de Coveros: segunda parte: creación de una estrategia de prueba Tiempo de leer: 8 minutos

En esta segunda parte de mi conversación (la primera es aquí) con Max Saperstone, Director de Automatización de Pruebas en Coveros, echamos un vistazo a cómo construir una estrategia de prueba eficaz y sus pensamientos sobre las herramientas comerciales de automatización de pruebas.

Max ha encontrado la misma situación en sus clientes que nosotros aquí en Parasoft. Muchas organizaciones enfrentan desafíos con las pruebas y cómo asignan recursos a cada fase de las pruebas. Max continúa con una discusión sobre su visión de las herramientas comerciales con una discusión adicional sobre las pruebas sin código.

Estrategia de prueba y la pirámide de prueba

Mark Lambert: Tener una estrategia de prueba de API en su lugar significa que puede encontrar problemas muy temprano en el proceso y aislarlos muy temprano es obviamente hacia lo que se está moviendo la industria. Pero cuando hablo con la gente, describen su estrategia de prueba como más como un cono de helado o una pirámide invertida. ¿Es eso lo que ves también? Y si es así, ¿cuáles son los desafíos que ve que enfrentan los equipos de software con ese tipo de situación de cono de helado?

Max Saperstone: He visto todo tipo de variaciones en la pirámide invertida. Algunos son casi un reloj de arena, donde hay mucha actividad en la parte inferior y mucha en la parte superior, y realmente no mucha en el medio.

Realmente el problema se reduce a los costos y la velocidad y, honestamente, la velocidad también influye en los costos. Las pruebas unitarias son baratas de ejecutar y deben ejecutarse en cuestión de segundos. Estas pruebas unitarias realmente deberían constituir la base de su pirámide. Deben ser relativamente baratos de crear y relativamente baratos de mantener. Si no son ninguna de esas cosas, rápidas y fáciles de mantener, etc., entonces no son realmente pruebas unitarias o simplemente estás haciendo un mal trabajo con ellas.

Mucho de lo que hago es trabajar junto con los desarrolladores, evaluadores y analistas de requisitos. Necesito entender lo que realmente se necesita para ser evaluado en diferentes áreas, y que todos estén en la misma página. Por ejemplo, cuando estás probando una base de datos, ya no es una prueba unitaria, eso es realmente una prueba de componentes. Veo equipos que tienen un montón de pruebas unitarias pero con muchas pruebas de integración mezcladas también. El aislamiento deficiente y las pruebas unitarias complejas ralentizan el proceso de prueba unitaria.

La razón por la que desea que las pruebas unitarias sean rápidas es para obtener comentarios rápidamente, incluso antes de que se compile el código. Desea asegurarse de que el código haga al menos lo que el desarrollador quiere. Porque si no está haciendo lo que el desarrollador quiere, no hay razón para seguir adelante.

Las pruebas funcionales, generalmente en forma de pruebas de IU, son inherentemente frágiles. Son más difíciles de mantener. Entonces, ¿por qué un equipo querría más de ellos? Entro en diferentes organizaciones y dicen: "Bueno, la automatización no nos está funcionando". Y yo digo: “Está bien. Bueno, veamos tus pruebas ". Lo que encuentro es una combinación de tres cosas: tienen demasiadas pruebas de IU, son demasiado difíciles de mantener y están mal escritas. Les digo que pueden reducir la cantidad de pruebas de IU debido a todas estas otras capas de pruebas (unidad y componente) que las respaldan y cuando las mejoran, puedo ayudarlas a escribir mejores pruebas funcionales en comparación con las que tienen hoy.

Mark Lambert: Mencionaste algo a lo que quiero volver, porque he estado viendo este problema desde que me uní a Parasoft, hace 15 años. Cuando alguien dice: "Sí, estoy haciendo pruebas unitarias", pero cuando entras allí, en realidad no están haciendo pruebas unitarias, en realidad están más arriba en la pirámide. Como dijiste, el simple hecho de usar un marco de pruebas unitarias no significa necesariamente que estén haciendo pruebas unitarias. ¿Por qué crees que es? ¿Cuál es el desafío para alguien para crear una prueba unitaria correcta o real?

Max Saperstone: Definitivamente este no es un incidente aislado que haya visto en uno o dos lugares. Honestamente, es difícil escribir una buena prueba unitaria, a diferencia de una prueba de integración o del sistema. Si quieres hacer buenas pruebas unitarias, tienes que burlarte de todo de lo que depende la unidad.

Escribir simulacros no es fácil. Requiere más trabajo; requiere más bibliotecas. Los desarrolladores realmente luchan con esto; es posible que no sepan cómo hacerlo o que no tengan tiempo para hacerlo. Por esas razones, pueden decidir tomar un atajo para conectar rápidamente una base de datos, por ejemplo, para lo que se pretende que sea una solución a corto plazo. Una semana después, todos los demás están usando el mismo código y es demasiado tarde para cambiarlo. La respuesta a esto cuando señalo estos problemas es “Bueno, estamos escribiendo pruebas. Eso es mejor que nada ". Y lo es, pero estos equipos rápidamente llegan a este punto donde sus pruebas no son tan efectivas como podrían ser.

En realidad, no creo que sea ignorancia en su mayor parte. Realmente creo que en la mayoría de los casos, es una crisis de tiempo. Cuando se trata de eso, y veo esto en cada organización, la gerencia se preocupa mucho más por sacar el producto por la puerta, que por hacer las cosas bien, inicialmente. Entonces, estos equipos acumulan deuda técnica y, a corto plazo, no hay problema con eso. Sin embargo, el problema real radica en el hecho de que cuando no regresan y reducen la deuda, cuando van a refactorizar el código o cambian algo, estas "pruebas unitarias" complejas y no aisladas se vuelven cada vez más frágiles, y más cosas. empezar a romper. Aunque inicialmente tenían buenas intenciones, esta acumulación de pruebas deficientes y deudas técnicas causa los problemas que veo.

Herramientas de automatización de pruebas

Mark Lambert: A medida que ayuda a los clientes a implementar su estrategia de prueba y determina dónde se aplicará la automatización, deben tomar algunas decisiones tecnológicas. Por ejemplo, ¿deben decidir si van a utilizar soluciones comerciales o de código abierto? ¿O simplemente construyen su propio marco? ¿Dónde recomiendas que inicien el proceso de toma de decisiones?

Max Saperstone: Esa es una gran pregunta, Mark. Y esa es una de las preguntas que más me hacen: ¿Qué herramienta debo usar? ¿Qué marco debo utilizar? Por lo general, el cliente está a punto de comenzar a realizar la automatización o comenzar a realizar pruebas de API. Desafortunadamente, la respuesta que siempre doy es, "Oh, no lo sé", porque no me gusta el primer enfoque de la herramienta.

Me gusta mucho que mis clientes den un paso atrás y piensen cuáles son sus requisitos. ¿Qué están mirando desde el análisis de los resultados de las pruebas y la perspectiva de la trazabilidad? ¿Qué es lo que están tratando de lograr? ¿Qué niveles de la pirámide de prueba quieren que respalden las herramientas? ¿Es solo una prueba en la interfaz de usuario, API, pruebas unitarias? ¿Cuál es la estrategia general de prueba?

Una vez que tenga todas esas preguntas respondidas. luego investigaré algunos de los marcos y herramientas que existen en el mercado y tomaré decisiones basadas en la investigación de los requisitos del cliente. Siempre sugiero ir primero con una herramienta de código abierto. Soy un gran admirador de intentar hacer las cosas de la forma más ágil posible, y gran parte de eso es la experimentación. A veces, como saben, el fracaso es parte de la experimentación. Puede encontrar la herramienta adecuada, y puede que funcione bien al principio, o puede que no. Si tiene que pagar dinero por estas herramientas, la experimentación puede resultar costosa y es posible que no obtenga lo que desea.

Después de experimentar con herramientas de código abierto, recomiendo a mis clientes que busquen herramientas comerciales que tengan períodos de prueba gratuitos para probar y comprobar las cosas. En este punto, les recomiendo que comiencen a analizar más las soluciones comerciales.

Al considerar las herramientas de código abierto, una de las cosas más importantes a considerar es el soporte. Existen diferentes marcos y herramientas de código abierto y el hecho de que sean gratuitos no significa que sean basura, pero tampoco significa que sean buenos. Por ejemplo, existía un estigma en torno a Selenium y la gente se preguntaba si una herramienta gratuita podía ser útil. Ahora hay una gran comunidad que contribuye a ello y es la herramienta de automatización número uno para las pruebas de interfaz de usuario a pesar de que puede seguir adelante y descargarla de forma gratuita.

Ser consciente del soporte que existe es importante para las herramientas de código abierto. También es una de las cosas clave que diferencia a los buenos proyectos de código abierto; el apoyo de la comunidad. Haces preguntas, la gente obtiene respuestas relativamente rápido. Selenium tiene una gran cantidad de personas dedicadas a responder preguntas allí. El apoyo de la comunidad como ese, ya sean herramientas de pago o gratuitas, es realmente importante.

Un peligro con las herramientas de código abierto es la posibilidad de quedarse atascado con un error o problema de uso y el proyecto se abandona, aunque esto también puede suceder con herramientas comerciales. Sin embargo, si no he hecho que mis pruebas sean portátiles, es un problema que he creado.

Todas estas diferentes herramientas y enfoques tienen ventajas y desventajas cuando las miras. Con el nivel apropiado de soporte y respaldo, para mí, eso siempre hace que la comunidad de código abierto sea un poco más valiosa.

Herramientas comerciales

Mark Lambert: Si existen dudas sobre la dependencia del proveedor, ¿está buscando una tecnología que pueda transferir fácilmente las pruebas entre diferentes marcos? En otras palabras, ¿es un aspecto crítico de la evaluación de soluciones comerciales la capacidad de moverse entre herramientas y asegurarse de que no está bloqueado en su plataforma?

Max Saperstone: Sí, realmente depende. Para muchos proveedores, el soporte de intercambiabilidad es algo bueno y para algunas herramientas funciona realmente bien. Sin embargo, cuando inicialmente está haciendo la primera experimentación, no necesariamente quiere comenzar con herramientas comerciales. Es doloroso si tengo que reescribir seis conjuntos de pruebas diferentes solo para probar seis piezas de software diferentes.

Mark Lambert: Entonces, primero abre el código hasta que chocas contra una pared, luego busca algo que pueda ayudarte a ir más allá de esa pared, ¿quizás?

Max Saperstone: Probablemente. Hay muchas soluciones diferentes que tienen una versión gratuita o un modelo "freemium", en el que se paga por funciones adicionales. También hay versiones pagas además de eso. Muchas de estas herramientas me gustan mucho, porque una vez que las examino, me doy cuenta de que puedo hacer todas estas cosas interesantes. Para mí, muchas veces vale la pena porque si la herramienta tiene todas las características correctas y puedo hacer mucho de mi desarrollo de antemano, solo necesito una o dos licencias para ejecutar las herramientas durante las compilaciones. Eso no es tan malo.

De nuevo, también depende del nivel técnico del equipo. Lo bueno de los productos pagos es que, por lo general, tienen soporte listo para ti. si el equipo no es tan competente técnicamente con las herramientas de prueba y necesita más soporte, está disponible. Cuando se trata de los productos de Parasoft, el soporte es una de las cosas por las que los clientes están pagando, lo que tiene mucho sentido estratégicamente.

Pruebas sin código

Mark Lambert: Dirigiéndose a su comentario sobre usuarios no técnicos, por ejemplo, alguien que no se sienta cómodo con la codificación de Selenium, ¿las herramientas de prueba sin código serían una solución? ¿Qué significa esa prueba sin código para usted? ¿Cuáles son tus pensamientos?

Max Saperstone: He estado viendo herramientas de automatización de pruebas sin código durante unos cinco años en este momento. Pienso en la primera vez que me enteré de que eran muy hábiles. Me gusta que puedan hacer muchas cosas relativamente simples y algunas de ellas van más allá del aspecto sin código. Algunas herramientas le permiten sumergirse cuando sea necesario y comenzar a escribir cosas en Java o Python, por ejemplo. Tener la capacidad de realizar pruebas sin código y la capacidad de agregar código cuando sea necesario es importante cuando tiene los equipos menos técnicos.

En mi opinión, cada tipo de herramienta tiene un costo. Tienes que pagar más por las personas que tienen experiencia en codificación y menos dinero por probadores menos técnicos. Sin embargo, esto podría compensarse con la tecnología y pagar un poco más por el soporte del proveedor. Entonces, creo que las pruebas sin código realmente ofrecen una gran solución para eso.

El gran desafío que veo es que hay muchos jugadores diferentes en este espacio. Realmente no he visto a un proveedor adelantarse a otro. Los proveedores parecen tener todavía un pequeño punto de apoyo. Si bien esto significa que definitivamente hay un mercado en crecimiento para las herramientas de automatización de pruebas, es posible que estas herramientas no resuelvan los principales problemas que tenemos en el espacio de la automatización de pruebas.

Mencioné anteriormente que había dos cosas que normalmente veo como problemas: los equipos pasan demasiado tiempo manteniendo sus pruebas porque son frágiles y se rompen. La otra es que la gente está escribiendo malas pruebas. Estos han sido los que veo como los principales puntos débiles de la automatización de pruebas en general. No creo que la automatización sin código realmente aborde estos problemas. Hacen que sea mucho más fácil escribir pruebas, pero no creo que ese sea el problema más común. Estas herramientas facilitan la redacción de la misma prueba incorrecta, potencialmente.

Muchos de estos problemas y la falta de éxito con la automatización se remontan a la falta de una estrategia de prueba. Creo que las herramientas y la automatización aún no han explotado realmente, definitivamente están resolviendo problemas, pero no están resolviendo el mayor problema en el espacio.

En la próxima publicación, hablamos con Max sobre sus experiencias con fallas y éxitos en las pruebas y la automatización de pruebas.

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