Las pruebas de desplazamiento a la izquierda son un enfoque en el desarrollo de software que hace hincapié en mover las actividades de prueba antes en el proceso de desarrollo para mejorar la calidad del software, una mejor cobertura de las pruebas, feedback continuos y un tiempo de comercialización más rápido.
¿Ha participado en un proyecto de software que se salía del presupuesto y sobrepasaba todos los plazos? Por supuesto que sí, todos lo hemos hecho. De hecho, si aún no lo ha hecho, es un unicornio 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 debe estar terminado en una fecha determinada y las pruebas llevarán cierto tiempo, entonces podemos utilizar esa información para trabajar hacia atrás y elegir una fecha de vencimiento 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.
Incluir tiempo para las pruebas de control de calidad es excelente en teoría, pero se desmorona rápidamente en la práctica una vez que se identifica el primer error o defecto.
¿Cuánto tiempo llevará arreglar este defecto? ¿En qué medida afectará al calendario? ¿Aparecerán nuevos fallos? ¿Cómo nos aseguraremos de que cada arreglo se verifica con tiempo suficiente para arreglar lo que hayamos roto mientras arreglábamos lo primero?
Al final, nunca pude encontrar la cantidad correcta de tiempo para asignar al control de calidad. Inevitablemente, las correcciones apresuradas se fusionaron en el último minuto; aprendí a mantener mi calendario despejado durante un par de semanas después de los grandes lanzamientos para poder clasificar todos los problemas que pasamos por alto (o introdujimos) en nuestras locas carreras hasta el final.
El problema, a fin de cuentas, no era el tiempo disponible para las pruebas, sino el momento de realizarlas. Necesitaba hacer pruebas antes y con más frecuencia. Necesitaba pruebas de desplazamiento a la izquierda.
Si imaginamos nuestro proceso de desarrollo de software como una línea de tiempo que fluye de izquierda a derecha, la "prueba de desplazamiento a la izquierda" se explica por sí misma. En pocas palabras, es la práctica de realizar pruebas en fases más tempranas, implicar en la estrategia de pruebas a los miembros del equipo, incluidos probadores, desarrolladores y partes interesadas, e integrar las pruebas tanto de las funciones existentes como de las 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 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 desplazamiento a la izquierda: 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. Los dos son importantes.
Necesitamos validar que los requisitos de nuestros usuarios realmente resuelven los problemas que nos hemos propuesto 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. 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 fines de este artículo, nos centraremos en las pruebas automatizadas de verificación.
Pruebas de pruebas de unidad
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 de desplazamiento a la izquierda.
Pruebas de integración
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.
Pruebas de API y pruebas de contratos
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.
Pruebas de IU
Las pruebas de interfaz de usuario verifican la funcionalidad completa de una aplicación desde la capa de interfaz de usuario. Herramientas como Selenium hacen que las pruebas automatizadas de interfaz de usuario sean ampliamente accesibles.
Más que automatización
El desplazamiento a la izquierda no es sólo 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 ideas pueden ayudar a que la arquitectura sea más transparente 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.
Realización continua de pruebas
Si pensamos en TDD como "desplazamiento a la izquierda para monolitos", entonces las pruebas continuas son "desplazamiento a la izquierda 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 una serie de 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 fuera de sincronía con sus servicios ascendentes o descendentes.
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 una infraestructura adicional.
¿Y si pudiéramos utilizar pruebas continuas de API integradas en nuestra herramienta de observabilidad? La próxima función 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 desplazamiento a la izquierda 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. Estas son algunas de las mejores prácticas para las pruebas de desplazamiento a la izquierda en el desarrollo ágil:
Participación temprana: las actividades de prueba deben comenzar lo antes posible en el proceso de desarrollo. Los probadores deben participar desde la fase de recopilación de requisitos para comprender el alcance del proyecto, los objetivos y las expectativas de los usuarios.
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.
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 las canalizaciones 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.
Desarrollo basado en pruebas (TDD): fomente la práctica de TDD, donde los desarrolladores escriben casos de prueba antes de escribir el código real. Este enfoque de pruebas por desplazamiento a la izquierda 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.
Integración y entrega continuas (CI/CD): implemente canalizaciones 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 con rapidez y frecuencia, reduciendo el riesgo de problemas de integración.
Pruebas de seguridad de desplazamiento a la izquierda: considere la posibilidad de integrar prácticas de pruebas de seguridad al principio 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.
Pruebas exploratorias: junto con las pruebas automatizadas, fomente las pruebas exploratorias para explorar la aplicación desde la perspectiva del usuario. Los evaluadores cualificados pueden identificar posibles problemas de usabilidad, casos extremos y escenarios que las pruebas automatizadas podrían pasar por alto.
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.
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.
Aprendizaje y mejora continuos: fomente una cultura de aprendizaje y mejora continuos. Fomente las retrospectivas periódicas para reflexionar sobre los procesos de pruebas, identificar los cuellos de botella y aplicar cambios para mejorar la eficacia de las pruebas por turnos.
Al implementar estas buenas prácticas, los equipos ágiles pueden lograr una mejor colaboración, feedback más rápidos y productos de software de mayor calidad a través de pruebas de desplazamiento a la izquierda.
Los bucles de feedback más cortos integrados en los procesos de desplazamiento a la izquierda 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 de desplazamiento a la izquierda.
Ahorro de costes
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 ha llegado a un entorno orientado al cliente, el coste de solucionarlo aumenta.
Bienestar de los desarrolladores
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. Encontrar defectos antes significa menos momentos de pánico en todas las manos. Dado que los lanzamientos son tan sencillos, corregir los pocos errores que se producen también es más rápido y fácil.
Arquitectura resiliente
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 resistente.
Mayor calidad general
Mejorar la experiencia del cliente es nuestro objetivo final. El desplazamiento a la izquierda 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 la salud 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 es un camino peligroso.
Probar los efectos secundarios (¿se guardó realmente ese registro 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 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 interfaz de usuario 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 de desplazamiento a la derecha son la práctica de realizar pruebas más tarde en el proceso de desarrollo, generalmente en entornos de producción. Aunque pueda parecer extraño, las pruebas de desplazamiento a la izquierda y a la derecha son complementarias.
Las pruebas de desplazamiento a la derecha nos permiten identificar los problemas de producción antes que nuestros clientes. Los bucles de feedback más cortos de las pruebas de desplazamiento a la izquierda nos dan la capacidad de responder y remediar estos problemas de producción rápidamente.
Las pruebas sintéticas de API como parte de su plataforma de observabilidad son la forma perfecta de combinar las ventajas de las prácticas de desplazamiento a la izquierda y a la derecha.
Aumente la funcionalidad y la observabilidad en la APM de su empresa; mejore la gestión del rendimiento de las aplicaciones y acelere las canalizaciones de CI/CD sin importar dónde residan las aplicaciones.
Explore cómo la observabilidad proporciona una visibilidad profunda de las aplicaciones distribuidas modernas para una identificación y resolución de problemas más rápidas y automatizadas.
Lea cómo las pruebas continuas desempeñan un papel crucial para acelerar el desarrollo de software, mejorar la calidad del código y evitar costosos cuellos de botella.
Explore cómo DevOps acelera la entrega de software de mayor calidad combinando y automatizando el trabajo de los equipos de desarrollo de software y operaciones de TI.
Aprenda todo lo que necesita saber sobre la supervisión sintética: qué es, cómo utilizarla, los retos y mucho más.
Aprenda cómo la aplicación de tecnología, programas, robótica o procesos puede ayudar a lograr resultados con una intervención humana mínima.
Prevea y evite los problemas de rendimiento antes de que afecten a su empresa con la gestión del rendimiento de las aplicaciones.