Código
Desarrollo
Testing

Claves para definir una estrategia de ‘testing’ continuo

Las organizaciones que apuestan por un ‘testing’ basado en personas, mejores prácticas y principios ágiles mejoran de forma clara su negocio. Veamos cómo.

pc, trabajo,

Realizar pruebas continuas (testing) es tanto una práctica como una filosofía dentro de los equipos de desarrollo de software. Los desarrolladores y los especialistas en garantizar la calidad de las aplicaciones inician la práctica del testing continuo cuando trabajan en el pipeline DevOps CI/CD (integración continua/desarrollo continuo) y activan una lista de pruebas automatizadas que se ejecutan con cada construcción y entrega. La filosofía llega cuando los desarrolladores, ingenieros y especialistas en asegurar la calidad empiezan a colaborar en las estrategias de prueba y en las implementaciones.

Esta colaboración es de una importancia crítica porque muchas organizaciones de tecnología no destinan ni los recursos humanos y económicos ni el tiempo necesario para realizar pruebas adecuadas. Esto significa que la organización de desarrollo de software debe establecer una estrategia de testing que defina un enfoque óptimo, una estrategia de implementación y funciones de apoyo continuas que se ajusten a las limitaciones existentes.

Aunque los equipos de desarrollo deben crear una estrategia de testing holística, también necesitan una estrategia específica para el testing continuo por diversos motivos. Por un lado, porque realizar un testing continuo es una forma óptima de implementar una estrategia de pruebas específicas, ya que proporciona a los desarrolladores una retroalimentación antes de que el código llegue a un entorno de entrega. Es particularmente importante para la ejecución de análisis de calidad y de seguridad del código de modo que los desarrolladores aprendan y adopten mejores prácticas.

Puede ser una inversión más costosa ya que las pruebas continuas tienen que ser automatizadas primero, integradas en el pipeline de CI/CD y configuradas con alertas para que las herramientas notifiquen los problemas descubiertos a las personas adecuadas. Dado que estas pruebas se realizan durante la construcción y la entrega, los equipos tienen que ser selectivos en cuanto al tipo de testing a implementar y considerar su duración. Las pruebas de larga duración no son óptimas para el testing continuo si ralentizan a los desarrolladores. La mejor manera de revisar las opciones de implementación y de que los equipos colaboren en las soluciones es optar por una estrategia de pruebas continuas.

 

Las personas en el centro

Cada vez cobra más importancia definir una estrategia de testing continuo usando un enfoque ágil. En un marco de testing continuo son diferentes personas las que se benefician de las pruebas, de forma que hay que priorizar qué tipos de pruebas hay que implementar. Algunas de estas personas o partes interesadas son los desarrolladores, que quieren asegurar la calidad del código y que sus modificaciones no rompan los servicios u otras áreas del código; los equipos de operaciones, que están preocupados por que los cambios de código no introduzcan problemas de rendimiento o afecten a la fiabilidad de la aplicación; los equipos de seguridad de la información, que están enfocados en el análisis del código estático, las pruebas de penetración y otros indicadores que alertan sobre riesgos de seguridad; especialistas en garantizar la calidad que representen los intereses de los usuarios finales de la aplicación y del propietario del producto; los arquitectos de software que representan la calidad del servicio y de las API, que son los más indicados para definir las normas sobre si los protocolos nuevos o modificados presentan un problema de calidad; los especialistas en la gestión de bases de datos, que se preocupan de si los desarrolladores han introducido sin darse cuenta nuevos problemas de calidad de datos o de seguridad; el equipo de desarrollo ágil, que debe responder y corregir los problemas cuando falla una construcción de CI/CD…

 

Cómo aplicar las pruebas continuas

Como antes dijimos, no todas las pruebas automatizadas se prestan bien a realizar un testing continuo. En primer lugar, las herramientas para ejecutar las pruebas deben integrarse sin problemas con Jenkins, CircleCI, Bamboo u otras herramientas de CI/CD utilizadas para la integración y entrega continua. Si el equipo tiene que realizar demasiado trabajo para integrar las pruebas en el pipeline de CI/CD, esto quita tiempo a otras labores críticas de negocio y tecnología. Herramientas como SmartBear, BlazeMeter, Tricentis qTest, BrowserStack, SauceLabs, Postman y muchas otras tienen integraciones y plug-ins para Jenkins.

En segundo lugar, la ejecución de testing continuo requiere entornos informáticos adecuados para ejecutar pruebas automatizadas. Muchas organizaciones que trabajan en entornos de desarrollo, pruebas y producción configurados manualmente luchan por mantener los cambios de configuración e infraestructura sincronizados entre sí. Cuando sea posible, es mejor estandarizar los entornos y utilizar la infraestructura como herramientas de código como Puppet, Chef o Ansible para gestionar sus configuraciones antes de invertir en pruebas continuas.

Por último, las pruebas continuas deben ser fáciles de automatizar, ejecutarse en un tiempo razonable, tener criterios definidos de aprobación o rechazo y disponer de rutas bien definidas para solventar los problemas. Por ejemplo, las pruebas funcionales que se ejecutan a través de miles de escenarios de prueba pueden tardar demasiado tiempo en ejecutarse. Podrían funcionar mejor como trabajos programados. Las pruebas de seguridad que reportan muchas alertas deben ser revisadas por el personal de seguridad de la información en lugar de detener la construcción del pipeline. Una prueba de calidad de datos que no puede conectarse fácilmente al código, al desarrollador o al equipo que ha creado el problema no debería estar en el pipeline de CI/CD porque detiene el desarrollo para todos y puede requerir un equipo extenso para revisar el problema. También es importante investigar las mejores prácticas. 

 

Foco en ‘agile’

Una vez que el equipo acuerda abordar una estrategia de testing continuo hay que priorizar el trabajo, considerando tanto los beneficios como las limitaciones de las pruebas propuestas. Las partes interesadas deben priorizar las pruebas recomendadas y clasificar su importancia en función de los riesgos que conllevan. El equipo ágil debe determinar si la prueba es apropiada para integrarse en el pipeline de CI/CD y luego valorar la implementación. Por último, es importante catalogar estas pruebas porque tener demasiadas puede ralentizar los desarrollos o requerir el aumento de la infraestructura necesaria.

Invertir en testing continuo mejora la colaboración en el desarrollo de software y la calidad de éste, pero requiere que los equipos estén alineados en lo que respecta a las prioridades, alcance y detalles de implementación. Seguir una estrategia basada en agile tienen más probabilidades de reducir los riesgos y generar más valor.

 


TE PUEDE INTERESAR...

Forma parte de nuestra comunidad

 

¿Te interesan nuestras conferencias?

 

 
Cobertura de nuestros encuentros
 
 
 
 
Lee aquí nuestra revista de canal

DealerWorld Digital