¡La Cumbre ASTQ está en vivo el 4 de noviembre! Escuche a los líderes de la industria compartir cómo están brindando calidad continua. Regístrate ahora "

X
BLOG

¿Qué es la prueba Shift-Left?

¿Qué es la prueba Shift-Left? Tiempo de leer: 8 minutos
Cuanto antes se entere de los problemas en su código, menor impacto tendrán. También cuesta menos lidiar con ellos. En este blog, exploramos la metodología de cambio a la izquierda y cómo abordar el cambio a la izquierda en su organización.

La metodología de prueba Shift Left

El movimiento hacia el “desplazamiento a la izquierda” consiste en trasladar las prácticas de prueba críticas a una etapa más temprana del ciclo de vida del desarrollo. Este término se encuentra especialmente en iniciativas Agile, Continuous y DevOps. Entonces, ¿por qué necesita realizar las primeras pruebas de software?

Muchas actividades de prueba ocurren al final del ciclo, donde se tarda más en descubrir qué salió mal y cuesta más arreglarlo. Desplazarse a la izquierda se trata de cambiar la identificación y prevención de defectos a una etapa anterior. Cuando no lo hace, y espera para realizar prácticas de prueba más adelante en el ciclo de desarrollo, sus requisitos comerciales no funcionales en particular (es decir, pruebas de seguridad y rendimiento) están tan profundamente arraigados en su código que todo lo que realmente puede hacer es arreglarlos en lugar de arreglarlos correctamente.

¿Cuándo ingresan los errores en el código?

La estrategia de prueba de cambio a la izquierda está bien ilustrada en el gráfico algo famoso de Capers Jones, que muestra el costo creciente de errores / defectos que se introducen en el software, en cada fase del desarrollo del software. la mayoría de los errores aparecen durante la fase de codificación, lo cual es de esperar.

Ya sea que cometan errores reales, malinterpreten los requisitos o no piensen en las ramificaciones de un fragmento de código en particular, los desarrolladores introducen defectos a medida que se produce el código.

Los defectos también se introducen en la aplicación cuando llega el momento de unir las piezas, especialmente si hay varios equipos involucrados (y a medida que las arquitecturas modernas como los microservicios se vuelven más complejas).

Cuando son esos bichos encontrado?

Empieza a ponerse interesante cuando superponemos la línea que muestra dónde están los defectos encontradoen la parte superior del gráfico de errores que se están introduciendo.

Tenga en cuenta que es básicamente una inversa de la primera línea:

Por supuesto, esto no es sorprendente, porque normalmente encuentra errores cuando comienza a probar, y puede ser difícil sin una infraestructura adecuada comenzar a probar antes de que todo esté listo (más sobre esto más adelante). Lo que vemos aquí es que los errores se introducen principalmente durante la codificación, pero casi nunca se encuentra en esa fase.

Lo que lo hace el costo para corregir errores?

Debido a que la mayoría de los errores se introducen durante la codificación, pero no se descubren hasta una fase posterior, es importante comprender la diferencia que cuesta corregir los defectos en cada fase del desarrollo. Esto se representa a continuación:

Ahora comienza a ponerse realmente interesante, ya que vemos una desagradable progresión del costo que aumenta drásticamente cuanto más tarde se encuentra el defecto. Dejar que un error se filtre en las pruebas del sistema es 40 veces más costoso que encontrarlo durante la codificación, o 10 veces más costoso que encontrar el mismo error durante la prueba unitaria. Y se vuelve ridículamente caro cuando se mira la cantidad de errores que dejan pasar a la implementación real.

Hay razones para esta escalada de costos, que incluyen:

  • El tiempo y el esfuerzo necesarios para localizar el problema. Cuanto más complejo (más grande) es el caso de prueba, más difícil es averiguar qué parte es el verdadero alborotador.
  • El desafío de reproducir defectos en el escritorio de un desarrollador, a medida que se incorporan sistemas dependientes como bases de datos o API de terceros (es común que las organizaciones experimenten un retraso de varias semanas entre la detección de defectos y la corrección de defectos en estas situaciones).
  • El impacto del cambio que se necesita para reparar un defecto. Si es un error simple, no importa tanto. Pero si lo ha hecho en muchos lugares, o ha utilizado el marco incorrecto, o ha creado un código que no es lo suficientemente escalable para la carga esperada, o que no se puede asegurar ...

