Seminario web destacado: Presentación de la prueba CT de Parasoft C/C++ para pruebas continuas y excelencia en el cumplimiento | Vea ahora

¿Qué es la prueba Shift-Left?

Foto de cabeza de Arthur Hicken, evangelista de Parasoft
11 de diciembre de 2018
7 min leer

Cuanto antes se dé cuenta de los problemas con su código, menor será el impacto que tendrán. Tratar con ellos también resulta en menores gastos. Aquí, desentrañamos la metodología de desplazamiento a la izquierda y cómo implementarla en su negocio.

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 al código?

The shift left testing strategy is well illustrated in the somewhat-famous graph from Capers Jones, that shows the increasing cost of bugs/defects being introduced into the software, at each phase of software development. The first part of the graph shows that the vast majority of bugs come in during the coding phase, which is to be expected.

Graph from Capers Jones depicting percentage of defects introduced by phase of development.

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).

¿Cuándo se encuentran esos errores?

Empieza a ponerse interesante cuando superponemos la línea que muestra dónde están los defectos founden 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.

¿Cuánto cuesta 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:

Imagen. Jones, Alcaparras. Medición de Software Aplicado: Análisis Global de Productividad y Calidad. Los defectos encontrados giran hacia la izquierda.

Ahora empieza a ponerse interesante, ya que vemos una desagradable progresión de costos que aumenta dramáticamente cuanto más tarde se descubre el defecto. Dejar que un error se cuele en las pruebas del sistema es 40 veces el costo de encontrarlo durante la codificación, o 10 veces más costoso que encontrar el mismo error durante las pruebas unitarias. Y se vuelve ridículamente costoso cuando nos fijamos en la cantidad de errores que se dejan pasar hasta 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 giran hacia 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 (desarrolladores creando un conjunto de pruebas unitarias que cubren el código razonablemente bien, y los evaluadores funcionales y los evaluadores de API hacen todo lo posible y minimizan la dependencia de las pruebas de último ciclo para que tenga suficientes pruebas manuales/UI para demostrar que todo funciona). 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.

Desplazarse aún más hacia 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.

Cuidado con 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.

¿Cómo se desplaza a 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 aquellos que aparecen 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 adoptan un enfoque proactivo y preventivo al marcar el código que puede "funcionar" pero aún así no ser seguro.

Los estándares de codificación son el equivalente en software de los estándares de ingeniería y son clave para reducir el volumen de errores (además de encontrarlos antes), para respaldar y aprovechar al máximo 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 le ayuda a evitar códigos malos, peligrosos o inseguros. Para usarlos, aplica análisis de código estático.

Para la seguridad del software, esto es especialmente importante para reforzarlo con éxito. Quiere incorporar seguridad a 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 a la vez una buena idea y 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 de manera continua. Esto es fundamental para los equipos que están adoptando prácticas de desarrollo ágiles para proporcionar comentarios continuos durante todo el proceso de desarrollo. Las pruebas unitarias se pueden ejecutar fácilmente de forma continua, pero cambiar a la izquierda la ejecución de las pruebas funcionales de etapa posterior suele ser difícil debido a las dependencias del sistema externo, y aquí es donde puede aprovechar la virtualización de servicios para permitir pruebas continuas.

La virtualización de servicios le permite simular sistemas dependientes que podrían tener disponibilidad limitada, como mainframes, tarifas de acceso, servicios de terceros o quizás sistemas que simplemente aún no están listos. Al simularlos, puede realizar pruebas funcionales sin tener todo el sistema disponible y puede desplazar la ejecución de la prueba hacia la izquierda hasta el escritorio de desarrollo.

En términos de virtualización de servicios en pruebas de rendimiento, la virtualización de servicios le permite probar 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 lograr 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, puedes empezar a realizar tus pruebas de seguridad antes. Desacoplarse 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 malvada. Ahora REALMENTE puede dedicarse a las 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, envíe datos con formato incorrecto o cualquiera de los muchos otros exploits comúnmente utilizados por los atacantes. Por lo tanto, no solo puede realizar pruebas antes (izquierda), sino que también puede realizar pruebas mucho más profundas 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.

Guía de metodologías de prueba de software: maximice la calidad, el cumplimiento, la seguridad y la protección