KPI para pruebas de software: garantía de calidad para su producto

Desarrollar un software que resuelva un punto de dolor para el usuario es, sin duda, la base del éxito de un producto de software. Sin embargo, hay otro aspecto de suma importancia: las pruebas de software. A menudo se descuidan las pruebas de software, a pesar de que el resultado de las mismas determina si su producto destaca entre la competencia... o no.

En este artículo analizaremos la importancia de las pruebas de software y cómo medir si el desarrollo de su producto va por buen camino. Le presentaremos los indicadores clave de rendimiento (KPI) más destacados para probar el software que desarrolla, ilustraremos la teoría de las pruebas de software con un ejemplo práctico y le proporcionaremos información importante sobre cómo puede obtener una ventaja competitiva probando su software.

Indicadores clave de rendimiento (KPI) para pruebas de software

Hay muchos KPI que reflejan el éxito de los procesos de prueba. En aras de la brevedad y de una priorización implícita, hemos seleccionado los más importantes de estos KPI. He aquí nuestra selección:

KPI 1 "Cobertura de las pruebas de requisitos" - Requisitos para el alcance de las pruebas

La cobertura de las pruebas de requisitos mide el grado en que los casos de prueba ejecutados durante las pruebas cubren el conjunto de requisitos funcionales y no funcionales especificados para la Software cubierta. Un requisito previo para la aplicabilidad de este ratio es que los requisitos del software estén completamente especificados.

Interpretación y aplicación de la cobertura de las pruebas como KPI:

  • Este KPI garantiza que cada requisito está vinculado al menos a un caso de prueba que lo comprueba. Es importante tener en cuenta que cada requisito puede ser comprobado por varios casos de prueba. Al mismo tiempo, una prueba también puede comprobar varios requisitos de software. Esto significa que existe una relación de muchos a muchos entre los casos de prueba y los requisitos.
  • Una cobertura del 100% de las pruebas de requisitos no significa que no haya otras pruebas posibles que puedan escribirse. Sólo significa que cada requisito está vinculado al menos a un caso de prueba. Sin embargo, no hay garantía de que este caso de prueba cubra toda la especificación del requisito.
  • No lo olvides: si cambian los requisitos del software, también deben cambiar los casos de prueba.
  • Para aplicar este KPI, debe Herramientas de trazabilidad para vincular los casos de prueba y los requisitos entre sí. Esta trazabilidad ayuda a saber qué requisitos se han probado ya y cuáles quedan pendientes. Esta trazabilidad mide la cobertura en porcentaje.

Ejemplo "Requisitos Cobertura de pruebas"

Usted desempeña un alto cargo en una empresa de comercio electrónico que está planeando una importante actualización de su plataforma de comercio electrónico para mejorar la experiencia del cliente. Para ello es necesario definir requisitos funcionales y no funcionales. Como parte del Proceso de garantía de calidad es crucial garantizar que todos los requisitos se comprueban adecuadamente.

Su equipo de desarrollo utiliza herramientas de trazabilidad para vincular los casos de prueba y los requisitos. Esto le permite medir la cobertura de las pruebas y asegurarse de que cada requisito está cubierto por al menos un caso de prueba.

Tras realizar las pruebas y relacionar los requisitos y los casos de prueba, se da cuenta de que la cobertura de las pruebas es de 90%. Esto significa que al menos un caso de prueba ha comprobado 90% de los requisitos especificados. Es un buen resultado, pero indica que aún se puede mejorar.

Al analizar la cobertura de las pruebas, observa que algunos de los requisitos no funcionales, como el rendimiento de la plataforma con cargas elevadas, aún no se han probado suficientemente. En este caso, debe asegurarse de que se crean casos de prueba adicionales para cubrir estos requisitos específicos. Además, resulta que algunos de los casos de prueba cubren múltiples requisitos y viceversa. Esto ilustra la relación de muchos a muchos entre casos de prueba y requisitos. Si se producen cambios en los requisitos durante el desarrollo, habrá que adaptar los casos de prueba en consecuencia para garantizar que la cobertura de las pruebas de requisitos se mantiene actualizada.

