¿Qué es la prueba shift left?

¿Estuvo involucrado en un proyecto de software que se excedió del presupuesto y no cumplió con todos los plazos? A todos nos ha pasado. De hecho, si no lo estuvo, es un unicornio y me gustaría conocerlo.

En las primeras etapas de mi carrera de desarrollo de software, aprendí la importancia de trabajar hacia atrás a partir de una fecha límite. Si un proyecto tiene una fecha límite determinada y las pruebas llevarán cierto tiempo, entonces, con esa información, podemos trabajar hacia atrás y elegir una fecha de vencimiento para nuestro proyecto. Perfecto, ¿verdad?

Bueno, no del todo. Si bien la creación de tiempo para las pruebas manuales redujo algo de estrés en los últimos días de los proyectos, todavía había demasiadas sorpresas.

En teoría, planear el tiempo para las pruebas de control de calidad es una buena idea, pero en la práctica se desmorona rápidamente una vez que se identifica el primer error o defecto.

¿Cuánto tiempo se tardará en arreglar este defecto? ¿Cuánto afectará a la línea de tiempo? ¿Se introducirán nuevos errores? ¿Cómo garantizaremos que cada arreglo se verifique a tiempo para reparar todo lo que descompusimos mientras arreglábamos la primera cosa?

Al final, nunca he podido encontrar la cantidad correcta de tiempo para asignar a control de calidad. Inevitablemente, los arreglos apresurados se fusionaron en el último minuto. Aprendí a mantener mi calendario despejado durante un par de semanas después de lanzamientos importantes. Este enfoque me permite clasificar cualquier problema que nos perdimos (o introdujimos) en nuestras locas carreras hasta el final.

El problema, al final, no era el tiempo disponible para las pruebas, sino el momento de las pruebas. Necesitaba pruebas antes y con más frecuencia. Necesitaba pruebas de shift left.

Si imaginamos nuestro proceso de desarrollo de software como una línea de tiempo que fluye de izquierda a derecha, entonces la “prueba de shift left” se explica por sí sola. En pocas palabras, es la práctica de probar etapas anteriores, involucrando a los miembros del equipo, incluidos quienes realizan las pruebas, desarrolladores y stakeholders en la estrategia de pruebas. Además, implica integrar pruebas tanto para características existentes como nuevas con mayor frecuencia en el ciclo de vida del desarrollo.

El modelo V es una forma útil de conceptualizar los ciclos de desarrollo de software. Si tomamos el flujo de cascada tradicional y "volteamos" el eje Y en la fase de implementación, obtenemos el modelo V.

Un ciclo de desarrollo comienza con requisitos de alto nivel. Estos requisitos se reducen con cada paso sucesivo de la "V" hasta que llegamos a la implementación a nivel de código en sí. Luego verificamos la implementación, comenzando con las pruebas unitarias más granulares y avanzando hasta la "V", a las pruebas de aceptación del usuario más abstractas.

En un proceso en cascada, todo el proyecto se compone de una única "V". Como industria, aprendimos que cuando dejas toda la validación para el final de un proyecto complejo, básicamente te estás preparando para fracasar.

En un proceso iterativo, podemos pensar en cada sprint o iteración como una “V” más pequeña. En teoría, logramos nuestros objetivos del shift left: hacer pruebas antes y con más frecuencia. Problema resuelto, ¿verdad? Bueno, no del todo.

Es posible que haya notado que hay dos etiquetas en el canal de feedback integrado en el modelo V: verificación y validación. Estas etiquetas son importantes.

Necesitamos validar que nuestros requisitos de usuario resuelvan los problemas que nos propusimos resolver. También necesitamos verificar que nuestra implementación coincida con las especificaciones que obtenemos de los requisitos del usuario.

Las pruebas automatizadas se pueden aplicar tanto a las validaciones como a las verificaciones. BDD (Behavior Driven Design) ha llevado a la creación de tecnologías como Cucumber que pueden automatizar algunas partes del proceso de validación. Para los efectos de este artículo, nos centraremos en las pruebas automatizadas para la verificación.

Las pruebas unitarias verifican la funcionalidad de un módulo específico dentro de una aplicación más grande. El módulo se prueba de forma aislada y cualquier comunicación con otros procesos externos se simula o finge. Las pruebas unitarias y TDD representan la primera fase de desarrollo en las pruebas de shift left .

Las pruebas de integración intentan verificar la funcionalidad general de un servicio o aplicación, incluidos los efectos secundarios. Este proceso es un antipatrón por razones que analizaremos más adelante.

