bug-tracking - source - buzilla

¿Cuántos errores son demasiados? (20)

A veces me frustro en mi trabajo debido a la percepción de buggyness de mi código. Pero creo que no estoy produciendo más, y probablemente menos que la mayoría de las personas. Por ejemplo, acabo de terminar de desarrollar un proyecto que tomó 3 meses, donde los evaluadores encontraron alrededor de 10 errores genuinos y probablemente otros 10 cambios no relacionados con errores (es decir, ¿puedo cambiar el color de este botón)? Creo que esto no es malo después de 3 meses de desarrollo, pero otras personas me están mirando como si acabara de registrar la mayor carga de basura. ¿Qué piensas?

Edición: Añadiré más información.

No solo lo comprobé al final. Me fui revisando continuamente y haciendo mis propias pruebas a medida que avanzaba. Obviamente encontré y corregí muchos errores a medida que avanzaba.
La primera ronda de pruebas realizadas por personas externas fue después de dos meses. La mayoría de los errores se encontraban en áreas que sabía que tenían problemas y no se habían probado exhaustivamente, pero como el software aún estaba "en desarrollo"
La segunda ronda de pruebas fue después de 3 meses y al igual que la primera versión en áreas en las que no había sido tan exhaustivo, aunque no creo que haya tantos problemas.
La mayoría de los errores estaban en partes bastante visibles de la aplicación, por lo que posiblemente empeoró las cosas. Estas partes, aunque visibles, no eran realmente integrales ni se usaban con tanta frecuencia por el usuario. De hecho, algunas de las solicitudes se pusieron en espera como no esenciales.

(no debe usarse como excusa) pero los errores en el código en programas grandes (no triviales) son parte del juego. Es por eso que tenemos departamentos de prueba. Incluso el mejor programador produce errores, ya que es matemáticamente imposible demostrar que una parte del software (no trivial) no tiene ningún error.

http://amartester.blogspot.com/2007/04/bugs-per-lines-of-code.html

Algunas personas prefieren no publicitar cuando encuentran errores en su propio código, especialmente para nuevas empresas sin seguimiento de errores.

Personalmente, considero que es un comportamiento positivo para los desarrolladores encontrar tantos errores en su software como sea posible. Por supuesto, estoy hablando de desarrolladores profesionales y competentes: no es necesario dejar errores en ellos para ganar puntos Brownie de esta manera. Pero si obtengo 1 error por la misma cantidad de código que otro desarrollador descubre 10 errores, no miraría hacia abajo en este desarrollador, especialmente si estamos considerando proyectos "grandes".

Aquí hay un único punto de comparación (estaría interesado en ver otros): una consulta rápida de errores me dice que en mi trabajo de desarrollador el año pasado solucioné 107 errores, y asumiendo que hay una correspondencia aproximada entre lo que solucioné y lo que originalmente escribí , eso es tal vez unos 25 errores creados por tres meses.

Como ha dicho la gente, hay muchos factores confusos al encontrar una interepretación razonable / significativa de estos datos (cuán graves son los errores, en qué tipo de sistema / producto trabajas, ...), pero me interesaría verlos. otras cinco o diez personas contribuyen con sus propios "datos del mundo real" solo para intentar promediar algunas pruebas anecdóticas.

Como una medida aproximada, un proyecto de tres meses es de 25,000 a 50,000 líneas de código, por lo que debe esperar encontrar diez errores por cada 1000 líneas en las pruebas internas, por lo que serían típicos de 100 a 500 errores.

Si su departamento de prueba interno está reportando 0.2 errores / 1000 líneas para lo que suena como un esfuerzo en solitario (¿alguien lo revisó en el código?), O bien usted es muy bueno, o no son lo suficientemente exhaustivos.

Desde un punto de vista perfeccionista, 1 error es demasiado. Cuán relevante es el punto de vista perfeccionista es muy subjetivo.

Si se trata de un código envuelto en papel de retractilado, la mejor cantidad de errores es mejor, ya que aumentará las ventas (no tendrá un boca a boca que diga que está lleno de errores).

En aplicaciones de alta seguridad, cero errores es realmente crítico (marcapasos, equipos hospitalarios, estaciones de energía nuclear), pero también tienden a especificarse con lenguajes formales que le permiten analizar correctamente el diseño, junto con largos períodos de prueba y largos períodos de prueba para Realmente la destrucción prueba tu código.

