X
BLOG

DevOps trae impactos a escala de El Niño a las pruebas de software

DevOps trae impactos a escala de El Niño a las pruebas de software Tiempo de leer: 4 minutos

¡Slams! ¡Abruma! ¡Causa estragos!

Ese es el tipo de lenguaje que se usa en los titulares de hoy que describen el primer avance de El Niño en California, y es igualmente aplicable al impacto de DevOps en las pruebas de software.

Con DevOps, la avalancha constante de nuevas funcionalidades crea sin lugar a dudas una interrupción torrencial de las pruebas tradicionales. Muchos equipos apenas mantienen la cabeza fuera del agua tratando de asegurarse de que cada nuevo requisito realmente funcione antes de su implementación. Entonces, ¿cómo puede asegurarse de que cada “pequeño cambio” no introduzca efectos secundarios que afecten a la aplicación y hagan que el usuario final se sienta más frustrado que un conductor en una autopista inundada de California?

¿Cómo se ven afectadas las pruebas de software por DevOps y Agile?

Tradicionalmente, las pruebas han sido un evento de tiempo limitado. Esperaría el desarrollo para producir una compilación viable, luego hubo un momento para que QA ejercitara lo que necesitaban para probar. Cuando sintieron que habían "terminado las pruebas" o se les acabó el tiempo, las pruebas se detuvieron.

Con el auge de Agile y DevOps, sucedieron dos cosas principales:

  • El tiempo de ciclo tardío (que ya se está reduciendo) dedicado a ejercitar la aplicación desapareció por completo.
  • Los métodos de prueba predominantes (pruebas manuales y pruebas de GUI) se volvieron obsoletos porque eran demasiado lentos, consumían mucho tiempo, eran costosos y frágiles para un mundo de iteraciones cortas y cambios constantes.

Para publicar con confianza a pesar de la velocidad y frecuencia de los ciclos de lanzamiento de hoy, debemos dejar de preguntar "¿Hemos terminado las pruebas" y cambiar el enfoque a "¿El candidato de lanzamiento tiene un nivel aceptable de riesgo comercial?" Si podemos responder a esta pregunta, podemos determinar si la aplicación está realmente lista para avanzar en el proceso de entrega.

Dado el costo creciente y el impacto de las fallas de software, las organizaciones ya no pueden permitirse lanzar una versión que podría interrumpir la experiencia del usuario existente o introducir nuevas características que exponen a la organización a nuevos riesgos de seguridad, confiabilidad o cumplimiento. Para evitar esto, la organización debe extenderse desde la validación de los requisitos ascendentes hasta la evaluación de los requisitos del sistema asociados con los objetivos comerciales generales, por ejemplo, a través de las pruebas continuas.

¿Qué implica pasar de las pruebas automatizadas a las pruebas continuas?

La automatización de las pruebas es un paso fundamental para avanzar hacia las pruebas continuas. Sin embargo, si una de sus pruebas automatizadas falla, ¿sabe lo que realmente significa? ¿Indica un riesgo comercial crítico o simplemente una violación de algún estándar de nomenclatura que nadie está realmente comprometido a seguir de todos modos? ¿Y qué pasa cuando falla? ¿Existe un flujo de trabajo claro para priorizar los defectos frente a los riesgos comerciales y abordar primero los más críticos? Y para cada defecto que amerite reparación, ¿existe un proceso para exponer todos los defectos similares que ya se hayan introducido, así como para evitar que este mismo problema vuelva a ocurrir en el futuro? Aquí es donde se hace evidente la diferencia entre automatizado y continuo.

evolucionar de pruebas automatizadas a pruebas continuas, necesitas lo siguiente:

  1. Expectativas comerciales claramente definidas, con riesgos comerciales identificados por aplicación, equipo y lanzamiento.
  2. Los defectos se priorizan automáticamente frente a los impulsores del negocio y saben cómo mitigar esos riesgos antes de que la versión candidata entre en funcionamiento.
  3. Realizar pruebas en entornos de prueba completos mediante simulación continua: esto es fundamental para proteger la experiencia del usuario actual del impacto del cambio.
  4. Circuito de retroalimentación para la prevención de defectos: buscar patrones que surjan y utilizarlos como una oportunidad para diseñar e implementar prácticas de prevención de defectos que eviten que se introduzcan defectos similares.