Las pruebas de API verifican los endpoints externos de un único servicio. El alcance de las pruebas API es similar al alcance de las pruebas de integración; sin embargo, en un contexto SOA o de microservicios, podemos pensar en las pruebas API como las nuevas pruebas unitarias.

Las pruebas de IU verifican la funcionalidad completa de una aplicación desde la capa de interfaz de usuario. Herramientas como Selenium hacen que las pruebas automatizadas de IU sean ampliamente accesibles.

El shift left no se trata solo de automatización. Otra forma de realizar pruebas antes y con más frecuencia es cerciorarse de que sus especialistas en control de calidad estén involucrados en cada paso de su proceso, comenzando con el descubrimiento y la recopilación de requisitos. Los ingenieros de pruebas pueden mejorar cuando tienen una mayor comprensión de la implementación general, y sus insights pueden ayudar a que la arquitectura sea más abierta y resiliente.

Cuando pensamos en hacer pruebas “más pronto y con más frecuencia”, nos viene a la mente una palabra determinada: continuo. Muchos (la mayoría) de los equipos de desarrollo de software están practicando algún tipo de integración continua y entrega continua. Las pruebas continuas son un ciclo de retroalimentación vital en este ciclo de DevOps.

Si pensamos en TDD como "shift left para monolitos", entonces las pruebas continuas son "shift left para arquitecturas distribuidas".

TDD nos hizo centrarnos en las pruebas unitarias. Para las pruebas continuas, debemos centrarnos en las pruebas de API y los contratos. Las pruebas de API tienen algunos beneficios:

• Las pruebas de API pueden evitar una de las formas más comunes de introducir errores en una aplicación de microservicios: cambiar una dependencia para que no esté sincronizada con sus servicios ascendentes o descendentes.
   

• Las pruebas de API pueden ser propiedad del mismo equipo que posee el servicio.
   

• Las pruebas de API evitan la fragilidad de los efectos secundarios de las pruebas y los detalles de implementación.

Idealmente, estas pruebas de API se ejecutarán de manera continua en entornos de producción y preproducción. Las herramientas de prueba de contratos pueden ayudar a automatizar este proceso, pero eso requiere infraestructura adicional.

¿Qué pasaría si pudiéramos usar pruebas continuas de API integradas en nuestra herramienta de observabilidad? La próxima característica de pruebas de API sintéticas de Instana le permitirá ejecutar continuamente pruebas de API en todos sus entornos con un esfuerzo mínimo.

Shift left implica acercar las actividades de prueba al comienzo del ciclo de vida del desarrollo de software, lo que permite feedback más rápido y reduce el tiempo y el esfuerzo necesarios para la corrección de errores. Estas son algunas de las mejores prácticas para las pruebas de shift left en el desarrollo ágil:

1. Participación temprana: las actividades de prueba deben comenzar lo antes posible en el proceso de desarrollo. Los evaluadores deben participar desde la fase de recopilación de requisitos para comprender el alcance del proyecto, los objetivos y las expectativas de los usuarios.
    

2. Colaboración y comunicación: fomente una estrecha colaboración y comunicación entre desarrolladores, evaluadores y otros stakeholders. Fomente las reuniones diarias, las sesiones de planeación de sprints y las retrospectivas periódicas para garantizar la comprensión y la alineación compartidas.
    

3. Automatización de pruebas: invierta en la automatización de pruebas para permitir pruebas frecuentes y eficientes. Las pruebas automatizadas deben crearse junto con el proceso de desarrollo e integrarse en las pipelines continuas de integración y despliegue. Esto ayuda a detectar defectos de manera temprana, reducir los problemas de regresión y acelerar los ciclos de feedback.
    

4. Desarrollo basado en pruebas (TDD): fomente la práctica de TDD, en el que los desarrolladores escriben casos de prueba antes de escribir el código real. Este enfoque de prueba de shift left ayuda a definir el comportamiento deseado y los resultados esperados por adelantado, lo que lleva a un código más robusto y comprobable.
    

5. Integración continua y entrega continua (CI/CD): implemente pipelines de CI/CD para automatizar los procesos de creación, prueba y despliegue. Esta práctica garantiza que cada cambio de código se pruebe exhaustivamente y se despliegue en entornos de producción de forma rápida y frecuente, lo que reduce el riesgo de problemas de integración.

6. Pruebas de seguridad shift left: considere la posibilidad de integrar prácticas de pruebas de seguridad en las primeras fases del proceso de desarrollo. Realice revisiones de códigos de seguridad, análisis de código estático y pruebas centradas en la seguridad para identificar vulnerabilidades y abordarlas de manera proactiva.

