No está solo si su organización ha avanzado a toda velocidad en su estrategia DevOps en los últimos cinco años. Tres cuartas partes de las organizaciones han adoptado un enfoque DevOps, una cifra que se duplicó con creces en los últimos cinco años.
A pesar del crecimiento explosivo de DevOps, solo el 10 % de los encuestados de la Encuesta de Harvard Business Review describen su negocio como "muy exitoso en el rápido desarrollo e implementación de software".
La transformación de DevOps requiere un lanzamiento y una implementación más rápidos, pero aumentar la frecuencia de las compilaciones da como resultado la creación de más pruebas y provoca cuellos de botella en el desarrollo.
Para los equipos en una posición en la que los ciclos de prueba lentos bloquean el desarrollo rápido, el análisis de impacto de prueba es una forma de acelerar el ciclo de desarrollo ejecutando solo las pruebas relevantes para el código fuente modificado.
El análisis de impacto de las pruebas es una forma de acelerar las pruebas de software al ejecutar solo las pruebas que importan para un conjunto de cambios de código. Realizar análisis de impacto de prueba permite a los equipos acelerar su ciclo de desarrollo e implementación al reducir los gastos generales de envío de un cambio.
Tradicionalmente, el análisis de impacto en las pruebas de software a menudo se basa en el análisis estático del código fuente para crear gráficos de dependencia entre el código y las pruebas.
Si no tiene acceso a una herramienta o biblioteca diseñada específicamente para el análisis del impacto de las pruebas, puede realizar un seguimiento manual de los cambios en su base de código y usar esta información para determinar qué pruebas es probable que se vean afectadas.
Por ejemplo, podría mantener una lista de las pruebas asociadas con cada módulo o componente en su sistema y actualizar esta lista a medida que realiza cambios.
Para realizar manualmente el análisis de impacto de la prueba, ejecute cada prueba y cree un mapa de qué código ejerce cada prueba. Una vez que crea el mapa, puede escribir un pequeño programa que se ejecuta cada vez que un desarrollador inserta código.
El programa revisa los archivos modificados y busca qué pruebas necesita ejecutar para el cambio.
Debe actualizar periódicamente el mapa para tener un gráfico de dependencia preciso a medida que el código cambia con el tiempo.
El fragmento de código siguiente asigna los nombres de las pruebas a los componentes con los que están asociados. En este ejemplo, tenemos tres módulos:
Para cada componente modificado, agregue las pruebas a una lista que podemos pasar al marco de ejecución de pruebas.
# Define a dictionary that maps test names to the modules or components they are testing tests_by_component = { "test_login": ["login_module"], "test_account_creation": ["account_creation_module"], "test_password_reset": ["password_reset_module"] } # Define a list of the components that have been modified # This should be dynamically generated based on the code changes. modified_components = ["login_module"] # Determine which tests are likely to be affected by the changes affected_tests = [] for test, components in tests_by_component.items(): for component in components: if component in modified_components: affected_tests.append(test) # Now, we can pass the affected tests to our test harness. print(affected_tests) # Output: ["test_login"]
Cuando se realiza de manera eficiente, el análisis del impacto de las pruebas ofrece una gran cantidad de beneficios, que incluyen:
El análisis de impacto de las pruebas manuales de software puede ser un desafío para hacerlo bien. Ya sea que su proyecto sea un microservicio pequeño o un monolito gigante, la cantidad de datos de prueba con los que necesita trabajar puede aumentar rápidamente.
El análisis de prueba manual rápidamente se vuelve difícil de manejar y aún más desafiante a medida que los desarrolladores agregan nuevas funciones y refactorizan el código con el tiempo.
Para cada línea de código agregada, debe determinar los impactos potenciales y qué pruebas son relevantes para esa línea de código. Muchos equipos de desarrollo informan que seleccionar las pruebas correctas requiere mucho trabajo para realizarlas a escala .
Veamos un escenario muy familiar: un equipo de desarrollo de software en una startup tecnológica mediana ha disfrutado de un crecimiento explosivo en los últimos tres años.
Han alcanzado su Serie C en financiación de capital de riesgo y han utilizado la infusión de efectivo para contratar desarrolladores para crear nuevas funciones rápidamente. La empresa utiliza un modelo ágil centrado en DevOps y se enorgullece de un sólido conjunto de pruebas .
La rápida expansión de la empresa viene con dolores de crecimiento para el equipo de desarrollo. La afluencia de nuevas características significa una afluencia de nuevas pruebas y cambios importantes, lo que a su vez provoca fallas en las pruebas y largos tiempos de ejecución.
Nadie en la startup ya confía en que las fallas sean legítimas, por lo que los desarrolladores presionan repetidamente el botón "volver a ejecutar" hasta que pasan las pruebas. Fusionan los cambios de todos modos cuando no pueden hacer que las pruebas tengan éxito y asumen que el problema está en la prueba, no en su código.
Los desarrolladores desactivan las pruebas que tardan demasiado o que no parecen relevantes para el código: tienen un trabajo que hacer y han comenzado a ver las pruebas de software como una barrera para completar sus tareas.
Los desarrolladores se encuentran en un escenario en el que ya no confían en las pruebas y las desactivan o ignoran arbitrariamente, esencialmente participando en su propia versión arriesgada de selección manual de pruebas.
El equipo de ingeniería está empezando a preocuparse de que este estado de cosas sea insostenible.
¿Cuánto tiempo están perdiendo esperando que se ejecuten las pruebas?
El jefe de ingeniería de la startup decide que es hora de adelantarse a la deuda técnica de DevOps antes de que provoque un incidente costoso.
En lugar de un análisis de impacto de prueba ad hoc impulsado por desarrolladores que intentan acelerar su flujo de trabajo, descubrirán cómo elegir las pruebas que importan para los cambios de código.
La selección de pruebas predictivas es una rama del análisis de impacto de las pruebas que utiliza datos para predecir qué pruebas necesita ejecutar su sistema de CI en función de los resultados de las pruebas históricas y los cambios de código.
Launchable está democratizando el enfoque de selección de prueba predictiva para que esté disponible para equipos de todos los tamaños con solo presionar un botón.
La selección de prueba predictiva de Launchable resuelve el análisis de impacto de prueba aprovechando el poder del aprendizaje automático para agilizar el desarrollo de software. La selección de pruebas predictivas utiliza inteligencia basada en datos para determinar qué pruebas se adaptan mejor a cada tipo de cambio.
Puede reducir la cantidad de ejecuciones de prueba y acelerar el tiempo de entrega con menos recursos desperdiciados.
En ausencia de esta práctica, los equipos deben crear manualmente subconjuntos de " pruebas de humo " o paralelizar sus pruebas.
En el escenario anterior, el equipo de desarrollo de la startup podría beneficiarse de la selección de prueba predictiva. Sus desarrolladores pueden concentrarse en ofrecer las funciones más importantes, acelerar su flujo de trabajo y volver a confiar en el conjunto de pruebas.
Con Launchable, no necesita adivinar qué pruebas se ejecutan y actualizar constantemente su conjunto de análisis de impacto de prueba. Aquí hay un ejemplo de Python de cómo Launchable puede funcionar con el marco Pytest .
Instale pytest-launchable en su entorno con pip3 install pytest-launchable
Genere un archivo de configuración ejecutable ejecutando launchable-config --create
.
Genere una clave API ejecutable desde https://app.launchableinc.com/
Establézcalo como la variable de entorno LAUNCHABLE_TOKEN
en la máquina que ejecutará las pruebas.
Desde el directorio que contiene su archivo de configuración ejecutable, ejecute pytest --launchable <your-pytest-project>
Los resultados de su pytest se informarán a Launchable. Launchable luego comienza a entrenar un modelo de aprendizaje automático en los resultados de su prueba a lo largo del tiempo. El modelo optimiza qué pruebas tienen más probabilidades de ser útiles en el menor tiempo de prueba.
Con la selección de prueba predictiva impulsada por ML de Launchable, los equipos suelen ver una reducción del 60-80 % en los tiempos de prueba sin afectar la calidad .
Las principales razones por las que las organizaciones eligen la función de selección predictiva de Launchable son:
Enviar código más rápido
Vea cómo los ingenieros de todas las industrias están teniendo éxito con Launchable con estos casos de estudio . El análisis del impacto de las pruebas es una herramienta esencial para mejorar la eficiencia del proceso de pruebas. Sin embargo, el análisis manual o estático puede ser engorroso y es posible que no proporcione valor.
La implementación adecuada del análisis de impacto de las pruebas con Predictive Test Selection puede ahorrar tiempo y mejorar la calidad de las pruebas al hacer que su canalización esté más basada en datos.
Launchable se integra a la perfección con su CI, independientemente de la frecuencia de confirmación o la cantidad de sucursales de Git que tenga. Es compatible con todas las aplicaciones e idiomas, y los equipos informan una reducción de hasta el 90 % en los tiempos de prueba sin ningún impacto en la calidad.