Esta pregunta ya tiene respuestas aquí :
Respuesta
Cuanto más cerca esté de una aplicación sin errores, más caro se vuelve. Es como apuntar a una cobertura de código del 100%: invierte la misma cantidad de tiempo y dinero en obtener del 0% al 95%, del 95% al 99% y del 99% al 99,9%.
¿Necesita este 0.1% adicional de cobertura o calidad de código? Probablemente sí, si está trabajando en un producto de software que controla el sistema de enfriamiento de un reactor nuclear. Probablemente no si está trabajando en una aplicación empresarial.
Además, la creación de software de alta calidad requiere un enfoque muy diferente . No puede simplemente pedirle a un equipo de desarrolladores que se pasó la vida escribiendo aplicaciones comerciales que creen una aplicación casi libre de errores. El software de alta calidad requiere diferentes técnicas, como prueba formal , algo que ciertamente no desea utilizar en una aplicación comercial, debido al costo extremadamente alto que representa.
Como expliqué en uno de mis artículos :
-
Las aplicaciones comerciales no deberían apuntar a la calidad requerida para el software vital, porque si esas aplicaciones comerciales fallan de vez en cuando, simplemente no lo hace » No importa. He visto errores y tiempo de inactividad en sitios web de probablemente todas las grandes corporaciones, siendo Amazon la única excepción. Este tiempo de inactividad y esos errores son molestos y pueden costarle a la empresa algunos miles de dólares al mes, pero solucionarlo sería mucho más costoso.
-
El costo debe ser el enfoque principal, y debe estudiarse de forma pragmática. Imaginemos un error que afecta a 5000 clientes y es tan importante que esos clientes se irán para siempre. ¿Es esto importante? ¿Sí? Piense más. ¿Qué pasa si digo que cada uno de esos clientes paga $ 10 por año y que ¿Cuesta casi $ 100 000 para corregir el error? La corrección de errores ahora parece mucho menos interesante.
Ahora para responder a sus preguntas específicamente:
¿Por qué se informan errores incluso después de pasar por tantas pruebas? ¿Es nuestro problema de requisitos? ¿Nuestro cliente no parece contento con nada de lo que ofrecemos? ¿Estamos haciendo algo incorrecto?
Muchas cosas pueden salir mal. Por prueba, ¿te refieres a pruebas automatizadas reales? De lo contrario, este es un gran problema en sí mismo. ¿Los evaluadores comprenden los requisitos? ¿Se comunica con el cliente de forma regular? Al menos una vez por iteración, en el mejor de los casos cualquier miembro de su equipo puede comunicarse inmediatamente con el representante del cliente en el sitio ? ¿Son sus iteraciones lo suficientemente cortas? ¿Los desarrolladores están probando su propio código?
De manera similar al artículo Escriben lo correcto vinculado anteriormente, tome un informe de error y estudie por qué apareció este error en primer lugar y por qué cada evaluador no lo detectó . Esto puede darle algunas ideas sobre las brechas en el proceso de su equipo.
Un punto importante a considerar: ¿está pagando su cliente por la corrección de errores? Si no, se le puede animar a considerar muchas cosas para Ser un error. Hacer que pague por el tiempo que dedica a los errores reducirá considerablemente el número de informes de errores.
¿Alguien ha desarrollado alguna aplicación que ¿Totalmente libre de errores? ¿Cuál es el proceso? ¿Por qué no podemos implementar la aplicación con errores menores? ¿Se supone que somos perfeccionistas?
Yo. Escribí una aplicación para mí el último fin de semana y no he encontrado ningún error hasta ahora.
Los errores son solo errores cuando se informan. Entonces, en teoría, tener una aplicación libre de errores es totalmente posible: si nadie la usa, no habrá nadie para reportar errores.
Ahora, escribiendo una aplicación a gran escala que coincida perfectamente con el especificación y se ha demostrado que es correcta (consulte la prueba formal mencionada anteriormente) es una historia diferente. Si este es un proyecto vital, este debería ser su objetivo (lo que no significa que su aplicación estará libre de errores).
¿Es el escenario actual el proceso correcto de desarrollo y prueba? Si no es así, ¿cuál es una forma eficiente en la que los desarrolladores, evaluadores y el cliente obtienen el máximo beneficio juntos?
-
Para entenderse , deben comunicarse. Esto no es lo que sucede en la mayoría de las empresas que he visto. En la mayoría de las empresas, el gerente de proyecto es el único que habla con el cliente (a veces con un representante).Luego, comparte (a veces parcialmente) su comprensión de los requisitos con desarrolladores, diseñadores de interacción, arquitectos, administradores de bases de datos y evaluadores.
Por eso es esencial que el cliente (o el representante del cliente) ser accesible para cualquier miembro del equipo (enfoque ágil) o tener medios de comunicación formales que autoricen a una persona a comunicarse solo con algunas otras personas en un equipo y hacerlo de manera que la información se pueda compartir con todo el equipo, asegurando que todos tengan la misma información.
-
Hay muchos procesos para hacer desarrollo y pruebas. Sin conocer con precisión la empresa y el equipo, no hay forma de determinar cuál debe aplicar en su caso. Considere contratar a un consultor o contratar a un gerente de proyecto que sea lo suficientemente hábil.
Comentarios
Respuesta
No todos los errores son iguales, por lo que es necesario separar el trigo de la paja.
Expectativas
Muchos errores surgen simplemente debido a un déficit en lo que hace el software y lo que espera el usuario final. Esta expectativa proviene de muchas áreas: uso de otro software, documentación incorrecta, personal de ventas demasiado entusiasta, cómo solía funcionar el software, etc.
Scope creep
No hace falta decir que cuanto más entregue, mayor será el potencial de errores. Muchos errores simplemente surgen como consecuencia de las nuevas funciones. Entregas X & Y, pero el cliente dice que en la parte posterior de esto ahora también debería hacer Z.
Comprenda el dominio del problema
Muchos errores se producen por la sencilla razón de que el dominio del problema no se comprendía bien. Cada cliente tiene sus propias reglas comerciales, jerga y formas de hacer las cosas. Gran parte de esto no se documentará en ninguna parte, solo estará en la cabeza de la gente. Con la mejor voluntad del mundo, no puedes esperar capturar todo esto de una sola vez.
Entonces … qué hacer al respecto.
Pruebas unitarias automatizadas
Muchos errores se introducen como un efecto secundario inesperado de algún cambio de código u otro. Si Si tiene pruebas unitarias automatizadas, puede evitar muchos de estos problemas y producir un mejor código desde el principio.
Las pruebas solo son tan buenas como los datos suministrados, así que asegúrese de comprender completamente el dominio del problema.
Cobertura de código
Esto va de la mano con las pruebas unitarias automatizadas. Debería asegúrese de probar tanto código como sea práctico.
Aprenda las lecciones
La locura es hacer lo mismo una y otra y otra vez y esperar resultados diferentes
¿Entiendes las causas del último fallo? ¿Verdad? ¿En serio? Puede que hayas dejado de el problema ocurriendo pero ¿cuál fue la verdadera fuente raíz? ¿Datos incorrectos? ¿Error de usuario? ¿La corrupción del disco? ¿Interrupción de la red?
Nada molesta más a los clientes que encontrarse con los mismos problemas una y otra vez sin avanzar hacia alguna forma de resolución.
Respuesta
Los defectos han existido desde el comienzo del desarrollo de software. Es difícil decir a partir de su pregunta hasta qué punto y qué gravedad los defectos afectan la usabilidad o la funcionalidad.
Existen programas sin defectos, pero casi cualquier sistema no trivial tendrá defectos.
Tendrá que decidir sobre algún tipo de priorización y probablemente tendrá que hacer un estudio de la causa de los defectos, donde se introdujeron. Hay mucho que discutir sobre tales cosas en una simple Q & Una publicación.
Se han escrito libros enteros sobre el análisis causal y el proceso de reparación para una organización que tiene problemas de calidad.
Así que mi recomendación es: (sin ningún orden en particular)
- Implementar un sistema de seguimiento de defectos si aún no ha encontrado uno
- Determinar una forma de clasificar la gravedad de los defectos
- Averigüe por qué no está cumpliendo con las expectativas del cliente (son los desarrolladores, el control de calidad, el cliente, etc.).
- Aprenda algunos ejercicios como los «Cinco por qué» y realice investigaciones similares. ación en algunas de las causas de sus defectos.
Responder
Depende de cómo llame a una aplicación.
Si te refieres a un programa interactivo en el que necesitas estar seguro de que el comportamiento en tiempo real es exactamente tal o cual bajo cualquier circunstancia, entonces es básicamente imposible probar que no hay errores. en eso. Supongo que sería posible si pudiera resolver el problema de detención , pero no puede hacerlo.
Sin embargo, si se limita a una declaración de «tal o cual entrada eventualmente producirá tal o cual estado final», entonces sus posibilidades de una «prueba libre de errores» son mejores, porque puede usar invariantes . Eso, y solo eso, permite que una prueba de corrección se desglose en subproblemas, cada uno de los cuales puede demostrarse con relativa facilidad para funcionar correctamente en todas circunstancias del programa restante (aunque generalmente «no puede ser muy preciso acerca de cuánto tiempo & de memoria podría tomar).
Tales técnicas son básicamente posibles en cualquier lenguaje de programación (aunque algunos esotéricos como Malbolge intentan refutar eso !), pero en todos los lenguajes imperativos se complica muy rápidamente, porque tienes que realizar un seguimiento meticuloso de muchos estado del programa implícito. En los lenguajes funcionales 1 , las pruebas tienden a verse mucho mejor ( lenguajes puros , o el subconjunto puramente funcional de un lenguaje). Aún así, en particular con los tipos dinámicos, deberá escribir muchos requisitos sobre qué entradas están permitidas. Ese es, por supuesto, uno de los principales beneficios de los sistemas de tipo estático fuerte: ¡los requisitos están ahí en el código!
Bueno, idealmente, eso es. En la práctica, los programas O «Caml o incluso Haskell tienden a contener funciones no totales , es decir, funciones que se bloquean / cuelgan / lanzan para ciertas entradas, a pesar del tipo correcto 2 . Porque a pesar de que estos lenguajes tienen sistemas de tipos muy flexibles, a veces todavía no es factible usarlos para restringir completamente algo.
Ingrese idiomas de tipado dependiente ! Estos pueden «calcular» los tipos con precisión según sea necesario, de modo que todo lo que defina pueda tener exactamente la firma de tipo que demuestre todo lo que necesita. Y, de hecho, los lenguajes de tipo dependiente se enseñan principalmente como entornos de prueba . Desafortunadamente, creo que ninguno de ellos está realmente preparado para escribir software de producción. Para aplicaciones prácticas, creo que lo más cerca que puede estar de completamente a prueba de errores es escribir en Haskell con funciones tan completas como posible. Eso te hace bastante cerca de a prueba de errores – aunque, nuevamente, solo con respecto a la descripción funcional. Haskell La forma única de manejar IO con mónadas también proporciona algunas pruebas muy útiles, pero generalmente no le dice nada sobre cuánto tiempo tomará algo finalizar. Muy posiblemente, algo podría tomar un tiempo exponencial en circunstancias particulares – del punto de vista del usuario, que probablemente sería un error tan grave como si el programa se cuelga por completo.
1 O más generalmente, lenguajes descriptivos . No tengo mucha experiencia con lenguajes lógicos, pero supongo que pueden ser igualmente agradables en la prueba saludos.
2 Si no es del tipo correcto, el compilador nunca lo permitirá en esos lenguajes; eso ya elimina muchos errores. (Y, gracias a la inferencia de tipo Hindley-Milner, ¡también hace que los programas sean más concisos!)
Comentarios
- " Si te refieres a un programa interactivo en el que necesitas estar seguro de que el comportamiento en tiempo real es exactamente tal o cual bajo cualquier circunstancia, entonces ' s básicamente imposible de probar que no hay ' t errores en eso. Supongo que sería posible si pudiera resolver el problema de detención, pero puede ' t. ": No estoy seguro de si esto declaración es correcta. Es imposible verificar un programa arbitrario , pero ¿qué pasa con un programa que ha escrito de una manera que permite tal verificación?
- Consulte, p. Ej. cs.cmu.edu/~rwh/smlbook/book.pdf , al comienzo de la página 198: " Por último, es importante señalar que la especificación, la implementación y la verificación van de la mano. No es realista proponer verificar que un fragmento de código arbitrario satisfaga una especificación arbitraria. Los resultados fundamentales de computabilidad y complejidad dejan en claro que nunca podremos tener éxito en tal esfuerzo. Afortunadamente, también es completamente artificial. En la práctica, especificamos, codificamos y verificamos simultáneamente, y cada actividad informa a la otra."
- @Giorgio: seguro que puedes escribir algunos programas de una manera que permita tal verificación , pero eso realmente te restringe bastante un monton. En un programa grande, ' casi siempre necesitará explotar la integridad de Turing en alguna parte. – Sí, en la práctica, usted especifica, codifica y " verifica " simultáneamente, pero esa verificación suele ser lo suficientemente heurística (basada, por ejemplo, en pruebas unitarias , no pruebas reales).
- ¿Qué quiere decir con " explotar la integridad de Turing "?
- " … pero esa verificación suele ser suficientemente heurística (basada, por ejemplo, en pruebas unitarias, no pruebas reales) ": No , si lee las notas con atención, habla de demostrar la corrección por medio de métodos formales (por ejemplo, mediante inducción), no habla de pruebas unitarias. Consulte también compcert.inria.fr/doc .