En las aplicaciones escritas para clientes específicos, ¿cuántos errores te pagan por eliminar? ¿Están pagando rápido o de calidad? Es de esperar que se produzcan errores graves en una aplicación que se ha presupuestado de forma insuficiente y se ha llevado rápidamente a la producción.

Además, ¿fueron estos 10 errores mientras los probadores probaban el código de preproducción? Si es así, entonces eso es bastante bueno (el último proyecto en el que trabajé, a veces logré 10 errores en un día ... pero luego los solucioné todos al día siguiente porque eran cosas pequeñas que simplemente no había considerado por completo :)). Pero el conteo de errores antes de que el sistema entre en funcionamiento apenas cuenta (a menos que sea una semana antes del lanzamiento y tenga problemas para cumplir con los requisitos originales)

El número de errores "externos" para un programador por 1''000 líneas de código (KLOC) es una constante. La cifra varía de 3-4 para programadores muy buenos a 10 para programadores promedio a "lotes".

Esto significa que: por cada 1000 líneas de código, encontrará muchos "errores" (desde errores tipográficos en una cadena hasta completar el código en un método de diseño desastroso que lleva a una reescritura completa).

Tenga en cuenta que generalmente cometemos muchos más errores, pero cuanto mejor se pone un programador, más errores encuentran antes de que el código salga de su escritorio (de ahí, errores "externos" -> errores que otras personas encuentran). Además, los buenos programadores tenderán a hacer algunos errores desastrosos y más errores "tontos" (que son fáciles de solucionar pero más embarazosos: "¿cómo podría supervisar esto?").

Curiosamente, el número de errores es constante con respecto al lenguaje, por lo que los programadores de ensamblador muy buenos hacen 4 errores / KLOC, así que los programadores de C muy buenos hacen 4 errores / KLOC, así que los programadores de Java muy buenos hacen 4 errores / KLOC, etc.

Esto significa que los idiomas que necesitan menos líneas de código para lograr el resultado deseado tienen una ventaja.

Ahora a la pregunta "¿cuándo hay demasiados errores?" Da un paso atrás. A medida que se desarrolle, tendrá muchos errores (la mayoría de ellos internos). El producto final tendrá menos errores porque la mayoría se encontrarán durante el desarrollo. Esto significa que importa cuando miras. También significa que el número de errores per se no es una buena indicación de "salud".

Para saber cuándo nuestro proyecto comienza a enfermarse, debe contar sus errores de alguna manera (cuántas líneas he escrito, cuántos errores encontré, cuántos podría solucionar). Esto es un gran esfuerzo y, a menudo, tiene un ROI negativo. Estas cosas son difíciles de medir y se necesita tiempo para escribir los errores que se encuentran en algún lugar y todo esto lo distrae de su objetivo: Escribir código.

Mi enfoque es comenzar a escribir más pruebas cuando broten más errores. La cantidad sentida de "buggyness" (o inquietud de mi parte) es una buena indicación de si algo está mal. Entonces, si sientes que creas dos errores nuevos con cada línea de código, es una señal segura de que hay que hacer algo. Si escribes muchas líneas de código y todo encaja en su lugar como por arte de magia, entonces ¿por qué perder el tiempo en medir qué tan bien va todo?

Al escribir pruebas, puedo mantener los errores bajo control y puedo asegurarme de que permanezcan muertos.

[EDITAR] Algunos enlaces con información donde obtuve mis números:

Es difícil decir cuántos errores es mucho. Creo que las métricas que involucran X errores por Y líneas de código son tan defectuosas como cualquier métrica que use líneas de código (por ejemplo: medir la productividad).

Mi observación es que los desarrolladores y usuarios / personas de negocios tienen puntos de vista muy diferentes sobre lo que significan los errores. Para un desarrollador, cada error encontrado y corregido aumenta la confianza del desarrollador en el código, ya que se puede ver que se está volviendo más sólido. Para un usuario, cada error encontrado (incluso si es fijo) disminuye su confianza.

Me recuerda un poco a mi curso de ingeniería de software de licenciatura que trata con las pruebas: una prueba exitosa no es una que pasa, sino una que falla, ya que ha detectado un error con éxito y, por lo tanto, llevará a una mejora. De manera similar, el código exitoso no tiene éxito porque no se encontraron errores, sino porque los errores se encontraron y se corrigieron. Si se encuentran pocos / ningún error en una pieza de software, simplemente asumo que aún no se ha probado adecuadamente.

Es muy subjetivo: el error trivial de una persona puede ser un bloqueador para otra persona, o incluso una característica para otra. Puede ser que los requisitos no fueran claros o correctos, y eso quedó reflejado en el código y fue recogido por los evaluadores. La calidad de sus evaluadores también juega un papel importante, cuanto mejor son los defectos más relevantes que encontrarán.

Hablando relativamente, 10 errores en 3 meses de código pueden ser muy buenos. Si hiciera un proyecto que durara 3 meses, no me sorprendería si se encontraran 200 errores en él.

Por supuesto, también hace una diferencia si son errores grandes o pequeños, y si son el tipo de cosas que debería haber capturado durante la codificación. Si uno de esos 10 errores es un problema importante que es una cosa bastante estándar a tener en cuenta, entonces tal vez esas otras personas estén algo justificadas en sus pensamientos.

La cantidad de errores es menos importante que el tiempo que lleva detectarlos. Cuanto más tarde en identificar un error, más costoso será localizarlo y corregirlo, y más probable será que la solución para ese error pueda romper algo más. Probar temprano y Probar a menudo (TEATO?) Es el mejor enfoque.

La percepción de la calidad de un producto de software puede variar mucho entre el programador y el usuario. Esto es en parte porque uno lo ve desde adentro y el otro lo ve desde afuera.

Si se juzgan solo por el número de errores encontrados en las pruebas, eso es desafortunado, ya que tiene poca correlación con la forma en que disfrutarán el producto cuando realmente lo usen. Yo lo vería como la verdadera prueba de calidad. Siéntelos frente al producto y luego vea cuál es la reacción.

Tanto como el código es hermoso desde su punto de vista como programador, es un hecho desafortunado (o afortunado, dependiendo de su perspectiva) de que el software se juzgará según la experiencia del usuario al usarlo.

Ver también: número de WTF por minuto .

Lo preocupado que debas estar depende del tipo de errores que sean. Qué tan severos son y qué tan probable es que los hayas visto antes que los evaluadores.

Si se trata de que la suma neta y los totales de impuestos en una factura no coinciden con el bruto, entonces debería preocuparse. Si se trata de dos personas que editan la misma factura al mismo tiempo hace que ocurra algo extraño 1 vez en 5, entonces puede que le moleste menos.

No tenemos un contexto para juzgarlo, por lo que les prestaría mucha más atención a los que se encuentran en su entorno inmediato que a nosotros.

Dicho esto, no creo que puedas seguir estrictamente los números. Si olvidó algunos detalles importantes de los que un cliente sería consciente de inmediato, me resistiría a estar en proyectos con usted. Si te perdiste los elementos de idiotas que son más comprensibles.

Escribir software para clientes cuyas actividades diarias de las que no tienes idea es un gran problema. Puede ser que sus compañeros de trabajo tengan la intuición de pasar tiempo con los clientes que aún no tiene, de ahí su reacción.

