¿Siguen siendo necesarias las pruebas en DevOps?

Hay cosas que DevOps puede hacer para mejorar las posibilidades de que se realicen pruebas para su(s) aplicación(es). Curiosamente, hay algunos que piensan que ya no necesitamos pruebas; el argumento es que debido a que los nuevos lanzamientos se pueden producir tan rápidamente si es necesario arreglar algo, es irrelevante. Combinando indicadores de funciones con la capacidad de implementar una nueva versión y, bueno, puede haber algo de verdad en eso, al menos para un subconjunto limitado de pruebas.

Si una organización implementara indicadores de características para la aceptación del usuario y la prueba de nuevas características y luego estandarizara el desarrollo basado en pruebas para los equipos de desarrollo de DevOps, eso dejaría las pruebas de sistemas y seguridad. Las pruebas de sistemas podrían, en teoría, ser reemplazadas por la capacidad de implementar una nueva versión. Aunque los problemas sistémicos pueden ser complejos y difíciles de solucionar, esta es una propuesta más arriesgada que extender el desarrollo basado en pruebas al nivel de sistemas. Para el sprint, asigne a una persona responsable del sistema integrado general y haga que el resto del equipo lo apoye en el proceso de asegurarse de que todo funcione como se espera.

Las pruebas, en particular las pruebas de sistemas, retrasan los lanzamientos. Lo entiendo. La velocidad a la que la mayoría de nosotros puede iterar una vez que los sistemas y procesos DevOps están en su lugar es lo suficientemente rápido como para permitirse un poco de desaceleración. Esto deja a las pruebas de seguridad como el último bit independiente. Pero puede ocurrir cierta validación de seguridad durante el proceso de desarrollo si se utilizan las herramientas DevSecOps. Eso todavía deja algunos problemas de seguridad para probar, pero elimina una gran parte.

La clave para estos últimos bits es integrarlos en el proceso/cadena de herramientas. DevOps se ejecuta directamente, una y otra vez. Se ejecutará cualquier parte trabajada en "se ejecuta directamente". Si la iteración de hoy cae en la mentalidad de "Nos atropellamos, cumpliremos la fecha límite con menos pruebas"; no es un problema, es una iteración. Simplemente no permita que se convierta en la respuesta predeterminada para alguien que no completa el trabajo de una iteración a tiempo. El desarrollo puede tener baches de velocidad inesperados que retrasan la entrega y reconocer eso y documentar lo que fue para futuras referencias es importante. Encubrirlo reduciendo el tiempo de prueba pone en riesgo un producto menos estable y no ayuda a superar el problema en el futuro.

Así que empiece a pensar en términos de DevOpsTest. Asegúrese de que el producto que está entregando represente las enormes inversiones de tiempo que ha realizado para producirlo y mantenerlo. Lo estás arrasando, y algo así como las pruebas integradas garantizan que los usuarios vean lo bien que lo estás arrasando y no una página de error.

Descubre la innovación

Para asegurar el éxito empresarial, ahora y a futuro, es imprescindible maximizar el retorno de la inversión existente en software, a la vez que innovar y adoptar nuevas tecnologías. Los retos que hay abordar para competir en un mundo de TI Híbrida incluyen DevOps, Seguridad, Gestión de riesgos y Análisis predictivo. Puedes obtener más información sobre cómo abordar estos retos e innovar en este enlace.