X
BLOG

Pruebas 1-2-3 con Mark Lambert de Parasoft: pruebas basadas en cambios y cobertura de código correlacionada combinada

Pruebas 1-2-3 con Mark Lambert de Parasoft: pruebas basadas en cambios y cobertura de código correlacionada combinada Tiempo de leer: 4 minutos

¡Bienvenido a la segunda sesión de Testing 1-2-3! Esta serie presenta conversaciones con líderes de la industria de pruebas de software sobre un amplio espectro de temas de pruebas de software: DevOps, Agile, pruebas de IoT, pruebas de rendimiento, pruebas unitarias, datos de prueba, virtualización de servicios, la nueva función de las pruebas de software, el impacto comercial de la calidad, y más.

La última vez presentamos nuestra sesión inaugural con Theresa Lanowitz de voke, donde discutimos las pruebas continuas, la virtualización de servicios y el nuevo rol de los probadores.

En esta edición de Testing 1-2-3, charlamos con Mark Lambert, Vicepresidente de productos en Parasoft sobre pruebas basadas en cambios, cobertura de código correlacionado combinado y desarrollo ágil.

Pruebas ágiles y basadas en cambios

Prueba 1-2-3:  Aquí en StarWest, todo el mundo habla de cambio. Muchas personas están adoptando nuevas formas de desarrollar y probar software en respuesta a las demandas de una entrega más rápida y una mejor visibilidad de los riesgos asociados con el software que se está lanzando. ¿Cómo ves esto en el campo?

Marca: Lo primero que estoy viendo últimamente es que la gente quiere saber el impacto de los cambios frecuentes que se realizan en sus aplicaciones. Es posible que tenga pruebas que cubran toda la aplicación, pero, especialmente con Continuous Delivery, no puede ejecutar todas esas pruebas para comprender el impacto de cada cambio. Con Agile, todo gira en torno a sprints de 1 o 2 semanas, y estás realmente concentrado en la funcionalidad que se está introduciendo en cada historia de usuario. Por supuesto, valida cada historia y se asegura de que funcione, pero ¿realmente sabe qué más podría haber impactado? Las pruebas exploratorias pueden descubrir algo, pero generalmente no hay una forma metódica de saber si esos cambios tuvieron efectos secundarios peligrosos.

Prueba 1-2-3:  Entonces, en otras palabras, el desafío de hoy es obtener retroalimentación en el momento del cambio para que sepa si puede avanzar con confianza o no.

Marca: Sí, se trata del alcance del impacto.

Prueba 1-2-3:  Interesante. ¿Cómo puede la gente dar los primeros pasos hacia la transición a este nuevo paradigma?

Marca: Creo que el primer paso es obtener más información. Si carece de algunos de los datos subyacentes en torno a sus prácticas de prueba existentes, ¿cómo puede esperar que evolucionen, se vuelvan ágiles y se aprovechen de tal manera que lo ayuden a mitigar el riesgo de cada versión candidata?

Cobertura de código combinada y correlacionada

Prueba 1-2-3:  ¿Puede darnos un ejemplo de esos datos?

Marca: Un ejemplo es comprender qué partes del código se ven realmente afectadas por casos de prueba específicos. A general-MarkL_Drawing.jpgParasoft, una de las cosas en las que nos enfocamos es ayudar a las organizaciones a obtener esa trazabilidad de la prueba: la capacidad de comprender qué código realiza una prueba en particular. La mayoría de las personas están familiarizadas con la medición de la cobertura a nivel de unidad, pero también desea obtener un nivel granular de cobertura de código para sus pruebas manuales y automatizadas.

Prueba 1-2-3: Pero todas esas son prácticas separadas realizadas en momentos separados a lo largo de diferentes fases del SDLC. Tienes a alguien haciendo pruebas unitarias cuando cambia el código (o tal vez incluso antes de que cambie el código, si están adoptando un enfoque TDD), tienes a alguien realizando pruebas de componentes y tienes un grupo diferente de personas que vienen para realizar pruebas de escenarios basado en el requisito o en la propia historia del usuario. Ante todo esto, ¿cómo se determina qué nivel de cobertura se logró realmente?

Marca: Aunque todas estas prácticas solían estar muy aisladas en diferentes partes del SDLC, ahora están realmente condensadas en un sprint particular. Debe poder agregar los datos de prueba y la información de cobertura de todas estas técnicas diferentes que se realizan simultáneamente en una compilación en particular. La correlación es vital ... reúne todos estos datos, los correlaciona con la compilación específica que pasa por el proceso de verificación y luego fusiona la cobertura a través de esas diferentes técnicas. En Parasoft, a esto lo llamamos cobertura correlacionada fusionada.

Release = MC2 (Cobertura correlacionada fusionada)

¿Quiere saber cómo la combinación y la correlación de la cobertura de código de una variedad de técnicas de prueba puede ayudar a su organización a comprender y mitigar los riesgos asociados con una versión determinada? Lea nuestro documento técnico, Cobertura integral del código: cobertura agregada en todas las prácticas de prueba.

dtp -cover-dash.pngAprenderá cómo la cobertura de aplicaciones ayuda a los equipos a cumplir sus objetivos de lanzamiento, que incluyen:

  • Cómo la cobertura de la aplicación ayuda a mitigar el riesgo asociado con la entrega acelerada
  • Cómo cobrar la cobertura de la solicitud
  • Cómo fusionar y correlacionar la cobertura de código de una variedad de técnicas de prueba
  • Cómo la cobertura de aplicaciones puede ayudar a las organizaciones críticas para la seguridad a lograr la trazabilidad necesaria para cumplir con los objetivos de cumplimiento
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