El uso de herramientas de trazabilidad y la comprobación periódica de la cobertura de las pruebas de requisitos garantizan que la plataforma de comercio electrónico cumple los requisitos especificados y que los posibles problemas se detectan y rectifican en una fase temprana. Una cobertura de las pruebas de requisitos de 100% no significa necesariamente que no sea necesario realizar más pruebas, sino que cada requisito se ha comprobado al menos una vez.

KPI 2 "Cobertura del código" - Cobertura del código

La cobertura del código mide qué parte del código fuente, incluidas las líneas de código, las instrucciones, las ramas y las rutas, se ha ejecutado realmente en las pruebas.

Interpretación y aplicación de la cobertura de código como KPI:

  • La cobertura del código suele expresarse en porcentaje, por ejemplo 20% o 90%. Un porcentaje más alto implica pruebas más exhaustivas. No existe una cifra clara que pueda fijarse como objetivo normalizado, pero si el porcentaje es superior a 70%, se trata de un buen valor.
  • Las herramientas de cobertura del código suelen resaltar las líneas o ramas específicas del código que no fueron ejecutadas por sus pruebas.
  • Si identifica áreas de código sin descubrir, puede utilizar esta información para cerrar las brechas de las pruebas. También es posible crear casos de prueba adicionales o modificar los existentes para probar estas rutas de código no descubiertas.

Ejemplo "Cobertura del código"

Su plataforma de comercio electrónico se ha actualizado recientemente, añadiendo nuevas funciones y cambiando algunas características existentes. Como parte de su proceso de garantía de calidad, es importante asegurarse de que todo el código ha sido suficientemente probado, especialmente después de este tipo de actualizaciones.

Su equipo de desarrollo utiliza una herramienta de cobertura del código para asegurarse de que los casos de prueba recorren el código a fondo. Después de Actualización realizas un análisis de cobertura del código y te das cuenta de que la cobertura del código es sólo de 65%. Esto significa que sólo 65% del código fuente ha sido recorrido por tus casos de prueba.

La herramienta de cobertura del código destaca las líneas y ramas específicas del código que no han sido ejecutadas por las pruebas. En este caso, se observa que algunas de las nuevas funciones y partes del código existente no han sido suficientemente probadas.

Para mejorar la cobertura del código, tome las siguientes medidas:

  1. Identificación de lagunas en las pruebasSe analizan las líneas y ramas de código resaltadas que no han sido alcanzadas por las pruebas y se identifican las áreas con código sin descubrir.
  2. Creación de nuevos casos de pruebaSe crean casos de prueba adicionales que cubren estas rutas de código no descubiertas. Esto puede significar desarrollar escenarios específicos que prueben a fondo las nuevas características o modificar los casos de prueba para cubrir estas nuevas áreas.
  3. Modificación de los casos de prueba existentesSe revisan los casos de prueba existentes para garantizar que cubren las partes modificadas del código.

Estas medidas aumentan la cobertura del código y garantizan pruebas suficientes de las nuevas funciones y partes modificadas del código.

KPI 3 "Cobertura de la automatización de pruebas" - Cobertura de la automatización de pruebas

La cobertura de automatización de pruebas le muestra qué proporción de todos los casos de prueba de que dispone como parte de su conjunto de pruebas están automatizados. La métrica se forma simplemente dividiendo el número de pruebas automatizadas por el número total de pruebas - automatizadas y manuales. Es importante tener en cuenta que todos los casos de prueba que deben considerarse son los que se ejecutan a nivel del sistema, es decir, de forma que cualquier usuario final del software pueda ejecutarlos.

Interpretación y aplicación de la cobertura de automatización de pruebas como KPI:

  • La cobertura de la automatización de pruebas se expresa en porcentaje. Un porcentaje más alto significa una mejor cobertura y viceversa.
  • La automatización de pruebas no es un proceso rápido, requiere tiempo y, por tanto, una buena planificación. Para saber qué pruebas deben automatizarse primero, hay que establecer prioridades. Por ejemplo, tenga en cuenta la frecuencia de uso de la funcionalidad probada, la dependencia de otros casos de prueba y la complejidad de la implementación de su software. Los casos de prueba con alta prioridad, fuertes dependencias y baja complejidad son buenos candidatos para la automatización.
  • La automatización de pruebas apenas tiene fin mientras siga desarrollando su producto. No olvides revisar y actualizar periódicamente tus casos de prueba automatizados para reflejar los últimos cambios en funcionalidad y rendimiento.

