Vea qué solución de pruebas de API resultó ganadora en el informe GigaOm Radar. Obtenga su informe analítico gratuito >>

Vea qué solución de pruebas de API resultó ganadora en el informe GigaOm Radar. Obtenga su informe analítico gratuito >>
Saltar a la sección
Tener visibilidad de las métricas clave ayuda a los equipos de desarrollo y pruebas a tomar decisiones bien informadas para lanzar software de alta calidad a tiempo y dentro del presupuesto. Siga leyendo para saber qué métricas son importantes para realizar un seguimiento.
Saltar a la sección
Saltar a la sección
Conducir un automóvil sin visibilidad clara no solo es peligroso sino también imprudente. Te pone a ti y a todos los que te rodean en riesgo de colisiones, lesiones e incluso muertes. Sin poder ver el camino por delante, no puede anticipar peligros u obstáculos potenciales, lo que hace imposible tomar decisiones informadas y tomar las medidas adecuadas.
Del mismo modo, desarrollar software sin agregar visibilidad al proceso es como conducir a ciegas. Las métricas de software proporcionan la visibilidad necesaria para identificar posibles problemas de calidad y seguridad que necesitan atención inmediata para que pueda decidir cuándo seguir esforzándose y cuándo reducir la velocidad.
Yendo un paso más allá, el análisis y el software inteligente lo ayudan a:
Todo esto ayuda a los equipos a:
Los proyectos de software modernos generalmente se planifican sopesando el costo de las historias de usuario que se comprometerán con la capacidad del equipo. Por lo general, estas historias se capturan en herramientas como Jira, GitHub o Azure DevOps.
Los gerentes de producto negocian con los gerentes de desarrollo para determinar qué se puede hacer de manera realista en el ciclo de lanzamiento actual. A continuación, los gerentes de desarrollo pueden planificar en función de:
Los planes, por supuesto, están sujetos a cambios. La mayoría de los proyectos de software se encuentran con problemas o obstáculos que pueden alterar el resultado del plan. Las vulnerabilidades de seguridad en particular pueden ser un revés importante. Las interrupciones son inevitables, pero sin poder medir el impacto, se vuelve difícil controlar el proyecto.
La visibilidad es esencial para el desarrollo de software. Las herramientas de monitoreo y análisis brindan información para tomar decisiones seguras y efectivas.
El acceso rápido a las métricas de desarrollo de software en un tablero fácil de usar es importante para comprender el desarrollo de software estado y progreso. Tener acceso rápido a través de herramientas visuales como tableros permite a los equipos de desarrollo Agile:
Las métricas generalmente se recopilan en puntos donde automatización de pruebas de software las herramientas están “tocando” el código. Normalmente, la recopilación se produce durante el análisis estático y la ejecución de pruebas. Los detalles recopilados pueden tener referencias cruzadas, por ejemplo, a archivos, pruebas particulares, vulnerabilidades de seguridad o debilidades de software conocidas y requisitos.
Cuando comencé como desarrollador, era escéptico acerca de los beneficios del análisis estático. Lo hice simplemente porque era una política de la empresa. Con los años, he llegado a apreciar sus beneficios. El análisis estático detecta constantemente ciertos problemas que de otro modo no se habrían detectado y que se han manifestado como defectos para los clientes. Los beneficios superan los inconvenientes de tener que suprimir los inevitables falsos positivos del análisis estático.
El análisis estático ayuda a cambiar las consideraciones de seguridad y calidad del código antes en el ciclo de vida del desarrollo de software, lo que permite a los desarrolladores abordar los problemas antes de que se vuelvan más costosos y requieran más tiempo para solucionarlos.
By integración de análisis estático en el proceso de desarrollo, los desarrolladores pueden identificar y solucionar problemas de seguridad antes de que afecten a los usuarios finales. Para ciertas industrias críticas para la seguridad, el análisis estático es imprescindible para mantener su base de código en conformidad con los requisitos de codificación y las pautas de la industria.
Las métricas del análisis estático pueden proporcionar información valiosa sobre el estado de la postura de seguridad y calidad de la aplicación, lo que ayuda a las organizaciones a planificar mejor sus esfuerzos de desarrollo de software. Las métricas como la cantidad de defectos, su gravedad y su ubicación dentro de la base de código pueden ayudar a los equipos a priorizar los problemas y asignar los recursos en consecuencia. Puede realizar un seguimiento del progreso a lo largo del tiempo e identificar áreas de mejora.
El análisis estático también ayuda al cumplimiento de los estándares. Las métricas recopiladas proporcionan a las organizaciones los datos que necesitan para demostrar Cumplimiento de estándares industriales o regulatorios..
Los resultados de las pruebas son las métricas más importantes (sí, las más importantes) para los equipos de desarrollo de software. Si las pruebas fallan, algo anda mal y requiere atención inmediata. Hay diferentes tipos de pruebas. Los equipos deben recopilar y revisar las métricas de cada tipo todos los días.
Las pruebas unitarias son los componentes básicos de su conjunto de pruebas. Los principales beneficios son:
Las pruebas de integración determinan si las unidades de software desarrolladas de forma independiente funcionan correctamente cuando están conectadas entre sí. Pruebas de API son un tipo de prueba de integración.
Hay una frase que es popular en el desarrollo de software: integre temprano, integre a menudo.
Las pruebas de integración son imprescindibles para aprovechar al máximo esta práctica. Son más difíciles de escribir que las pruebas unitarias. Sin embargo, aprovechar una buena herramienta o marco de prueba definitivamente ayuda. Y se necesita más trabajo para medir la cobertura del código mientras se ejecutan pruebas de API o de integración.
Las pruebas de interfaz de usuario son otro tipo de prueba que conduce la aplicación a través de la interfaz de usuario. Estos son valiosos. Si puede automatizar las pruebas de IU, evitará que su equipo tenga que ejecutar pruebas manuales una y otra vez.
Estas pruebas son las más difíciles de escribir y pueden ser costosas de mantener. Ejecutarlos también requiere una inversión en una infraestructura de prueba donde pueda ejecutarlos con ciertos navegadores o en modo autónomo. Medir la cobertura del código también requiere inversión.
Tenga en cuenta que Parasoft ofrece herramientas y marcos para cada uno de estos tipos de pruebas, lo que le facilita escribir y mantener estas pruebas, así como medir la cobertura del código mientras las ejecuta.
Por último, las pruebas manuales requieren que su equipo de control de calidad (QA) valide manualmente la funcionalidad del software desde la perspectiva del usuario final. Los resultados de las pruebas manuales pueden proporcionar información sobre la usabilidad y la experiencia del usuario del software, destacando las áreas en las que pueden ser necesarias mejoras.
La cobertura de código es una métrica que va de la mano con los resultados de su prueba. Es posible que tenga un 100% de aprobación de las pruebas, pero si solo se prueba el 5% de su base de código, todavía está conduciendo a ciegas.
Antes de un viaje por carretera, se sentiría más seguro si su automóvil pasara una inspección de 150 puntos en lugar de solo una inspección de 10 puntos. De la misma manera, la cobertura de código es una métrica útil que se correlaciona con la profundidad y la calidad de su conjunto de pruebas.
¿Qué es una buena cobertura? Eso depende.
Si está comenzando un nuevo proyecto, es razonable apuntar a una cobertura de código del 80 % o más desde el principio. Esto significará que se prueba el 80% de su base de código. Si su base de código es una combinación de código nuevo y código heredado, puede ser difícil aplicar una cobertura de código del 80 %. En este caso, puede realizar un seguimiento de otras dos métricas:
Si su cobertura de código general es baja cuando comienza, digamos un 10 %, puede que no sea razonable tratar de llegar al 80 % de cobertura de código. Sin embargo, es razonable asegurarse de que la cobertura de su código siempre mejore con el tiempo.
Mejora la cobertura del código con el tiempo mediante el seguimiento de la tendencia. Junto con eso, una práctica que recomienda Parasoft es medir la cobertura del código modificado. Este es un subconjunto de su cobertura de código general: solo la cobertura de código del código que ha cambiado desde que comenzó a medir la cobertura de código.
Parasoft recomienda establecer una meta del 80 % de cobertura de código modificado. Al adoptar esta práctica, puede asegurarse de que su cobertura de código general siga mejorando hacia ese objetivo del 80 %, incluso si comienza con una cobertura de código general baja.
Para muchas organizaciones, medir la cobertura de la línea puede ser suficiente. Pero para ciertas industrias críticas para la seguridad, la cobertura de la línea de medición no es suficiente. Los estándares de seguridad como ISO 26262, IEC 62304 y DO-178C requieren evidencia de métricas de cobertura de código suficientes, como declaración, rama, MC/DC y otras. Las herramientas que están certificadas por TÜV SÜD para estos estándares, como Parasoft C/C++test, tienen la capacidad de medir métricas de cobertura de código avanzadas.
Ahora que sabe qué métricas son importantes para realizar un seguimiento, desea una visibilidad fácil y rápida de estas métricas. Parasoft DTP es un tablero y una herramienta de informes que le brinda visibilidad de todas estas métricas, para que no tenga que conducir a ciegas.
Los equipos de desarrollo pueden usar tableros como este durante las reuniones diarias y para mostrar el estado de calidad del proyecto a las partes interesadas durante las revisiones de sprint.
Los equipos de calidad y cumplimiento pueden usar tableros para monitorear continuamente sus esfuerzos de cumplimiento de ciertos estándares de la industria. Haga un recorrido rápido por DTP para ver cómo los equipos de desarrollo obtienen una visibilidad completa.
Cuando tenga visibilidad de las métricas clave de calidad, no tendrá que conducir a ciegas. En cambio, en cada paso, puede tomar decisiones bien informadas que muestren resultados.
¿Por qué conducir a ciegas cuando se puede tener visibilidad?