¿Las pruebas manuales tienen un lugar en DevOps?

En pocas palabras, necesita automatizar tanto como sea posible. La automatización debe convertirse en la norma para las pruebas modernas. Dicho esto, algunas cosas no se pueden automatizar, por lo que cierto grado de prueba manual puede ser inevitable. Para asegurarse de que las pruebas manuales no se conviertan en un cuello de botella en su canal de entrega, debe asegurarse de que esté fuera de su ruta crítica; haga todo lo que requiera su proceso y sus recursos lo permitan, pero no lo convierta en una puerta en su camino. proceso de entrega automatizado.

¿Cómo debe evolucionar el concepto de "QA" para DevOps?

Aunque el término "QA" se deriva de "garantía de calidad", el papel de QA en los equipos de desarrollo de software se ha centrado más o menos en las pruebas tácticas. Para que las iniciativas de procesos colaborativos más modernas (DevOps, lean, ágil ...) se afiancen, el papel de QA debe volver al aseguramiento de la calidad. En este caso, QA es responsable de definir y habilitar un proceso continuo y proactivo que identifica y previene los riesgos comerciales a lo largo del ciclo de vida del software.

Si QA = Quality Assurance, entonces QA se enfoca en crear y administrar scripts de prueba funcional parece extraño; esta tarea no es preventiva ni está orientada a procesos. El concepto de calidad y cómo se define es una responsabilidad organizacional y empresarial que debe reflejarse en la cultura de la empresa. Las pruebas son solo una de las muchas actividades que garantizan que se logren los objetivos de calidad de la organización.

¿Cómo encajan las tecnologías de simulación en DevOps y las pruebas continuas?

Una vez que las organizaciones comienzan a acelerar su canalización de entrega de software para Agile y DevOps, a menudo llegan al punto en el que necesitan realizar pruebas, pero no pueden ejercer la AUT porque aún no está listo un entorno de prueba completo. Muchos equipos utilizan tecnologías de simulación como EaaS y virtualización de servicios para sortear estos obstáculos.

Para proteger verdaderamente la experiencia del usuario final, debemos probar y defender de manera agresiva la experiencia del usuario final en todas las transacciones clave de un extremo a otro. Con los sistemas actuales, esas transacciones pasan por una gran cantidad de componentes diferentes, por lo que es muy difícil acomodar eso en un único entorno de prueba por etapas, en la nube o no. La simulación nos ayuda a solucionar esto. Para obtener el entorno simulado más realista, necesitamos comprender realmente cómo funcionan los componentes en un entorno operativo y transferir esto a la simulación.

¿Cuál es la diferencia entre “entornos como servicio” y “virtualización de servicios”?

Las pilas de aplicaciones que están bajo su control (listas para la nube) se pueden importar y crear imágenes a través de un elástico. EaaS en una nubeVirtualización de servicios luego le permite simular el comportamiento de aquellas dependencias que no puede visualizar fácilmente (por ejemplo, servicios de terceros, regiones SAP, mainframes, API aún no implementadas, etc.), o aquellas que desea estabilizar para propósitos de cobertura de prueba.

El resultado es que los equipos de TI o los administradores del entorno pueden configurar fácilmente entornos completos de desarrollo y pruebas que los evaluadores y los desarrolladores pueden configurar y aprovisionar de forma rápida (y simultánea) a pedido.

Escrito por

Parasoft

Las herramientas de prueba de software automatizadas líderes en la industria de Parasoft respaldan todo el proceso de desarrollo de software, desde que el desarrollador escribe la primera línea de código hasta las pruebas unitarias y funcionales, hasta las pruebas de rendimiento y seguridad, aprovechando los entornos de prueba simulados en el camino.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft