Cómo medir la calidad de un producto de software

Question

Tengo un producto, X, que entregamos a un cliente, C todos los meses, incluidas correcciones de errores, mejoras, nuevos desarrollos, etc.) Cada mes, se me pide que "me equivoque". "la calidad del producto.

Para ello se utilizan una serie de estadísticas obtuvo a partir de las pruebas que realizamos, como por ejemplo:

tasa
• reabrir (número de errores reabierto/número de errores corregidos probados)
• nueva tasa de errores (número de nuevo, incluyendo regresiones, insectos encontrados durante las pruebas/número de errores corregidos probado)
• para cada nueva mejora, la nueva tasa de errores (el número de errores encontrados para esta mejora/número de días-hombre)

y varias otras figuras.

Es imposible, por razones que no vamos a entrar, probar todo en todo momento.

Por lo tanto, mi pregunta es:

¿Cómo estimar el número y el tipo de errores que permanecen en el software? ¿Qué estrategias de pruebas tengo que seguir para asegurarse 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 realmente calcular el número de errores en tu aplicación. A menos que use un lenguaje y un proceso que permita pruebas formales, nunca podrá estar seguro. Es probable que le dedique mejor su tiempo a la configuración de procesos para minimizar errores que intentar calcular 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 del elemento de trabajo. Es posible que no pueda realizar pruebas de regresión completas todas las veces, pero si tiene una lista de los cambios que ha realizado en la aplicación desde la última versión, entonces su gente de control de calidad (o persona) puede enfocar sus pruebas en las partes de la aplicación que se espera que se vea afectada.

Otra cosa que podría ser útil son las pruebas unitarias. Cuanta más cobertura haya cubierto, más seguro podrá estar de que los cambios en un área no afectaron inadvertidamente a otra área. Lo encontré bastante útil, ya que a veces cambiaré algo y olvidaré que afectaría a otra parte de la aplicación, y las pruebas unitarias mostraron el problema de inmediato. Las pruebas pasadas de unidad no garantizarán que no haya roto nada, pero pueden ayudar a aumentar la confianza de que los cambios que realiza 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

pienso hacer que sea sencillo es el mejor camino a seguir. Categorice sus errores por gravedad y diríjalos en orden de severidad decreciente.

De esta manera puede entregar la construcción de la más alta calidad posible (el número de errores importantes restantes es cómo mediría la calidad del producto, a diferencia de algunas estadísticas complejas).

Answer 3

La cuestión es que requiere que proporcione las estadísticas.

Si no se trata de personas técnicas, falsifique las estadísticas. Por "falso", me refiero a "proporcionar cualquier número irrelevante, pero real" del tipo que mencionas.

Si se trata de personas técnicas sin experiencia en CS, se les debe informar sobre el problema de detención, que es indecidible y es más simple 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, directrices de codificación y herramientas que las imponen, etc.). En la práctica, lo que funciona es la automatización de pruebas tanto como sea posible, teniendo probadores humanos hacen tantas pruebas que no fueron automatizadas como sea posible, y luego orar.

Answer 4

¿Por cuánto tiempo es un pedazo de cuerda? En definitiva, ¿qué hace que un producto de calidad? Los errores dan alguna indicación, 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 factor principal que afecta si un producto puede considerarse calidad o no, es una buena comprensión del problema que se está resolviendo. A menudo lo que sucede es que el 'problema' de que el producto está destinado a resolver no es entendido correctamente y los desarrolladores terminan inventando la solución a un problema que tienen carne en su cabeza, y no el verdadero problema, por lo tanto se hacen 'bichos' .Soy un firme defensor del desarrollo iterativo de Agile, de esa manera el producto tiene acceso constante al "problema" y el producto no se aleja demasiado de su objetivo.

Answer 5

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

¿Cómo calcular el riesgo?

Si es un accidente, entonces es un 5 Si es un accidente, pero que puede proporcionar una solución alternativa, entonces es un número menor que 5. Si el fallo reduce la funcionalidad, entonces es un 4

Cómo calcular la verosimilitud?

se puede volver a producir cada vez que se ejecuta, es un 5. Si el trabajo alrededor proporcionado todavía hace que se bloquee después de menos de 5

Bueno, tengo curiosidad por saber si cualquier otra persona usando este esquema y ansioso por saber su kilometraje en esto.

Answer 6

Las preguntas que escuché fueron: ¿cómo puedo calcular los errores en mi software? y ¿qué técnicas uso para asegurar que la calidad sea buena?

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

¿Cómo calculo los errores en mi software?

Comience con la historia, usted sabe cuántos encontró durante la prueba (con suerte) y sabe cuántos se encontraron después del hecho. Puede usar eso para estimar qué tan eficiente es en 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 coherente (o mejora), puede proporcionar una idea de la calidad del lanzamiento adivinando la cantidad de defectos posteriores a la publicación que se encontrarán una vez que se haya lanzado el producto.

¿Qué técnicas uso para asegurar que la calidad sea buena? análisis de la causa

raíz en sus errores le apuntan a los componentes específicos que son cochecito, promotores específicos que crean código erróneo, el hecho de que carecen de los requisitos completos resultados en la aplicación que no coincida con las expectativas, etc.

reuniones de revisión del proyecto para identificar rápidamente lo que era bueno, para que esas cosas puedan repetirse y lo que era malo y encontrar una manera de no volver a hacer eso.

Afortunadamente, estos le dan 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 exacto como su equipo de prueba. Si emplea pruebas unitarias, le proporciona una métrica mensurable de cobertura de códigos 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 de nivel de sistema/integración. Veo que se introducen muchos defectos porque no hay pruebas de regresión. Creo que los "errores" en los que la implementación del desarrollador de los requisitos se desvía de la visión del usuario es una especie de problema separado que, como Dan y rtony declararon, se trata mejor con las metodologías Agile.