7. Pruebas exploratorias: junto con las pruebas automatizadas, fomente las pruebas exploratorias para explorar la aplicación desde la perspectiva de un usuario. Los evaluadores expertos pueden identificar posibles problemas de usabilidad, casos extremos y escenarios que las pruebas automatizadas podrían pasar por alto.
    

8. Pruebas de rendimiento: realice pruebas de rendimiento con anticipación para identificar posibles cuellos de botella y problemas de escalabilidad. Esto ayuda a optimizar el rendimiento de la aplicación y a garantizar que cumpla con los criterios de rendimiento requeridos.
    

9. Entornos de prueba y datos: aprovisione entornos de prueba que se parezcan mucho a los entornos de producción para garantizar pruebas de software realistas. También, asegúrese de que haya datos de prueba suficientes y representativos disponibles para simular escenarios del mundo real.
    

10. Aprendizaje y mejora continuos: fomente una cultura de aprendizaje y mejora continuos. Promueva retrospectivas periódicas para reflexionar sobre los procesos de prueba, identificar cuellos de botella e implementar cambios para mejorar la eficacia de las pruebas de shift left.

Al implementar estas mejores prácticas, los equipos ágiles pueden lograr una mejor colaboración, feedback más rápido y productos de software de mayor calidad a través de pruebas de shift left.

Los bucles de feedback más cortos incorporados en los procesos de shift left nos potencian de varias maneras. Los defectos se pueden encontrar más rápido, las correcciones se pueden aplicar de manera más eficiente y las lecciones aprendidas en una iteración se pueden aplicar en la siguiente, por mencionar algunas.

Independientemente de la metodología de gestión de proyectos o la cadencia de lanzamiento que tenga su equipo, puede beneficiarse de los bucles de retroalimentación de verificación más cortos de las pruebas de shift left.

Un defecto encontrado por una prueba unitaria automatizada en la máquina local de un desarrollador cuesta menos identificar y corregir. Pero cuando un defecto ha llegado a un entorno orientado al cliente, el costo de arreglarlo aumenta.

Cuando se realizan correctamente, las pruebas automatizadas y la CI pueden proporcionar la confianza que los ingenieros de software necesitan para desplegar con frecuencia, incluso los viernes. Encontrar defectos antes significa menos momentos de pánico en los que todo el personal se ve involucrado. Porque los lanzamientos son tan indoloros, arreglar los pocos errores que logran colarse también es más rápido y fácil.

Del mismo modo que un software más accesible suele ser más fácil de usar para todos, un software más comprobable puede ser más fácil de comprender y mantener. Pensar en las pruebas en una fase temprana puede conducir a una mejor separación de intereses y a una arquitectura general más resiliente.

Mejorar la experiencia del cliente es nuestro objetivo. El shift left puede eliminar algunos incidentes que los usuarios podrían experimentar y reducir el impacto de otros incidentes. Podemos usar observabilidad para completar este ciclo de feedback y mejorar el estado general de nuestro software.

Con potentes herramientas de automatización a nuestra disposición, puede ser tentador implementar todo tipo de pruebas en cada línea de código. Este enfoque es un camino peligroso.

Probar los efectos secundarios (¿ese registro realmente se almacenó en la base de datos?) es una idea atractiva. Pero probar los detalles de implementación es un antipatrón porque este tipo de pruebas son extremadamente frágiles. Es posible que deban cambiar cada vez que se cambie su aplicación. La interfaz de usuario también es un detalle de implementación, por lo que las pruebas de IU caen dentro de este mismo aspecto.

Las pruebas de verificación solo se preocupan por el “qué”, no el “cómo” o el “por qué”. Idealmente, los requisitos del usuario se diseñaron para validar el "por qué". Para responder "cómo", podemos confiar en una automatización más poderosa en forma de plataforma de observabilidad.

Las pruebas de shift right son la práctica de pruebas más avanzadas en el proceso de desarrollo, generalmente en entornos de producción. Si bien puede parecer extraño, las pruebas de shift left y shift right son complementarias.

Las pruebas de shift left nos permiten identificar problemas de producción antes que nuestros clientes. Los ciclos de feedback más cortos de las pruebas de shift left nos dan la capacidad de responder y remediar estos problemas de producción rápidamente.

Las pruebas de API sintéticas como parte de su plataforma de observabilidad son la manera perfecta de combinar los beneficios de las prácticas de shift left y shift right.