Cómo medir la calidad de un producto de software

Question

Tengo un producto, X, que entregamos a un cliente, C cada mes, incluyendo correcciones de errores, mejoras, nuevos desarrollos, etc.) Cada mes, me piden que "garantice" la calidad del producto.

Para ello utilizamos una serie de estadísticas obtenidas de las pruebas que realizamos, como por ejemplo:

• tasa de reapertura (número de errores reabiertos/número de errores corregidos probados)
• tasa de errores nuevos (número de errores nuevos, incluidas regresiones, encontrados durante las pruebas/número de errores corregidos probados)
• para cada nueva mejora, la nueva tasa de errores (la cantidad de errores encontrados para esta mejora/la cantidad de días)

y varias otras figuras.

Es imposible, por razones que no analizaremos, probarlo todo cada vez.

Entonces, mi pregunta es:

¿Cómo calculo la cantidad y el tipo de errores que permanecen en mi software?¿Qué estrategias de prueba debo seguir para asegurarme de que el producto es bueno?

Sé que esta es una pregunta un poco abierta, pero bueno, también sé que no hay soluciones simples.

Gracias.

Answer 1

No creo que puedas estimar realmente la cantidad de errores en tu aplicación.A menos que utilice un lenguaje y un proceso que permita pruebas formales, nunca podrá estar realmente seguro.Probablemente sea mejor invertir su tiempo configurando procesos para minimizar errores que tratando de estimar cuántos tiene.

Una de las cosas más importantes que puede hacer es tener un buen equipo de control de calidad y un buen seguimiento de los elementos de trabajo.Es posible que no pueda realizar pruebas de regresión completas cada vez, pero si tiene una lista de los cambios que ha realizado en la aplicación desde la última versión, entonces su personal (o persona) de control de calidad puede centrar sus pruebas en las partes de la aplicación que se espera que se vea afectada.

Otra cosa que sería útil son las pruebas unitarias.Cuanto más haya cubierto su código base, más seguro podrá estar de que los cambios en un área no afectaron inadvertidamente a otra área.Esto me ha parecido bastante útil, ya que a veces cambio algo y olvido que afectaría otra parte de la aplicación, y las pruebas unitarias mostraron el problema de inmediato.Las pruebas unitarias aprobadas no garantizan que no haya roto nada, pero pueden ayudar a aumentar la confianza en que los cambios que realice están funcionando.

Además, esto es un poco redundante y obvio, pero asegúrese de tener un buen software de seguimiento de errores.:)

Answer 2

La pregunta es quién requiere que proporciones las estadísticas.

Si se trata de personas sin conocimientos técnicos, falsifique las estadísticas.Por "falso" me refiero a "proporcionar números reales, inevitablemente sin sentido" del tipo que mencionaste.

Si se trata de técnicos sin experiencia en informática, se les debe informar sobre el problema de la detención, que es indecidible y es más sencillo que contar y clasificar los errores restantes.

Hay muchas métricas y herramientas relacionadas con la calidad del software (cobertura de código, complejidad ciclomática, pautas de codificación y herramientas que las hacen cumplir, etc.).En la práctica, lo que funciona es automatizar tantas pruebas como sea posible, hacer que evaluadores humanos realicen tantas pruebas que no fueron automatizadas como sea posible y luego rezar.

Answer 3

Creo que mantenerlo simple es la mejor manera de hacerlo.Clasifique sus errores por gravedad y solucionelos en orden de gravedad decreciente.

De esta manera, puede entregar la compilación de la más alta calidad posible (la cantidad de errores importantes que quedan es la forma en que yo mediría la calidad del producto, en lugar de algunas estadísticas complejas).

Answer 4

La mayoría de las metodologías ágiles abordan este dilema con bastante claridad.No puedes probarlo todo.Tampoco puedes probarlo un número infinito de veces antes de lanzarlo.Entonces, el procedimiento consiste en confiar en el riesgo y la probabilidad de que se produzca el error.Tanto el riesgo como la probabilidad son valores numéricos.El producto de ambos te da un número RPN.Si el número es inferior a 15, enviarás una versión beta.Si puede reducirlo a menos de 10, envía el producto y envía el error para que se solucione en una versión futura.

¿Cómo calcular el riesgo?

Si es un choque, entonces es un 5 si es un bloqueo pero puede proporcionar un trabajo, entonces es un número de menos de 5.Si el error reduce la funcionalidad entonces es un 4

¿Cómo calcular la probabilidad?

¿Puedes reproducirlo cada vez que lo ejecutas? Es un 5.Si la solución alternativa proporcionada todavía causa que se bloquee, entonces menos de 5

Bueno, tengo curiosidad por saber si alguien más está usando este esquema y estoy ansioso por saber su kilometraje al respecto.

Answer 5

¿Que tan larga es una pieza de cordon?En última instancia, ¿qué hace que un producto sea de calidad?Los errores dan alguna indicación de que sí, pero hay muchos otros factores involucrados; la cobertura de la prueba unitaria es un factor clave en la OMI.Pero en mi experiencia, el principal factor que influye en si un producto puede considerarse de calidad o no es una buena comprensión del problema que se está resolviendo.A menudo, lo que sucede es que el "problema" que el producto debe resolver no se entiende correctamente y los desarrolladores terminan inventando la solución a un problema que tienen en mente, y no el problema real, por lo que se crean "errores". .Soy un firme defensor de la iterativa. Ágil desarrollo, de esta manera el producto está constantemente en contacto con el 'problema' y el producto no se desvía demasiado de su objetivo.

Answer 6

Las preguntas que escuché fueron: ¿cómo calculo los errores en mi software?¿Y qué técnicas utilizo para garantizar que la calidad sea buena?

En lugar de seguir un curso completo, he aquí un par de enfoques.

¿Cómo calculo los errores en mi software?

Comience con el historial, sabrá cuántos encontró durante las pruebas (con suerte) y cuántos se encontraron después del hecho.Puede usarlo para estimar qué tan eficiente es para encontrar errores (DDR: Tasa de detección de defectos es un nombre para esto).Si puede demostrar que durante un período de tiempo constante, su DDR es consistente (o mejora), puede proporcionar una idea de la calidad del lanzamiento adivinando la cantidad de defectos posteriores al lanzamiento que se encontrarán una vez que se lance el producto.

¿Qué técnicas utilizo para garantizar que la calidad sea buena?

El análisis de la causa raíz de sus errores le indicará componentes específicos que tienen errores, desarrolladores específicos que crean código con errores, el hecho de que la falta de requisitos completos da como resultado que la implementación no cumpla con las expectativas, etc.

Reuniones de revisión del proyecto para identificar rápidamente qué fue bueno, para que esas cosas se puedan repetir y qué fue malo, y encontrar una manera de no volver a hacerlo.

Con suerte, estos le darán un buen comienzo.¡Buena suerte!

Answer 7

Parece que el consenso es que se debe poner énfasis en las pruebas unitarias.El seguimiento de errores es un buen indicador de la calidad del producto, pero solo es preciso según su equipo de pruebas.Si emplea pruebas unitarias, obtendrá una métrica mensurable de la cobertura del código y proporciona pruebas de regresión para que pueda estar seguro de que no ha roto nada desde el mes pasado.

Mi empresa depende de las pruebas a nivel de sistema/integración.Veo que se introducen muchos defectos porque faltan pruebas de regresión.Creo que los "errores" en los que la implementación de los requisitos por parte del desarrollador se desvía de la visión del usuario son una especie de problema separado que, como dijeron Dan y rptony, se aborda mejor con metodologías ágiles.