Ejemplo "Cobertura de automatización de pruebas"

Quedémonos con nuestra empresa, que gestiona una plataforma de comercio electrónico en la que los clientes pueden comprar productos. Su plataforma tiene diversas funciones, como la búsqueda de productos, la cesta de la compra, el procesamiento de pedidos y las opiniones de los clientes. Como responsable de control de calidad, deberá supervisar la automatización de las pruebas y garantizar una buena cobertura de las mismas.

Su plataforma de comercio electrónico tiene un total de 500 casos de prueba diferentes que son relevantes a nivel de sistema. Se trata de pruebas que garantizan que un usuario final pueda utilizar todas las funciones importantes de la plataforma. Para calcular su cobertura de automatización de pruebas, ha automatizado 200 de estas pruebas. Esto significa que 200 de sus casos de prueba son ejecutados por un marco de automatización de pruebas, mientras que los 300 restantes son ejecutados manualmente por los probadores.

La cobertura de automatización de pruebas, en este caso, es:

(casos de prueba automatizados / número total de casos de prueba relevantes) x 100 = (200 / 500) x 100 = 40%

Esto significa que su Cobertura de Automatización de Pruebas es 40%. Esto a su vez significa que 40% de sus casos de prueba relevantes Automatizado mientras que las 60% restantes se realizan manualmente. Esto puede deberse a diversos factores, como las limitaciones de tiempo y recursos o la dificultad de automatizar determinadas pruebas.

Se pueden seguir los siguientes pasos para mejorar la Cobertura de Automatización de Pruebas:

  1. Dar prioridad aAnalice qué pruebas realizan con más frecuencia los usuarios, como la búsqueda de productos y la tramitación de pedidos. Estas pruebas tienen la máxima prioridad para la automatización.
  2. Tener en cuenta las dependenciasIdentifique los casos de prueba que dependen en gran medida de otros. Las pruebas automatizadas deben ser las que más influyan en otras pruebas para aumentar la eficacia.
  3. Considerar la complejidadHay que favorecer las pruebas fáciles de automatizar, ya que requieren menos tiempo y recursos.
  4. Actualización periódicaSe asegurará de que los casos de prueba automatizados se revisen constantemente y se adapten a los últimos cambios de la plataforma para mantener actualizada la cobertura de las pruebas.

Aplicando estos principios, podrá aumentar la cobertura de la automatización de pruebas y garantizar la calidad de su plataforma de comercio electrónico, al tiempo que utiliza el tiempo y los recursos de forma eficiente.

KPI 4 "Eficacia de la detección de defectos - DDE" - Eficacia de la detección de defectos

La eficacia en la detección de defectos (DDE) se expresa en porcentaje y representa la proporción de defectos o errores detectados mediante pruebas en comparación con el número total de defectos o errores en el proyecto. Software representar.

La fórmula para calcular el índice de detección de defectos es la siguiente:

Tasa de detección de errores (%) = (número de errores detectados durante la prueba / número total de errores) x 100

Interpretación y aplicación de la fórmula DDE como KPI:

  • Un porcentaje más alto significa que las pruebas son más eficaces. Indica que su procedimiento de prueba es suficiente y que solo un número mínimo de defectos llegará al entorno de producción.
  • Un porcentaje bajo significa que su proceso de pruebas es menos eficaz para encontrar errores y que necesita ampliar su conjunto de pruebas. A la hora de decidir cómo hacerlo, puedes utilizar los datos proporcionados por tus herramientas de cobertura de código.

Ejemplo "Eficacia de la detección de defectos"

Un equipo de desarrollo de software está trabajando en un nuevo sistema de comercio electrónico. Durante la fase de desarrollo se detectan 100 errores o fallos en el código. Antes de que el software pase al entorno de producción, se realizan pruebas exhaustivas para reconocer y corregir los errores. Durante estas pruebas, se detectan y corrigen 80 de los 100 errores.

