Exploración del desplazamiento de pruebas a la izquierda
Las pruebas en la administración del ciclo de vida de las aplicaciones son esenciales para maximizar la calidad del código y minimizar el riesgo operativo asociado a la implementación y actualización de software. El término desplazamiento a la izquierda en este contexto transmite la idea de mover las actividades de prueba lo antes posible en la fase de desarrollo. La organización de nuestro escenario de ejemplo debe considerar la posibilidad de incorporar este enfoque en su estrategia de DevOps para minimizar los problemas actuales de seguridad y estabilidad. En esta unidad, revise diferentes tipos de pruebas que se podrían implementar de esta manera y, a continuación, examine sus métodos de implementación.
¿Qué pruebas deberían formar parte del desplazamiento de pruebas a la izquierda?
El desarrollo de software incorpora una amplia gama de tipos de prueba, pero los de un interés particular para nosotros incluyen:
pruebas unitarias: estas pruebas se centran en las partes más pequeñas que se pueden probar de un código de aplicación, como funciones o métodos individuales. El objetivo es establecer si cada unidad de código puede realizar correctamente su operación prevista de forma aislada del resto del código base y las dependencias externas. Estas pruebas deben estar totalmente automatizadas, rápidas (completadas en un plazo de 30 segundos) y proporcionar cobertura de código completa (lo que básicamente significa que todas las pruebas unitarias deben probar colectivamente todo el código base). Las pruebas unitarias son adecuadas para el enfoque del desplazamiento a la izquierda. Se recomienda aplicarlo a todo el código lo antes posible en el ciclo de desarrollo, preferiblemente al principio de la fase de programación.
pruebas de humo: estas pruebas están diseñadas para evaluar la funcionalidad básica de una aplicación en un entorno de prueba. Aunque prueban la aplicación real (en lugar de sus componentes aislados individuales, como hacen las pruebas unitarias), su propósito es determinar si la compilación o implementación de la aplicación es lo suficientemente estable para garantizar pruebas más detalladas. Sin embargo, no comprueban la interoperabilidad entre aplicaciones. Al igual que con las pruebas unitarias, deben estar totalmente automatizadas y relativamente rápidas (la interacción del usuario se puede simular mediante herramientas de automatización de exploradores y marcos de automatización de interfaz de usuario). El término prueba de humo se utiliza para transmitir la idea de que el humo indica un problema importante (incendio) que debe abordarse lo antes posible. Las pruebas de humo también deben implementarse al principio del ciclo de desarrollo, preferiblemente en cuanto esté disponible una versión del software que proporcione su funcionalidad principal. Esto se aplica a las fases de compilación e implementación de la aplicación.
pruebas de integración: estas pruebas validan la interacción entre distintos componentes de la aplicación. A diferencia de las pruebas unitarias, pueden tardar mucho tiempo en completarse. La duración extendida de estas pruebas se usa normalmente como argumento para ejecutarlas al principio del ciclo de vida de desarrollo de software. En general, debe considerar las pruebas de integración en escenarios para los que las pruebas unitarias o de humo no son adecuadas. Sin embargo, la recomendación es programarlas para que se ejecuten en intervalos regulares. Este enfoque ofrece un compromiso razonable entre un posible retraso en la detección de problemas de integración y un tiempo de espera adicional necesario para resolverlos.
pruebas de aceptación: estas pruebas determinan si un producto de software cumple los requisitos empresariales y está listo para una entrega a sus consumidores. Las pruebas de aceptación no son adecuadas para la estrategia de desplazamiento a la izquierda, pero es posible incorporar algunos de sus elementos al principio del ciclo de vida de desarrollo de software. Por ejemplo, los criterios de aceptación y los casos de usuario, que son componentes esenciales de las pruebas de aceptación, deben introducirse al principio del proceso de desarrollo. Esto facilita la colaboración entre los equipos de desarrollo, los propietarios de productos y las partes interesadas del proyecto. Además, los consumidores de software y las partes interesadas del proyecto deben participar en las fases de prueba anteriores para compartir sus comentarios. Esto puede implicar el uso de métodos como pruebas alfa o beta, pruebas de facilidad de uso o versiones tempranas, antes de las pruebas de aceptación formales.