Métricas que importan para las pruebas de extremo a extremo

¿Cómo se mide la calidad del software?

A partir de los resultados de múltiples encuestas de mercado, está claro que los ejecutivos de la industria están de acuerdo en que la calidad del software es una prioridad principal para brindar valor comercial a los clientes. El desafío es cómo definir qué significa eso y cómo lograrlo. Esto implica seleccionar y aplicar métricas apropiadas a sus procesos de desarrollo y prueba de software.

Una forma de mejorar la calidad del software es agregar la automatización de pruebas a su flujo de trabajo de desarrollo. Esto le permite cambiar las pruebas más temprano en el ciclo de vida, encontrando y corrigiendo errores antes con pruebas más sólidas que las que se pueden realizar manualmente. Las pruebas de extremo a extremo implican la aplicación de múltiples técnicas de prueba para abordar todas las facetas de la aplicación, desde el código, pasando por las API, hasta la interfaz de usuario.

Recientemente, tuvimos la oportunidad de hablar con Diego Lo Giudice, vicepresidente y analista principal de Forrester Research, sobre sus pensamientos sobre las métricas para la calidad del software. Sus conocimientos expertos se presentan aquí y se comparten en la repetición del seminario web a pedido, Ofrezca experiencias superiores con pruebas y métricas integrales que importan.

Preguntas y respuestas sobre las pruebas de extremo a extremo

Con el invitado destacado Diego Lo Giudice, vicepresidente y analista principal de Forrester Research

P: En el seminario web, Ofrezca experiencias superiores con pruebas y métricas integrales que importan, mencionó que Agile y DevOps son dos caras de la misma moneda. ¿Cómo ayudan estas prácticas a las empresas a aplicar e integrar las pruebas de extremo a extremo en sus Flujo de trabajo de CI/CD?

A: Agile y DevOps son dos caras de la misma moneda, lo que significa que uno no puede prescindir del otro.

¿Por qué?

Porque si Agile ayuda a derribar el muro entre los equipos de desarrollo y el negocio y acelera las cosas mientras se alinea con los requisitos, DevOps continúa el trabajo entre los equipos de desarrollo y las operaciones de I&O. Agile + DevOps brinda una agilidad comercial completa de extremo a extremo.

Desde una perspectiva organizativa y práctica, Agile + DevOps debe soportar cambiar las pruebas a la izquierda y convertirlas en parte de lo que se debe hacer en el sprint. De lo contrario, la entrega/implementación continua no puede ocurrir. Las pruebas realizadas tarde interrumpirán el ciclo continuo de DevOps.

El uso de herramientas de CI/CD en Agile + DevOps ahora puede orquestar un flujo de trabajo donde el código se registra, se ejecutan pruebas unitarias, se ejecutan pruebas funcionales, se ejecutan pruebas de rendimiento y en cada paso, según la cobertura y aprobado vs no aprobado pruebas, se pueden tomar decisiones automáticas para empujar el código hacia adelante o hacia atrás para que el equipo lo corrija y pruebe más.

Así que ahora puede ver que hemos reemplazado lo que solía ser un largo proceso de gobierno manual con un flujo de trabajo de prueba automatizado de extremo a extremo, que normalmente habría sido una gran cantidad de traspasos, reuniones de lanzamiento y más para hacer lo mismo. Reduce el tiempo del ciclo de prueba al automatizar el gobierno. Esa es la ayuda que obtienen las empresas.

P: Al principio de la presentación, notó que la calidad del software es una preocupación ejecutiva. ¿De qué manera pueden TI y los ejecutivos medir y cuantificar la calidad de manera más efectiva? ¿Cuáles son algunas de las métricas más importantes para las pruebas y la calidad del software?

A: En la investigación de métricas de aplicaciones modernas que realmente importan, las métricas de resultados más importantes se centran en el valor empresarial. Sin embargo, lo que conduce al valor comercial son las métricas de calidad.

Las métricas de calidad más importantes siguen siendo métricas que miden la calidad del software en producción: defectos escapados. Nadie quiere que los defectos lleguen a la producción porque causan pérdida de ingresos, aparecen en las noticias con una mala reputación e impactan en la experiencia del usuario.

Las métricas habituales para rastrear incluyen defectos de densidad de código a nivel de prueba unitaria, defectos escapados desde el desarrollo hasta la prueba, tiempo de ejecución de automatización de prueba, número de fallas en la prueba de confirmación y número de fallas en la prueba de automatización. Yo agregaría a cada una de ellas “tendencias”.

¿Está disminuyendo la tendencia de la velocidad de ejecución de pruebas automatizadas? En caso afirmativo, eso podría ser una indicación de problemas en las pruebas.

P: También habló sobre evitar un "mar de métricas". Entonces, ¿cómo puedo saber si tengo demasiados? ¿Cómo sé cuáles podar?

A: Ahí es donde entran los marcos como OKR (resultados clave objetivos) o GQM (objetivo, pregunta, métrica). Siguiendo el principio de que no puede administrar lo que no mide, debe decidir qué necesita administrar.

¿Cuáles son los objetivos del equipo (o los objetivos del producto)? A partir de ahí, obtenga las métricas útiles que necesita. No tiene sentido tener métricas de rendimiento si el rendimiento no es el principal dolor que tiene su negocio y, por lo tanto, no es una meta para la organización.

Si, por el contrario, el problema son los errores técnicos, es posible que desee incluir la cobertura de pruebas unitarias en el tablero y pasar las métricas.

P: ¿Cómo pueden ayudar las métricas significativas a justificar el valor de la automatización de pruebas?

A: Normalmente, según el marco mencionado anteriormente, la calidad es una métrica líder que contribuye al valor comercial. Ese es un punto de partida para acordar con las partes interesadas. Entonces, como consecuencia, reemplazar las pruebas manuales con pruebas automatizadas acelerará el ciclo de entrega, porque también disminuye el tiempo del ciclo de ejecución de la prueba.

El tiempo total del ciclo de desarrollo, incluso desde el efectivo hasta el código, se verá afectado positivamente por la automatización de pruebas. La calidad también aumenta si la automatización es correcta porque puede ejecutar las mismas pruebas (piense en la regresión) una y otra vez. Construyes una vez pero ejecutas muchas veces. Sin embargo, tenga en cuenta lo difícil que puede ser la automatización, ya que el código y los sistemas mal codificados pueden ser difíciles de realizar pruebas unitarias. O si no es necesario repetir una prueba, ¿por qué automatizarla? Aunque esto rara vez sucede, especialmente en Agile.