¿Qué son las pruebas shift left?

¿Ha participado alguna vez en un proyecto de software que se haya salido del presupuesto y haya incumplido todos los plazos? Seguro que sí, a todos nos ha pasado. De hecho, si no ha sido así, es usted un perro verde y me gustaría conocerle.

En las primeras etapas de mi carrera de desarrollo de software, aprendí la importancia de trabajar a partir de una fecha límite. Si un proyecto tiene un plazo determinado y las pruebas van a llevar un tiempo concreto, con esa información podemos calcular hacia atrás y fijar una fecha de entrega para nuestro proyecto. Perfecto, ¿verdad?

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

Prever tiempo para las pruebas de control de calidad es una idea estupenda en teoría, pero en la práctica se viene abajo rápidamente en cuanto se detecta el primer error o defecto.

¿Cuánto tiempo llevará corregir este defecto? ¿En qué medida afectará al calendario? ¿Aparecerán nuevos fallos? ¿Cómo nos aseguraremos de que cada corrección se verifica con tiempo suficiente para corregir lo que hayamos roto mientras corregíamos lo primero?

Al final, nunca conseguí encontrar el tiempo necesario para dedicar al control de calidad. Inevitablemente, se incorporaban correcciones apresuradas en el último momento. Aprendí a dejar mi agenda libre durante un par de semanas tras los lanzamientos importantes. Este enfoque me permite clasificar por orden de prioridad cualquier problema que se nos haya pasado por alto (o que hayamos introducido) en nuestra carrera frenética hacia la meta.

Al final, el problema no era el tiempo disponible para las pruebas, sino más bien el momento en que se realizaban. Necesitaba que las pruebas se hicieran antes y con mayor frecuencia. Necesitaba pruebas shift left.

Si imaginamos nuestro proceso de desarrollo de software como una línea de tiempo que fluye de izquierda a derecha, la "prueba shift left" se explica por sí misma. En pocas palabras, consiste en realizar pruebas en fases más tempranas e involucrar a los miembros del equipo (entre ellos, los evaluadores, los desarrolladores y los stakeholders) en la estrategia de pruebas. También implica integrar con mayor frecuencia las pruebas de las características existentes y de las nuevas 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 tradicional en cascada e "invertimos" el eje Y en la fase de implementación, obtenemos el modelo en V.

Un ciclo de desarrollo comienza con requisitos de alto nivel. Estos requisitos se van reduciendo con cada paso sucesivo de la "V" hasta llegar a la aplicación a nivel de código propiamente dicha. A continuación, verificamos la implementación, empezando por las pruebas unitarias más granulares y ascendiendo por la "V" hasta las pruebas de aceptación de usuarios más abstractas.

En un proceso en cascada, todo el proyecto se compone de una única "V". Como sector, hemos aprendido que cuando se deja toda la validación para el final de un proyecto complejo, básicamente se está abocando al fracaso.

En un proceso iterativo, podemos pensar en cada sprint o iteración como una "V" más pequeña. En teoría, hemos logrado nuestros objetivos de shift left: realizar pruebas antes y con mayor 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.

Tenemos que comprobar que nuestros requisitos de usuario resuelven los problemas que nos propusimos resolver. También necesitamos verificar que nuestra implementación coincida con las especificaciones que obtenemos de esos requisitos de los usuarios.

Las pruebas automatizadas se pueden aplicar tanto a las validaciones como a las verificaciones. El diseño basado en el comportamiento (BDD) ha llevado a la creación de tecnologías como Cucumber que pueden automatizar algunas partes del proceso de validación. Para los fines de este artículo, nos centraremos en las pruebas automatizadas de verificación.

Las pruebas unitarias verifican la funcionalidad de un módulo específico en 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 simula. Las pruebas unitarias y TDD representan la primera fase de desarrollo en las pruebas 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 discutiremos más adelante.

Las pruebas de API verifican los endpoints externos de un único servicio. El alcance de las pruebas de API es similar al de las pruebas de integración; sin embargo, en un contexto SOA o de microservicios, podemos pensar en las pruebas de 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 es solo automatización. Otra forma de realizar pruebas antes y con mayor frecuencia es asegurarse de que sus especialistas en control de calidad participen en cada paso de su proceso, empezando por el descubrimiento y la recopilación de requisitos. Los ingenieros de pruebas pueden hacerlo mejor cuando tienen un mayor conocimiento de la implementación global, y sus perspectivas pueden ayudar a que la arquitectura sea más abierta y resiliente.