Para calcular la DDE, utilizamos la fórmula:

DDE (%) = (número de errores encontrados durante la prueba / número total de errores) x 100

Insertemos los valores en la fórmula:

DDE (%) = (80 / 100) x 100 = 80%

En este ejemplo, la eficacia de detección de defectos (DDE) es de 80%. Esto significa que 80% de los defectos existentes se encontraron durante las pruebas. Una DDE alta indica que los esfuerzos de las pruebas son eficientes. Sólo 20% de los defectos podrían entrar en el entorno de producción sin ser detectados.

En la práctica, el equipo de desarrollo intentaría mantener la DDE lo más alta posible para garantizar la calidad del software y minimizar las quejas de los clientes o los problemas de calidad tras el lanzamiento. Si la DDE fuera más baja, los probadores y desarrolladores se replantearían su estrategia de pruebas y posiblemente aumentarían la cobertura de las pruebas para garantizar una mejor detección de los defectos. El uso de herramientas de cobertura del código, entre otras cosas, podría contribuir a ello e identificar las áreas del código que no han sido suficientemente probadas.

KPI 5 "Defectos escapados

El término "defectos escapados" se refiere a errores o problemas en un Aplicación informáticaque no se reconocieron y rectificaron durante la fase de prueba y que posteriormente se introdujeron en el entorno de producción. Se "escaparon" del proceso de prueba y fueron descubiertos por el usuario final. Los usuarios finales no son sólo los clientes, sino también los participantes internos que se encontraron con el error fuera del proceso de prueba.

Interpretación y aplicación de los defectos escapados como KPI:

  • Los defectos que se escapan pueden provocar mayores costes de mantenimiento. Corregir defectos en el entorno de producción suele ser más costoso y llevar más tiempo que hacerlo en la fase de pruebas.
  • Estos errores pueden repercutir negativamente en la experiencia del usuario.
  • La presencia de defectos escapados puede indicar deficiencias en el proceso de pruebas, por ejemplo, cobertura insuficiente del código, cobertura insuficiente de las pruebas de requisitos o falta de casos de prueba eficaces.

Ejemplo "Defectos escapados"

Su empresa de comercio electrónico ha lanzado recientemente una nueva versión de su plataforma de comercio electrónico en el entorno de producción, que incluía algunos cambios y mejoras significativos. Antes de su lanzamiento, el software pasó por una extensa fase de pruebas en la que los desarrolladores y los equipos de control de calidad revisaron detenidamente los requisitos, la cobertura del código y varios casos de prueba.

Unas semanas después del lanzamiento de la nueva versión, empieza a recibir informes de problemas y errores de los usuarios finales. Estos errores afectan a la experiencia del usuario y dan lugar a quejas de los clientes. Al investigar estos fallos no detectados, se da cuenta de que se deben a vulnerabilidades no reconocidas en el entorno de producción. Estas vulnerabilidades no se reconocieron durante la fase de pruebas y se han trasladado al entorno de producción.

Un error de este tipo es, por ejemplo, un error en el proceso de pedido que hace que los pedidos no puedan completarse correctamente. Esto perjudica considerablemente la experiencia del usuario y provoca pérdidas de ventas, ya que los clientes no pueden completar sus compras con éxito.

Las consecuencias de los errores no cometidos son múltiples:

  1. Mayores costes de mantenimientoLa corrección de errores en el entorno de producción requiere recursos y tiempo adicionales. Esto conlleva mayores costes de mantenimiento, ya que los desarrolladores y los equipos de soporte tienen que trabajar urgentemente en la corrección de errores en lugar de trabajar en nuevas funcionalidades.
  2. Experiencia del usuarioLos errores no detectados afectan a la experiencia del usuario y pueden provocar la insatisfacción de los clientes y su posible cambio a la competencia.
  3. Proceso de garantía de calidadLa ausencia de defectos indica posibles deficiencias en el proceso de prueba. Esto puede indicar una cobertura insuficiente del código, una cobertura insuficiente de los requisitos o casos de prueba ineficaces. Es importante revisar y mejorar el proceso de pruebas para evitar este tipo de errores en el futuro.

