Las pruebas no funcionales y las pruebas de rendimiento no se pueden desplazar más a la izquierda

Un BrainBlog de Intellyx para Parasoft por Jason English

¿Alguna vez has tenido un amigo que sufriera TOC por la blancura de sus dientes? ¿Van a un dentista cosmético para un blanqueamiento con láser y luego se quejan de que no es lo suficientemente blanco? Con el tiempo, alcanzan un punto asintótico en el que la superficie del diente no puede reflejar el 99.9 % de la luz, por lo que obtener un tratamiento que produzca un 99.999 % de dientes blancos sería demasiado costoso e imposible.

Los ingenieros de pruebas, los evaluadores de rendimiento y los SRE están obsesionados con lograr un nivel de confiabilidad de cinco nueves (o, a veces, incluso más alto) en la última milla de la entrega de software, donde más impacta a los clientes.

Si usted también tiene TOC sobre la confiabilidad de la aplicación, ya hizo los cálculos y se dio cuenta de que 5 9 equivalen a aproximadamente 5.26 minutos de tiempo de inactividad por año, en total. Y también se da cuenta de que el costo de la ingeniería de pruebas y el esfuerzo de superar el 99.9% para garantizar un tiempo de actividad del 99.999% es monumental.

¡Obtener producción de 3 a 9 consumirá mucho más presupuesto de TI que llegar a 5 en la mayoría de los casos!

Parece que todas las pruebas de rendimiento de preproducción en el mundo nunca resolverán todas las condiciones desconocidas que podrían causar el 0.001% del tiempo de inactividad. No importa cuánto gastemos. ¡Fuera, maldito lugar!

Ah ... pero no nos preocupemos por esa única cosa que no puede mejorar, en el lado derecho de la entrega de software. No, no, no ... Los problemas cuestan mucho más resolver aquí, de todos modos, cuando la aplicación está completamente preparada. No puedo obsesionarme con eso.

Solo una pequeña llamarada. Nadie es perfecto. Relajarse.

Obtenga una nueva perspectiva con los primeros equipos de DevTest

¿Por qué no dejar la producción en paz por un tiempo y pasar el rato con los equipos de DevTest al comienzo del ciclo de vida del software?

Aquí, en el lado izquierdo de la entrega de software, están dibujando mapas, escribiendo código y seleccionando componentes. No es una preocupación en el mundo. Sin miedos sobre lo que incógnitas desconocidas podría suceder en el despliegue.

Están ejecutando un desarrollo ágil de prueba primero, y están ejecutando muchas verificaciones de código estructural con cada compilación, ejecutando unidades automatizadas y conjuntos de pruebas de regresión. Cambiaron a la izquierda en ese tipo de pruebas.

Tampoco están terriblemente preocupados por el impacto de las decisiones que están tomando. Cuando se integran diversos servicios, software y componentes de infraestructura detrás de una aplicación en funcionamiento, pueden generar una variedad infinita de problemas no funcionales cuando interactúan bajo carga.

Las primeras selecciones de diseño y desarrollo pueden proporcionar malas noticias más adelante, pero las pruebas no funcionales (NFT) y las pruebas de rendimiento tradicionalmente ocurren más cerca de la producción.

Espera, ¿y si pudieras llevar NFT al diseño y desarrollo? ¿Podría eso proporcionar una alerta temprana suficiente para evitar los errores más costosos?

Desplazamiento de NFT y PerfTest a la izquierda

Los problemas no funcionales son difíciles de detectar al principio del software porque las condiciones del mundo real son, por naturaleza, difíciles de reproducir en el laboratorio.

Puede ejecutar conjuntos de pruebas funcionales de Selenium en una interfaz de aplicación o un proceso de autorización de usuario, o ejecutar un conjunto de llamadas de prueba de servicio API y conjuntos de datos para verificar las respuestas, o ejecutar un montón de pruebas JUnit o NUnit en el código. Pero todos estos métodos solo pueden probar los problemas que espera encontrar en esta etapa temprana.

Para acercarse a las condiciones del mundo real, el equipo tiene tres opciones abiertas.

1. Inserte pruebas funcionales para la evaluación comparativa. Si inserta pruebas funcionales de Selenium en la canalización del software CI / CD y las automatiza con una herramienta complementaria como Parasoft Selenic para monitorear los tiempos de ejecución con cada compilación, puede capturar un punto de referencia bastante bueno para cualquier aplicación, componente o servicio.