Cuando pensamos en probar "antes 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 alguna forma de integración y entrega continuas. Las pruebas continuas son un bucle de feedback 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 las pruebas de contratos. Las pruebas de API tienen algunos beneficios:

• Las pruebas de API pueden evitar una de las formas más habituales de introducir errores en una aplicación de microservicios: modificar una dependencia sin que esté sincronizada con sus servicios anteriores o posteriores.
   

• Las pruebas de la API pueden pertenecer al mismo equipo que posee el servicio.
   

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

Lo ideal sería que estas pruebas de API se ejecuten de forma continua en entornos de producción y preproducción. Las herramientas de pruebas de contratos pueden ayudar a automatizar este proceso, pero eso requiere más infraestructura.

¿Y si pudiéramos utilizar 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.

El shift left implica acercar las actividades de prueba al principio del ciclo de vida de desarrollo del software, lo que permite un feedback más rápido y reduce el tiempo y el esfuerzo necesarios para corregir errores. A continuación se presentan algunas buenas prácticas para las pruebas 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 la colaboración y la comunicación estrechas entre los desarrolladores, los evaluadores y otras partes interesadas. Fomente las reuniones diarias, las sesiones de planificació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 automatización de pruebas para permitir pruebas frecuentes y eficientes. Las pruebas automatizadas deben crearse junto con el proceso de desarrollo e integrarse en los pipelines de integración e implementación continuas. Esto ayuda a detectar defectos a tiempo, reducir los problemas de regresión y acelerar los ciclos de feedback.
    

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

5. Integración y entrega continuas (CI/CD): implemente pipelines de CI/CD para automatizar los procesos de creación, prueba e implementación. Esta práctica garantiza que cada cambio de código se pruebe a fondo y se implemente 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 al inicio del proceso de desarrollo. Realice revisiones de código de seguridad, análisis de código estático y pruebas centradas en la seguridad para identificar vulnerabilidades y abordarlas de forma proactiva.
    

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

8. Pruebas de rendimiento: realice pruebas de rendimiento con antelació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 cumple los criterios de rendimiento exigidos.
    

9. Entornos y datos de prueba: proporcione entornos de prueba que se parezcan mucho a los entornos de producción para garantizar unas pruebas de software realistas. Asegúrese también de que se dispone de datos de prueba suficientes y representativos para simular escenarios del mundo real.
    

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

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

Los bucles de feedback más cortos integrados en los procesos shift left nos potencian de varias maneras. Los defectos se detectan más rápido, las correcciones se aplican con mayor eficacia y las lecciones aprendidas en una iteración pueden aplicarse en la siguiente, por citar algunos ejemplos.

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

Un defecto detectado por una prueba unitaria automatizada en la máquina local de un desarrollador cuesta menos de identificar y corregir. Pero cuando un defecto llega a un entorno orientado al cliente, el coste de las correcciones aumenta.

Si se hacen correctamente, las pruebas automatizadas y la CI pueden ofrecer la confianza que los ingenieros de software necesitan para implementar con frecuencia, incluso los viernes. Detectar los defectos antes significa que habrá menos momentos de pánico en los que haya que movilizar a todo el personal. Dado que los lanzamientos son tan sencillos, corregir los pocos errores que se producen también es más rápido y fácil.

Del mismo modo que un software más accesible nos resulta más fácil de usar a todos, un software más comprobable puede ser más fácil de razonar y mantener. Pensar en las pruebas en una fase temprana puede conducir a una mejor separación de preocupaciones 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 finales podrían experimentar y reducir el impacto de otros incidentes. Podemos utilizar la observabilidad para completar este ciclo de feedback y mejorar el estado general de nuestro software.

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

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

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

Las pruebas shift right son la práctica de realizar pruebas más adelante en el proceso de desarrollo, normalmente en entornos de producción. Aunque pueda parecer extraño, las pruebas shift left y shift right son complementarias.

Las pruebas shift right nos permiten identificar los problemas de producción antes que nuestros clientes. Los bucles de feedback más cortos de las pruebas 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.