Por ello, es importante analizar los fallos detectados, corregirlos y, al mismo tiempo, reforzar el proceso de pruebas para evitar estos problemas en futuras actualizaciones del software. Esto ayudará a reducir los costes de mantenimiento y a mantener la confianza de los usuarios en su plataforma de comercio electrónico.

KPI 6 "Satisfacción del cliente" - Satisfacción del cliente

Incluso si la satisfacción del cliente no está directa y exclusivamente relacionada con las pruebas de software, debe tener en cuenta este KPI tanto en el desarrollo como en el Optimización de una estrategia de pruebas de software. La satisfacción del cliente es una medida de lo bien que su software cumple las expectativas del usuario. De este modo, este KPI puede mostrarle -además de los resultados sobre la funcionalidad en sí- cómo de alta es la calidad percibida de su software.

Interpretación y aplicación de la satisfacción del cliente como KPI:

  • Hay muchas encuestas que se piden a los clientes con regularidad y que proporcionan un valor numérico para la satisfacción del cliente. Por ejemplo: Net Promoter Score o Puntuación del esfuerzo del cliente.
  • Aunque los valores numéricos son fáciles y rápidos de entender, no debe confiar únicamente en ellos. En su lugar, asegúrese de integrar también preguntas cualitativas. Estas respuestas le mostrarán el "por qué" detrás del número, que en muchos casos no es una función que falta, sino simplemente un producto de software poco fiable lleno de anomalías.
  • Evalúe la relación entre los problemas detectados y sus procedimientos de prueba. Valore si estos problemas podrían haberse detectado mediante pruebas más exhaustivas o específicas. Por ejemplo, pruebas funcionales, de usabilidad, de rendimiento o de seguridad.

Ejemplo "Satisfacción del cliente

Su empresa de comercio electrónico realizó una encuesta entre sus clientes y utilizó el índice Net Promoter Score (NPS) para medir su satisfacción. El NPS dio como resultado una puntuación media de 7. Aunque esto es positivo a primera vista, las respuestas cualitativas mostraron que los clientes tenían problemas con el rendimiento del sitio web, lo que afectaba a su experiencia de compra.

El análisis cualitativo mostró que estos problemas de rendimiento afectaban a la calidad percibida del software. La causa era la insuficiencia de pruebas de rendimiento durante el desarrollo. En respuesta, optimizaron la estrategia de pruebas e integraron pruebas de rendimiento más exhaustivas.

El KPI de satisfacción del cliente ayudó a identificar el desfase entre los requisitos del cliente y los procedimientos de prueba y a adaptar la estrategia de pruebas para aumentar la satisfacción del cliente y garantizar el éxito a largo plazo de la organización.

Conclusión sobre los KPI para pruebas de software

Pruebas de software KPI Conclusión

Las pruebas de software suelen ser un aspecto descuidado del desarrollo de software. Sin embargo, las pruebas de software desempeñan un papel fundamental en el éxito de un producto. Existen diversos indicadores clave de rendimiento (KPI) para evaluar la calidad de las pruebas en cada iteración.

No es realista, ni siquiera necesario, aplicar todos los KPI. Sin embargo, a menudo se complementan y deben considerarse en combinación.

Por ejemplo, es posible seguir la evolución del indicador de rendimiento de Efectos Escapados en las distintas versiones del software. Este KPI determina en última instancia el éxito de todas sus estrategias de prueba. Sin embargo, otros KPI como la Cobertura del Código, el Porcentaje de Automatización de Pruebas y el DDE le ayudarán a decidir en qué partes del software debe centrar sus esfuerzos para mejorar su estrategia de pruebas si aumenta el número de efectos escapados.

NotaA la hora de aplicar estos KPI, tenga en cuenta también otras buenas prácticas de desarrollo de software, como invertir tiempo y esfuerzo en el análisis de requisitos para obtener un conjunto completo de requisitos.

¿Tiene alguna pregunta sobre las pruebas de software? Escríbanos un mensaje.








    "
    "
    Avatar de Boyidar Parvanov

    Últimos artículos