Puede consultar las normas de seguridad funcional como ISO26262 ( http://en.wikipedia.org/wiki/ISO_26262 ) o IEC 61508. Debido a que hace una diferencia si la consecuencia de la falla / error es la pérdida de una vida humana, o Si solo el café se está enfriando.

Esos estándares describen los métodos y las situaciones en que deben tomarse para reducir el riesgo.

El número de fallos también está relacionado con la complejidad. (por ejemplo: http://www.cas.mcmaster.ca/~lawford/papers/SeparatingSafetyAndControl.pdf , ch 4.4)

DFSS (diseño para six sigma) y diseño axiomático son conceptos de ingeniería para reducir las fallas en los productos.

Realmente depende. Firefox tiene aproximadamente 15000 errores, pero se considera que es bastante utilizable. Por otro lado, no me gustaría tener un error en mi marcapasos.

Si otros perciben que su código tiene errores, entonces es demasiado con errores. La percepción es más importante que la realidad. No importa si solo tienes 1 error. Ser percibido como un buggy (incluso si solo era 1 error) significaría que creaste algunos errores bastante visibles.

Como lo sugirió otra persona, realmente no podemos determinar su situación si 10 errores son demasiados porque tendríamos que conocer el tipo de errores. Le sugiero que observe los tipos de errores que está creando para ver si existen similitudes. ¿No entendiste los requisitos? ¿Hubo muchos errores por un error? ¿Errores lógicos? etc ... Luego evalúa si son errores que deberías haber atrapado. Si es así, busque la manera de no inyectar ese tipo de errores la próxima vez.

Los errores de lógica / matemáticas / procesamiento son casi siempre casos que debería haber capturado. Los requisitos y los errores de la interfaz son más comprensibles, ya que las palabras significan cosas diferentes para diferentes personas, sin importar cuán detalladamente las escriba. Sin embargo, si entendió lo que significaba el requisito y aún tenía el error, entonces ese error de requisito no es comprensible.

Alguien señaló que 3 o 4 errores por kSLOC son promedio, eso también me parece alto, pero he estado en proyectos que fueron peores (así que quizás no lo sea). Sin embargo, esos mismos proyectos tampoco tuvieron muy buenos desarrolladores. OMI, si no es un error oscuro o una mala interpretación, el error no debe estar en el código. Si es así, no estás haciendo tu trabajo correctamente. Entonces, tal vez 10 es demasiado, quizás no, depende de los tipos de errores que esté creando.

Si usted ingresa su código solo después de tres meses de trabajo, creo que hay algo que está muy mal.

En cuanto a los proyectos con un breve ciclo de registro personal, creo que cada error es demasiado. Siempre arregle los errores antes de escribir el nuevo código (# 5 en la prueba de Joel ).

Solo soy un perfeccionista, pero tiendo a revisar todo y probarlo con cosas que sé que solía romper (y cosas que sé que solían funcionar) para asegurarme de que mi nuevo código solucione mis problemas anteriores (y no lo haga " arreglar "cualquier solución antigua). Tengo la mala costumbre de quedarme colgado arreglando un error en lugar de agregar algo que necesitaba agregar. Esto es probablemente algo bueno, pero ¿quién sabe?

Supongo que pasa 3 meses escribiendo y encontrando errores, y que su resultado final después de 3 meses de trabajo tuvo 10 errores. Esto está bien. No necesariamente diría que esto es bueno o malo; depende de cuánto de los 3 meses pases reparando errores. Si solo estás escupiendo el código durante 3 meses y luego registralo, 1) lo estás haciendo mal, y 2) eso es bastante sorprendente. Sin embargo, si pasas esos 3 meses revisando tu código y asegurándote de que funcione, lo cual sospecho que eres, podría sugerir que pases un poco más de tiempo revisándolo para eliminar al menos 5 de esos 10 errores. Si se trata de casos de esquina que ocurren con una combinación de entradas incorrecta y poco común, entonces eso es algo perdonable, pero si son bastante comunes, debería considerar tomarse un poco más de tiempo para localizarlos.

No quiere decir que esté haciendo un mal trabajo, pero si cada 3 meses el resto de su equipo tiene que rastrear y corregir los 10 errores que introduce para que sus funciones estén en funcionamiento, puedo entender que se molesten un poco.

Un pelo en la sopa es demasiado y en la cabeza muy pocos. Todo depende

Una posibilidad para clasificar los errores es usar un método similar a FMEA. El FMEA (modo de falla y análisis de efectos) se realiza normalmente en la fase de diseño y no después. Pero es solo una idea tener la importancia de defectos comparables.

S = Gravedad de la aparición del defecto (alto impacto en el software: bloqueo, pérdida de datos ...)
O = índice de ocurrencia (con qué frecuencia ocurre el defecto)
Clasificación de detección (aquí no es realmente útil: ¿Pruebas unitarias?)

Una medida de cómo "Importante" el defecto es efectivamente RPN = S x O.

Ningún software está libre de errores. El desarrollador mismo nunca es el mejor probador. Es por eso que los pasos de QA son siempre necesarios. Los evaluadores que lo culpan deberían estar felices de haber encontrado los defectos antes de que lo hiciera un cliente. Por supuesto, todavía hay una programación deficiente o un diseño deficiente, pero también una prueba deficiente ... El mundo no es perfecto, pero tenemos que hacer frente a todas estas cosas de una manera adecuada. Utilizar procesos de desarrollo de software aún más estrictos si el software que desarrolla se utiliza en un entorno médico o militar, por ejemplo. Si se utilizaron todas las herramientas para la calidad del software: diseño FMEA, verificación de códigos estáticos, revisiones de códigos de pares, pruebas de unidades, pruebas de componentes, pruebas de sistemas, ... no se debe culpar a nadie.