Pruebe temprano, pruebe con frecuencia (el enfoque de cambio a la izquierda)

Ahora observe la línea naranja agregada al gráfico a continuación, ya que ilustra un ciclo de detección de defectos propuesto que se basa en pruebas anteriores (desplazado a la izquierda):

Animación. Jones, alcaparras. Medición de Software Aplicado: Análisis Global de Productividad y Calidad. Los defectos encontrados se desplazan a la izquierda.

Puede ver cómo la curva de detección naranja se hace más grande en el lado económico y más pequeña en el lado caro, lo que nos brinda una reducción de costos bastante significativa.

El desplazamiento a la izquierda se basa en una práctica de desarrollo más madura, por ejemplo, una basada en la pirámide de pruebas de software (los desarrolladores crean un conjunto de pruebas unitarias que cubren el código razonablemente bien, y los probadores funcionales y los probadores de API hacen todo lo que pueden y minimizar la dependencia de las pruebas de ciclo tardío por lo que tiene suficientes pruebas manuales / UI para demostrar que todo está funcionando). De esta manera, las pruebas de ciclo tardío están ahí para probar la funcionalidad, no para encontrar errores. Prueba-temprano, prueba-a menudo es el mantra del turno-izquierdo.

Cambiando aún más a la izquierda

Algunas organizaciones que se desplazan hacia la izquierda se detienen en este punto. Pero obtienes aún más valor cuando presionas aún más hacia la izquierda, en la codificación. Después de todo, aquí es donde se introducen los errores, así que comencemos a buscarlos mientras el desarrollo todavía está funcionando. Aquí es donde nos beneficiamos del análisis de código estático, al encontrar defectos aún más a la izquierda, donde los defectos son más baratos de corregir:

Con el análisis estático, puede comenzar a encontrar errores durante la fase de codificación real, cuando el costo de encontrar errores es lo más bajo posible.

Como puede ver claramente, encontrar cosas antes de que comience la "prueba" es lo más rentable. También es el más efectivo en el tiempo, ya que no deja a los desarrolladores con problemas para tratar de reproducir errores o comprender los fallos. Ser capaz de reducir un ciclo de corrección de defectos de días o semanas a horas o minutos es tremendamente útil.

Tenga cuidado con simplemente trasladar la carga al desarrollador

Pero hay un peligro en este paso, que accidentalmente impone demasiada carga de prueba a los desarrolladores de software. Lo importante que debe recordar al observar el gráfico es que, si bien el costo de la corrección de defectos aumenta drásticamente a medida que avanza hacia la derecha, los recursos de la izquierda tienen posiblemente el costo más alto de todos en el ciclo de vida del software, sin mencionar que usted les están alejando de centrarse en el desarrollo de funcionalidades.

Así que tienes que hacer lo correcto y llevar todo esto al siguiente nivel. No solo desea encontrar defectos antes, en realidad desea disminuir la cantidad de defectos que está poniendo en la aplicación en primer lugar. Vea el gráfico a continuación, con la hermosa burbuja reducida a la izquierda.

¡Pero espera, hay una trampa! Si estuviera recompensando a las personas por encontrar y corregir errores, ahora encontrarán menos, que en realidad es lo que desea, pero solo si realmente ha reducido la cantidad de errores que está introduciendo en primer lugar. Medir el número de defectos que llegan al campo es probablemente una métrica más útil.

Entonces, ¿cómo se desplaza hacia la izquierda?

Bien, esto es el núcleo de todo lo que hacemos en Parasoft. Pero en aras de la brevedad, el enfoque de prueba de cambio a la izquierda se divide en dos actividades principales.

Aplicar las mejores prácticas de pruebas de desarrollo

Realizar prácticas de desarrollo en etapas anteriores, como análisis de código estático y pruebas unitarias, ayuda tanto a identificar como a prevenir defectos en una etapa más temprana del proceso.

Es importante recordar que el objetivo no es encontrar errores, sino reducir la cantidad de errores (especialmente los que se incluyen en la versión). En última instancia, crear menos errores en primer lugar es mucho más valioso que encontrar más errores, y es mucho más barato. Es por eso que los estándares de codificación críticos para la seguridad en un enfoque preventivo proactivo al marcar el código que puede "funcionar" pero que aún no es seguro.