Si hay alguna desviación en el tiempo de respuesta, por cualquier motivo, la compilación puede notificar a la plataforma de compilación o al desarrollador que alguna excepción (probablemente no funcional) provocó la ralentización de un componente en particular.

2. Reutilice las pruebas y repita bajo carga. ¿Por qué esperar hasta el final y usar herramientas como LoadRunner que requieren interfaces de usuario casi terminadas para invocar, habilidades de prueba especializadas y altos costos por puesto?

En cambio, ¿qué pasaría si realizara las pruebas de Selenium y algunas comprobaciones de seguridad y pruebas de servicio e integración de una herramienta como Prueba SOA de Parasoft, luego comenzó a ciclar y a volver a ejecutarlos, tal vez con alguna variabilidad de datos o tiempo, a frecuencias más altas? Obtendría una prueba de rendimiento en la etapa inicial de prueba de desplazamiento a la izquierda.

A partir de ahí, puede combinar diferentes combinaciones de estilo web, llamadas a la interfaz de usuario, llamadas que no son de la interfaz de usuario a las API o colas de eventos para una prueba de rendimiento híbrida que puede ejercitar múltiples capas del ecosistema de destino de la aplicación, sin esperar una aplicación finalizada.

3. Aislar frente a las dependencias ambientales. El último obstáculo para cambiar NFT a la izquierda es el entorno donde realmente viven las aplicaciones. Una aplicación moderna funciona en un mundo lleno de dependencias de datos y servicios.

Aquí es donde pruebas basadas en el entorno con una solución de virtualización de servicios tiene sentido instrumentar todas las dependencias ascendentes y descendentes en torno a la aplicación en vivo. Esto le permite simular cosas como el sistema de un socio bancario o un sistema meteorológico nacional o de tráfico aéreo que nunca estaría bajo su control o disponible para importar a su propio laboratorio de DevTest.

Las dependencias se pueden escuchar y capturar como servicios virtuales, componentes que pueden responder "mejor que lo real" en lo que respecta a las pruebas de software.

Un banco canadiense utilizó una combinación de las tres técnicas. Automatizaron las pruebas funcionales para capturar un punto de referencia para un componente de solicitud de préstamo, luego volvieron a ejecutar las pruebas con algunas otras pruebas para consultas de datos y llamadas API a un servicio de virtualización "simulacro" de un servicio de crédito de terceros.

Ellos estaban preocupados. Si el servicio de API virtual respondiera con demasiada lentitud, ¿qué pasaría con el componente bajo prueba? Respondió como se esperaba, pero luego el equipo de pruebas aceleró el servicio virtual de la respuesta de ese tercero en el menor tiempo posible. Surgió una “condición de carrera” que provocó que la transacción del componente fallara al obtener una respuesta que era demasiado rápida.

La toma Intellyx

En software, solo hay una definición de perfección, pero el fracaso es infinito.

No importa cuánto nos cepillemos, nunca tendremos dientes 100% blancos. No importa cuánto analicemos, nunca estaremos 100% libres de defectos que lleguen a la producción, donde los errores son difíciles de aislar y costosos de remediar.

Pero con una higiene adecuada de prueba que incluya pruebas no funcionales y de rendimiento, podemos obtener un sistema de alerta temprana que eliminará muchos de estos problemas incipientes antes de que tengan la oportunidad de surgir en el laboratorio de rendimiento o fallar frente a los clientes.

© 2020 Intellyx, LLC. Intellyx conserva el control editorial sobre el contenido de este documento. En el momento de escribir, parasoft es un cliente de Intellyx. Ninguno de los otros proveedores mencionados aquí son clientes de Intellyx. Fuentes de imagen: Steve Snodgrass, Kristopher Volkmann, juan reina, Gauthier DELECROIX - 郭 天, código abierto de flickr.

Por Jason Inglés

Jason English es Analista Principal y CMO en Intellyx, donde asesora a los principales proveedores de soluciones tecnológicas y a las nuevas empresas de software mientras navegan por la transformación digital. Su experiencia incluye experiencia del cliente y diseño interactivo, ciclo de vida de desarrollo / prueba de software empresarial, virtualización, nube y blockchain.