Los estándares de codificación son el software equivalente a los estándares de ingeniería y son clave para reducir el volumen de errores (además de encontrar errores antes), para respaldar y obtener el máximo valor de su iniciativa de cambio a la izquierda. Los estándares de codificación son la encarnación del conocimiento de la ingeniería de software que lo ayudan a evitar códigos malos / peligrosos / inseguros. Para usarlos, aplica el análisis de código estático.

Para la seguridad del software, esto es especialmente importante para fortalecer con éxito su software. Quiere incorporar seguridad en su código, no probarlo. Los estándares de codificación le permiten crear una aplicación más segura desde el principio (es decir, segura por diseño), lo cual es tanto una buena idea como un requisito. si está sujeto a regulaciones como GDPR.

Aproveche la virtualización de servicios para permitir pruebas continuas

A continuación, debe tomar las pruebas que se crearon en todas las etapas, incluidas las etapas posteriores, del proceso de desarrollo, y ejecutarlas continuamente avanzando. Esto es fundamental para los equipos que están adoptando prácticas de desarrollo ágiles para proporcionar retroalimentación continua durante todo el proceso de desarrollo. Las pruebas unitarias se pueden ejecutar fácilmente de forma continua, pero cambiar a la izquierda de la ejecución de pruebas funcionales en etapas posteriores a menudo es difícil debido a las dependencias del sistema externo, y aquí es donde puede aprovechar la virtualización de servicios para permitir las pruebas continuas.

Virtualización de servicios le permite simular sistemas dependientes que pueden tener disponibilidad limitada, como mainframes, tarifas de acceso, servicios de terceros o quizás sistemas que aún no están listos. Simulándolos, puede realizar pruebas funcionales sin tener todo el sistema disponible, y puede desplazar la ejecución de la prueba a la izquierda hasta el escritorio de desarrollo.

En términos de pruebas de rendimiento, la virtualización de servicios le permite realizar pruebas antes de que todo esté listo y sin tener un laboratorio completo de todo en el sistema. Incluso puede ejecutar todo tipo de escenarios hipotéticos, como qué pasa si el servidor de aplicaciones es rápido y la base de datos lenta (algo difícil de hacer en el mundo real). O, ¿qué pasa si mi servidor comienza a arrojar errores divertidos como un error 500? ¿Cómo afectará eso al rendimiento del sistema?

Puede impulsar el sistema tanto como quiera y más allá, y hacerlo lo antes posible. (Obtenga más información sobre cómo shift-left su prueba de rendimiento.)

Del mismo modo, puede comenzar a realizar sus pruebas de seguridad antes. El desacoplamiento de los sistemas físicos le permite hacer algo aún más interesante, que es hacer que los sistemas simulados se comporten de manera maligna. Ahora puede REALMENTE realizar pruebas de seguridad ... En lugar de simplemente hurgar en su sistema en busca de datos contaminados y DDoS, puede hacer que un sistema lo inunde con paquetes, o envíe datos mal formados o cualquiera de los muchos otros exploits comúnmente utilizados por los atacantes. Por lo tanto, no solo puede probar antes (a la izquierda), sino que también puede probar mucho más profundamente de lo que es posible con un laboratorio de pruebas o un sistema de producción.

Resumen

Los procesos de garantía de calidad que han demostrado su eficacia durante muchas décadas se pueden utilizar para mejorar drásticamente la calidad y, al mismo tiempo, ahorrar tiempo y dinero.

Cuando se desplaza hacia la izquierda aprovechando las tecnologías modernas de prueba de software, puede lograr un software que sea seguro, confiable y protegido. Al cambiar las pruebas a la izquierda, puede reducir el costo de las pruebas al encontrar errores antes, cuando es más barato, y al mismo tiempo reducir la cantidad de errores que ingresa en el código en primer lugar.

Escrito por

Arthur Hicken

Arthur ha estado involucrado en seguridad de software y automatización de pruebas en Parasoft durante más de 25 años, ayudando a investigar nuevos métodos y técnicas (incluidas 5 patentes) mientras ayuda a los clientes a mejorar sus prácticas de software.

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